Archive for the ‘Interaction design’ Category

Are you sure? How to write effective confirmations

I stumbled upon Never Use a Warning When you Mean Undo by Aza Raskin the other day (and to clarify, what Aza calls a warning, I call a confirmation where users are explicitly asked to proceed with a task they initiated.) Aza’s basic point is that confirmations are often used when an undo feature would be more appropriate. While true, this isn’t always the best solution (even if Undo were always possible), and what’s more, this is only part of the story. In this post, I’ll tell the whole story.

UI is communication

When making a design decision, it’s good to think about alternative designs as Aza suggests here. However, a more fundamental design principle to consider first is the need for effective communication. A user interface is a conversation between the user and your product’s underlying technology. A UI is good only if that communication feels natural, friendly, and efficient. Effective communication is the universal design principle that spans the popular UI design books, from Don Norman’s The Design of Everyday Things, to Steve Krug’s Don’t Make Me Think, to Edward Tufte’s books on visual communication. Effective communication is essential to the design of all UI elements, including task flow, text, use of controls, layout, animation, color—even icons and graphics.

What do confirmations communicate?

Imagine a situation where everything you did was confirmed based on the possibility—however small—that you might not intend to proceed with what you were doing. Some UIs feel like this, so you don’t have to imagine too hard. In this situation, you quickly become habituated to the extra step and proceed without giving the confirmation any thought. Not only would such confirmations not achieve their intended goal of reducing error, but they actually increase error because any necessary confirmations would no longer stand out. Confirming would be a pointless ritual, much like the “Final answer” routine in Who Wants to Be a Millionaire.

So what makes a confirmation necessary? The mere possibility of making a mistake isn’t sufficient. There are three basic patterns where confirmations are warranted:

  • Risky actions The user is about to take an action that has significant consequences that cannot be easily undone.
  • Unintended consequence The action itself might not be risky, but there is a significant side effect of the action that the user needs to be aware of.
  • Clarification There is more than one way to perform the action, so the user needs to confirm the desired outcome. These are usually presented as a choice dialog, but they have the effect of being a confirmation as well, particularly if the user doesn’t desire any of the offered outcomes.

Given these basic patterns, a confirmation is necessary when there is a strong reason not to proceed. An effective confirmation is essentially trying to talk the user out of proceeding and there is a significant chance that the user might decide not to. Another important implication: confirmations should be rarely needed—a well designed system shouldn’t have many actions that are risky or have unintended consequences.

Are you sure?

Confirmations tend to be abused because they are easy to implement. They also provide an element of safety—for the designer—because they transfer the liability of a mistake from the software to the user (the logic: we asked you and you said “yes,” so if you aren’t happy it’s your fault.)

But neither of these are a good reason to use a confirmation and often there is a better alternative:

  • Prevent the error You don’t need to confirm if you can prevent a mistake from happening in the first place. For example, if you design your system architecture to avoid unintended consequences, there’s no need for its confirmation. Another approach is to design direct manipulations to avoid accidental manipulation.
  • Provide feedback Good feedback is a good way to prevent errors, especially with direct manipulation. Users shouldn’t be able to make significant mistakes without knowing it. For example, you don’t need to confirm direct manipulations if their effect is extremely clear.
  • Provide undo Provide the ability to easily revert unintended actions. For example, having a trash can, recycle bin, or deleted items folder is a standard way to restored accidentally deleted objects. User-created objects should be restorable from their deleted state for an extended period of time—modern UXs shouldn’t delete them until necessary.
  • Make the results easy to change Suppose you have a situation where there might be two intended outcomes, but one outcome is 98% likely and the other is just 2%. You can eliminate the Clarification confirmation by doing the 98% choice automatically, especially if you make it easy for users to chose the 2% option later.
  • Just don’t ask If the confirmation isn’t necessary and none of the above alternatives work, usually the best solution is to just not ask.

The answer is never No, so don’t bother asking.

I could give many more examples for each of these alternatives, but the bottom line is that it should be difficult to lose work or make significant mistakes in a well designed product. When evaluating a task flow, at each step ask yourself “What mistakes might the user make and how does the design prevent them or reduce their impact?”

Main instructions

