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.
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.
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:
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.
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:
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?”
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.
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.
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:
Given these facts, there are three ways we can write the response button labels to create a mental speed bump:
The Save vs. Don’t save labels tell you everything you need to know.
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.
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.
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.
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.
I like to define things, so I’ll take a crack at it. A UI is intuitive when it has an appropriate combination of:
Of these elements, the first two reflect the dictionary definition, and the others are those extra attributes that go beyond the literal definition.
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.
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.
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 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.
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.
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.
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.
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.
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 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.
As a challenge, design Aero Snap to have intentional affordance. When done, compare your answer to mine.
“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:
If you need professional help with any of these skills, please let us know. We’re here to help!
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:
Here it is:
Level 1—Beginner designers
Level 2—Intermediate designers
Level 3—Advanced designers
Knowing the ladder will help you in a variety of ways:
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.