No More Confirmation, pt 2: To Confirm Is Useless; to Undo, Divine

The common technique of confirmation, popping a dialog box into the user's face and asking, "Are you really Really REALLY sure you want to do that?" is evil. It's unfriendly, it's distracting, and it's completely ineffective. Have you ever, even once, said, "Whoa! I didn't want to do that. Thanks," and clicked No? Have you seen anyone do that? Have you even heard of anyone doing it? I haven't. It shouldn't exist. Anywhere. Ever.

Confirmation is so vastly overused that it has become completely useless. Because the box constantly cries "wolf!" like the shepherd boy in Aesop's fable, no one pays attention to it, even when it's warning you of something you really don't want to do. You cruise through it on auto-pilot, clicking Yes without thinking, an action the cognitive scientists call "chaining".

We might just tolerate the annoyance of confirmation if it actually made us safe, but research has shown again and again that it does not. On the contrary, mistakenly believing that a confirmation box will prevent users from making mistakes gives programmers a false sense of security. It keeps programmers from having to clearly explain to the user what he's doing, and providing a way to recover when he does something that he later regrets, despite having originally confirmed it.

No human being is ever 100% certain about anything; just ask anyone who's married. An application with undo capability recognizes and honors a user's humanity. One that lacks Undo is insisting that a user become something other than human to use that application successfully. Which would you rather buy?

Other operations in life don't require confirmation. Your car does not ask, "Do you really want to start the engine?" when you turn the key. The supermarket clerk does not ask, "Do you really want to buy these?" when you place groceries on the register belt. Programmers constantly ask for confirmation because they think users don't understand the consequences of their commands. That may be true, given the poor quality of the user interface. But confirmation doesn't solve this problem. If the user was confused when he first gave whatever command triggered the confirmation box, he'll be even more confused when he sees it.

But what if the user really has made a mistake? If you put a flashlight on the register belt with a package of the wrong size batteries, wouldn't an attentive clerk ask, "Are you sure you want this size and not the one that fits the flashlight you're buying?" A good user interface should and can save us from mistakes like that, but it won't happen by blindly and stupidly asking, "Are you sure?". Instead, a good user interface prevents the problem initially by Just Working. Perhaps the Web page selling flashlights would contain a check box saying "include batteries," checked by default. Better still, the flashlight would come with batteries already inside it, so it'd work the instant you unwrapped it and no one would ever have to worry about buying the correct size. Now that's a design that Just Works.

Another reason that you aren't asked to confirm starting your car or buying groceries is that these operations are easy to undo. You just turn off the key or return the unwanted item. Programmers often put "undo" capability in their programs, where it's the greatest design advance since the mouse. It takes an enormous amount of effort to make this feature work so that users don't even have to think about it ("easy is hard, the saying goes"), but the programmers who implement it are any user's best friends. I buy them beer whenever I meet them.

The worst confirmations are those of undoable actions, such as moving a file to the Recycle Bin, shown below:

It's much more efficient to fix the relatively small number of errors that actually do occur (for example, a slip of the mouse deleting the wrong file) than attempt to prevent them by annoying the user with a confirmation box every time (which are usually ignored out of habit). An ounce of cure is not worth five pounds of prevention, especially when what the programmer THINKS is prevention does not prevent anything.

The beauty of undo is that it allows users to explore a program. It's not always easy to understand a new program's operation from menu items and toolbar pictures. With undo, a user can try different commands, knowing that he won't damage something that can't be repaired with a few keystrokes. Programmers often regard incorrect user input as the act of an idiot who should have read the %*$#% instruction manual. It isn't. It is the primary mechanism by which the human species learns.

If undo is implemented correctly, then there's only one destructive operation in the entire system: emptying the Recycle Bin. Some would say that this operation should have a confirmation box, as it currently does. But even here, the confirmation dialog exists only to guard against another bad design, placing the "Explore" context menu item next to "Empty Recycle Bin." One slip of the mouse, sliding down three spaces instead of two, and you get the latter instead of the former. That's bad. Emptying the Recycle Bin should have a special action used for no other purpose, perhaps clicking on it while holding down some key. Better still, the Recycle Bin should automatically delete files after some configurable period of time so you'd seldom have to empty it manually. Don't you wish that your real trash cans Just Worked like that?

A good application should never ask permission. Programmers should provide undo capability, and not ask for confirmation. That's the way to write an applicatin that Just Works