A good confirmation main instruction must require thought. Remember, the entire point of an effective confirmation is to give the user a reason not to proceed, so that reason should be clear. (Making the generic “Are you sure?” confirmation clearly pointless.) The risk of the action or the unintended consequence should be extremely clear.

Provide all the information

A general rule: whenever you ask the user a question, you provide all the information required to provide an informed answer. Be sure to give specific risks, object names, contexts, etc. required to respond in the confirmation itself.

Design responses to create a mental speed bump

Ordinarily, a good dialog box is designed for efficient decision making, where users can often respond without reading anything but the response buttons.

While this works well in general, the entire point of a confirmation is to get the user to stop and think about whether or not to proceed. (If proceeding requires no thought, don’t confirm!) There are two facts about user behavior that we need to work with here:

  • We can’t force users to read the main instruction.
  • Users do read button labels before they click them.

Given these facts, there are three ways we can write the response button labels to create a mental speed bump:

  • Choose specific responses so that the reason to not proceed is obvious even without reading the main instruction.

The Save vs. Don’t save labels tell you everything you need to know.

  • Use Yes/No responses (with the safe response the default). While there’s no guarantee, users generally read what they are responding Yes or No to before clicking.
  • Add “anyway” to the label, as in “Proceed anyway.” Anyway is a very provocative word that gets users to stop and think. “You mean there’s a reason to not proceed? Better find out what it is first.”

Don’t annoy me again

I forgot to mention the top problem with unnecessary confirmations—they’re annoying! When users are frustrated by unnecessary confirmations, all too often the “solution” is to add a “Don’t show this message again” option. Adding this option is a clear sign that the confirmation is unnecessary, because it makes no sense to add this option for a necessary confirmation.

While this is better than always confirming, it’s worse than never asking or asking just once. So while many people like this option, I don’t. All it does is show me that the designer tried to weasel out of making the hard design decision.  (To be clear: sometimes using this option is a good idea, but those situations are fairly rare.)

If you do only one thing:
Present a confirmation only if there is a solid reason to not proceed. If there is a reason to not proceed, make that reason obvious, provide all the information required to make a good decision, and design the response buttons to encourage users to read the main instruction. If a confirmation isn’t necessary, do the right thing and remove it.



Intuitive UI: What the heck is it?

For any UX project, it’s almost a sure thing that a top goal is to have an “intuitive UI.” To users, describing a UI as intuitive is among the highest praise they can bestow. Given this, it’s reasonable to ask what it means for a UI to be intuitive. Surprisingly, nobody really knows. Ironically, people’s definition of intuitive is, well, intuitive, as they struggle to define the term in a specific, meaningful way. (Other popular UI goals share this problem, “simple,” “easy to use,” and “clean” being runners up.)

A practical question: How can you achieve a project goal if you don’t even know what it is?

My practical answer: You can’t. The term “intuitive” is meaningless as a UI characteristic, so—with the exception of casual conversation—we should avoid using it, at least without prior definition.

Struggling for a definition

I used to work at Microsoft and as a Microsoft employee, it wasn’t uncommon for people to tell me (with a certain glee) that, they, unfortunately, prefer using a Mac. While I primarily use PCs, I too have a Mac and have had a current model for decades. I like the Mac and appreciate its advantages (along with its disadvantages), but knowing that my lack of disapproval would be disappointing, I always keep that detail to myself. Everyone assumes Microsoft employees hate Macs.

From this point, the conversations have been remarkably consistent. My response: “Really, why is that?” To this their response is consistent and immediate: “I find the Mac much more intuitive.” My response: “Interesting—could you give me some specific examples of how it is more intuitive?” With this question, their glee turns to shock and horror as if to say “Of course, the Mac is more intuitive—how dare you question that!”  From this point, they would struggle to come up with some sort of answer, ranging from “it just is” to “it just works” to “it’s simpler” to “Mac apps have a more consistent look and feel.”

Sure, there’s an element of “intuitiveness” in those responses, but there is no clear, consistent definition. Sans the reality distortion field, in practice intuitive just means better. But going back to our UX project, imagine a project goal being a “better UI.”  An equally useless as a goal, just more obviously so.

A dictionary definition

