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.
The comments are closed.