UX Design Edge

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.

• 1 Comment »


• Interaction design, UI design, UI is communication, UX design