Starting with the definition of intuition from Wikipedia, I’ll say that the “dictionary definition” of intuitive is:

A UI is intuitive when users understand its behavior and effect without use of reason, experimentation, assistance, or special training.

For such intuition to be possible requires prior knowledge, either from experience in the real world or with other software. So, for example, if something looks like a push button, we know from the real world that we can click on it to make something happen. Alternatively, if something looks like a link, we know we click on it from experience with other software.

We can boil this definition down to two requirements: affordance and consistency, where affordance allows us to predict what is going to happen based on appearance, and consistency to make that prediction correct. Labeling and context are also factors in making the prediction.

So is intuitive just a fancy word for affordance, consistency, and predictability? It could be, but when people use the term, I think they have more in mind.

Everett’s definition

I like to define things, so I’ll take a crack at it. A UI is intuitive when it has an appropriate combination of:

  • Affordance Visually, the UI has clues that indicate what it is going to do. Users don’t have to experiment or deduce the interaction. The affordances are based on real-world experiences or standard UI conventions.
  • Expectation Functionally, the UI delivers the expected, predictable results, with no surprises. Users don’t have to experiment or deduce the effect. The expectations are based on labels, real-world experiences, or standard UI conventions.
  • Efficiency The UI enables users to perform an action with a minimum amount of effort. If the intention is clear, the UI delivers the expected results the first time so that users don’t have to repeat the action (perhaps with variations) to get what they want.
  • Responsiveness The UI gives clear, immediate feedback to indicate that the action is happening, and was either successful or unsuccessful.
  • Forgiveness If users make a mistake, either the right thing happens anyway or they can fix or undo the action with ease.
  • Explorability Users can navigate throughout the UI without fear of penalty or unintended consequences, or of getting lost.
  • No frustration Emotionally, users are satisfied with the interaction.

Of these elements, the first two reflect the dictionary definition, and the others are those extra attributes that go beyond the literal definition.

Achieving your goals

If your goal is an “intuitive” UI, I think it’s best to explicitly spell out exactly what you want using the above attributes. Don’t use the term in specs, proposals, or plans unless you define the term in detail beforehand. When evaluating a UI, always do it in terms of the specifics. Otherwise, intuitive will end up being a vague synonym for good instead. That’s at best. The world’s most confusing UI could be credibly described by its creators as intuitive as long as the term isn’t defined specifically.

If you do only one thing:
Don’t use the term intuitive to describe a UI without a definition because nobody understands what it means. Instead, define the term specifically in your documents or describe your goals using more specific terms.

A footnote

I’ve got 80+ UI books in my library, but only two bothered to define the term. In The Humane Interface, Jef Raskin defines intuitive as familiar. I prefer consistent though because it is more specific and actionable. In Software for Use, Larry Constantine and Lucy Lockwood define it as guessable and behaving as expected.



Accidental manipulation and intentional affordance

In my post Getting started in interaction design, I recommend that you pay attention to design and learn to appreciate good design. I had a chance to do both last weekend. I was at Stowe Mountain Lodge, my favorite resort in Vermont, and noticed that the controls on their Technogym exercise equipment were particularly well designed. To appreciate why, I’d like to start by explaining a significant problem with direct manipulation, and give a couple examples of direct manipulations that aren’t so well designed.

Direct manipulation

Direct manipulation is a crucial ingredient of a modern UX. Direct manipulation is the ability for users to perform a task on an object instead of indirectly through some intermediary. For example, moving a window using a Move Window menu command is indirect manipulation, whereas dragging a window into position is direct. Traditionally we have used a mouse to perform manipulation, but touch-based interfaces feel more direct because there’s nothing between users and the object being manipulated.

Accidental manipulation

But there’s a problem: where there is direct manipulation, there is accidental manipulation. There’s always a chance that the user performed an action either entirely by accident, or performed the wrong operation or acted on the wrong object.  The potential for accidental manipulation is large enough that critical operations shouldn’t be performed without confirmation. (Hmm…did I just drag the North American domain to Fiji?) But note that generally, combining direct manipulations with confirmations is a poor idea because confirmations destroy the very directness you are after.

Touch-based UIs are especially prone to accidental manipulation. This is why a swipe motion (with very little margin for error) is used to initiate interaction with an iPhone—a correctly performed swipe indicates with high probability that the input is intentional.

Well designed direct manipulation must minimize the likelihood of accidental manipulation. Failing to do so will make the design annoying at best and disaster prone at worst.

Bad example: My Miele vacuum

My Miele vacuum is an example of a design that fails to consider accidental manipulation.

Take a look at the handle, and notice the bypass device at the top. Not obvious from the photo is that the bypass device slides open with minimal resistance. Where do you think your thumb will naturally go? When vacuuming, what motion will you naturally make? Guess what happens—constantly—when you naturally use the device as intended.

This vacuum is frustrating to use because I’m constantly opening the bypass without realizing it. The feedback isn’t as obvious as you might think—the vacuum doesn’t work well and sounds louder and eventually you realize that you’ve opened the bypass and wonder how you managed to open it yet again.

Talk about not getting the proper amount of suction.

Another example: Windows 7 Aero Snap

To take a software example, this extremely heavily promoted feature allows you to quickly view two windows side by side by dragging them to their respective sides of the screen. (Snarky comment: from the advertising, you’d swear that this was the most useful thing you could do with a computer.)

Unfortunately, this feature wasn’t designed to prevent accidental manipulation. If you don’t want a window to snap, it’s very difficult to persuade Windows otherwise once you get in Snap’s gravitational field. (“Aero Shake” cancels a snap, but shaking isn’t easy to do and it’s difficult to discover.)

Aero Snap works extremely well better with high resolution, wide-screen monitors, but I find that it’s way too easy to trigger by accident with lower res monitors (like 1024×768). In this case, the accidental snaps happen far more frequently than intentional ones, making the feature a net negative.

This part of Windows 7 wasn’t my idea.

Update (5/11/2011): I finally got fed up and turned off Aero Snap. I find that even on high res monitors, it’s wrong far more often than it’s right. The novelty has long worn off, so it’s just not worth the trouble anymore.

Great example: Technogym

I found that the Technogym level controls are brilliantly designed to prevent accidental manipulation. Here is what the control looks like:

Note how recessed the button is. Here’s how the handle looks when you grab it naturally:

Note how the control lies in the gap between the thumb and the fingers, and how the thumb is naturally away from the control. However, even if you were to slide your thumb around in a variety of positions, you won’t trigger the control accidentally because it is recessed:

But if you do want to change the level, doing so is simple and easy.

The goal is to make it difficult to press the button through casual contact. If you press the button, you almost certainly did so deliberately.

Intentional affordance

I use “intentional affordance” to describe direct manipulation that ensures the interaction is intentional. The challenge is to design simple, natural interactions that are constrained just enough to signal clear intent. The Technogym controls and the iPhone swipe are excellent examples.

If you do only one thing:
Design manipulations that are likely to be performed accidentally to have affordances that require clear, deliberate intent.

The tragedy of great design

The tragedy of great design is that if it is particularly well done, most people won’t even notice it. Their reaction will be “Of course! How could you design it any other way?” I bet most people who used the Technogym controls never gave them a second thought. But the bad examples show that great interaction design happens only when someone designs something carefully and well.

Fixing Aero Snap

As a challenge, design Aero Snap to have intentional affordance. When done, compare your answer to mine.



Getting started in interaction design

“I’m a software developer and I just started working on a project that needs a good UI. I don’t have a UI design background and nobody on my team does either, but I know enough to realize that our current design needs a lot of work. I’d like to help make it better. How should I get started?”

This is a popular question. While there are many things you could do, here’s what I recommend:

  1. Pay attention to design Design, both good and bad, is all around you so pay attention to your everyday experiences. If something works well or doesn’t work well, try to understand why. To develop your design thinking, make note of what is “intuitive,” what confuses you, what delights you, and why.
  2. Know where you are on the UX design skills ladder Understanding the ladder will help you develop a road map to get to the next skill level. It will also help you work more effectively with people with different skills by understanding where they are coming from.
  3. Design for your users, not yourself The most common trap for beginners is to design for themselves. It’s also common for intermediates to think that they are designing for their users but design for themselves instead. An easy way to tell the difference is to gather your team and write down all the known facts and assumptions about your target users, then validate your design decisions against the list. If, for example, you are targeting beginners but some features require advanced knowledge, you’ve got some work to do.
  4. Work with more than one design idea The second most common trap is to fall in love with your first idea and, as a result, fail to see other possibilities. Design is about making choices, but you can’t make a good choice unless you have options to choose from. Considering alternatives also helps you build confidence in your decisions. But if your first idea is so good that you can’t possibly think of anything better, at least design a simpler version of that solution. Chances are you’ll like it better (and prove to yourself that there are alternatives.)
  5. Think in terms of users and scenarios, not in terms of features and technologies A scenario is a description of a user’s goal, problem, or task in a specific environment. Great design focuses on nailing important scenarios. By contrast, weak design focuses on individual features and technologies, without much regard for the user’s goals, tasks, or environment.
  6. Make priorities It is literally impossible to focus on everything. Good design establishes clear targets and nails them. Poor design is undisciplined and tries to do everything for everybody. You can’t do everything, and you certainly can’t do everything well. Do less better instead.
  7. Learn to communicate to users effectively Great designs communicate their purpose well. This is what people really mean when they say a design is “intuitive.” Think of your UI as a conversation between you and your target users.
    Does your design communicate well? Here’s a simple test: suppose you are looking over a user’s shoulder and he or she asks, “What should I do here?” Think about the explanation you would give—the steps, their order, the language you’d use, and the way you explain things. Also think about what you wouldn’t say. That’s what your UI should be—like a conversation between friends—rather than something arcane that users have to decipher. If the UI feels like a natural conversation, your design communicates well.
    Many developers avoid thinking about UI text, and assume that any problems can be fixed by somebody else later. Wrong!  If the communication is poor, the design is poor—and quite often such problems can’t be fixed by just tweaking text. Effective communication is an essential element of good design, not an add-on.
  8. Look for design models What existing products or services have a similar experience? This is helpful question when brainstorming or identifying design alternatives. The design models don’t even have to be remotely related to what you are doing—a particular experience at Starbucks might be a great design model for purchasing your accounting product. The key is to understand that the goal isn’t to copy other people’s ideas but to inspire you to consider the full range of possibilities.
  9. But don’t design by copy Another trap for beginners is to design by copying features that you like. While at first this approach seems logical—if the design works and you like it, why not use it? The problem is that design is all about making good choices on behalf of your target users to create a product that satisfies their goals. Design-by-copy often fails because it short circuits this user-centered thinking by focusing on features—features that may have been designed for different users with different goals in different environments.
  10. Ask for feedback Ask people who represent your target users (or at least neutral observers) to review your design and provide feedback. Review their feedback, look for trends, and refine the design. If you design without getting feedback, there is a good chance that you’ll make many mistakes. I try to get feedback on everything.
  11. Learn how to receive critical feedback Critical feedback is required to do your best work, but not all feedback you receive is going to be encouraging or well presented. Regardless, smile, thank the person for helping you, take the feedback seriously, follow up on it, and encourage more.
  12. Learn to give good feedback—based on something other than personal opinion Feedback is a two-way street, so it’s important to learn how to give good feedback as well. If someone asks for your feedback about a design, it’s inevitable that at least some of it will be personal opinion. However, feedback based on scenarios, design principles, guidelines, and such are far more useful, especially when there is disagreement within a team. For example, think of the top tasks you can perform with a product, and present your feedback in terms of the issues you found while performing those tasks. While such feedback might still feel personal, it’s not just personal opinion anymore.
  13. Learn to appreciate good design It’s easy to criticize bad design—anybody can do that. A more useful talent is to understand what makes a good design good. When you see a good design, examine it carefully and try to understand why specifically it works so well. Think about the project management angle too—consider the team leadership and design process required to make that good design a reality. It didn’t just happen by itself.
  14. Learn to appreciate bad design It’s easy to sneer at bad design—look at how silly those people were…what were they thinking? Of course, we would do so much better, right?
    Not necessarily. There are many traps in the design process and we are all bound to fall into them eventually. When you see a bad design, examine it carefully and try to understand what went wrong behind the scenes. Did they try to do too much? Was it designed by non-designers? Was it designed by committee? By the boss? For the boss’s mom? Did they design around features and technology instead of users and scenarios? Did they not do any user testing? Was the schedule unrealistic? Did they rush to market? Bad design happens for a reason, and many of those reasons extend well beyond design skills.
  15. Continue to improve your skills Read books and blogs about UX design. Read up on interaction guidelines. Take a design course. Hire a design consultant to help you get started.

If you need professional help with any of these skills, please let us know. We’re here to help!



Why “everybody is a designer”: The UX Design Skills Ladder

I started to write an article on how non-designers can get started in interaction design, but quickly realized that Tip 2, “Know where you are on the UX design skills ladder,” is worthy of its own post.

The UX Design Skills Ladder has several constituents:

  • The ability to recognize problems
  • The ability to identify solutions
  • The scope of design knowledge
  • The method for making decisions
  • The ability to give and receive feedback
  • The ability to persuade others

Here it is:

Level 0—”Everybody”

  • Can identify general, superficial problems with a design.
  • Thinks of design in terms of technology.
  • Believes “user centered design” means designing for the one’s mother, sibling, or spouse.
  • Gives vague, often harsh feedback, usually in terms of personal opinion or preference.
  • Offers feedback that is often inappropriately detailed, focused on minor visual details.
  • Is unaware of what they don’t know.

Level 1—Beginner designers

  • Can identify basic interaction and visual design problems.
  • Thinks of design in terms of technology and features.
  • Works with a single solution, rarely considers alternatives. Often that single solution is their first idea and they have trouble seeing beyond it.
  • Makes one-off decisions based on whatever “feels right.” Often “wings” it.
  • Offers feedback in terms of personal opinion or the behavior of other programs.
  • Can convince self that a design idea is good.

Level 2—Intermediate designers

  • Can identify many interaction and visual design problems. Aware of what makes a design good.
  • Thinks of design in terms of tasks.
  • Usually works with a single solution, but occasionally works with a few.
  • Makes decisions based on data, team feedback and consensus, and the problem at hand. Still often “wings” it.
  • Offers specific, actionable feedback at the appropriate level in terms of design concepts.
  • Can convince several people that a design idea is good.

Level 3—Advanced designers

  • Can identify subtle interaction and visual design problems. Has a strong appreciation for good design.
  • Thinks of designs in term of scenarios and personas.
  • Always works with many solutions before making a choice. Proposed solutions include standard approaches, simple solutions, and innovative alternatives that others would miss.
  • Makes decisions using a decision making framework and a holistic product vision. Often uses data to make decisions, but is willing and able to go beyond the data.
  • Offers specific, constructive, actionable feedback at the appropriate level in terms of design principles, guidelines, branding.
  • Can convince a team that a design idea is good. Experts can convince a team that a radical design idea is good.
  • Is completely in tune with what they don’t know.

Some observations

  • Level 0 Everybody has at least level 0 design skills, which is why “everybody is a designer.” Unfortunately, these skills are neither rare nor particularly valuable but people at this level are blissfully unaware of this fact. They often think their vague, unactionable feedback is brilliant. For example, they’ll say things like “My mom would never do that” or “I don’t care for that color red.” Brilliant! They also tend to be managers.
  • Level 1 Most people experienced with “design thinking” are at least at level 1.
  • Level 2 A surprising number of people are at this level, even designers with many years of experience.
  • Level 3 This level of design skills is fairly rare. Many people think that they are at this level but aren’t quite there yet. For example, I’ve noticed that many who think they are doing user-centered scenario-based design are really doing feature- or task-based design. (The difference? Check Design scenarios—and how thrilled users ruin them.)

Why this helps

Knowing the ladder will help you in a variety of ways:

  • It suggests a road map on how to improve your design skills.
  • It helps you understand other people’s design skills better so that you can work with them more effectively.
  • It helps you evaluate other people’s design skills for things like job interviews.

If you do only one thing: Know your UX Design Skills level and make a plan to get to the next level.

Next week, we’ll look at how non-designers can get started in interaction design.



For more information, please contact info@uxdesignedge.com

All Content Copyright © UX Design Edge