«My paper’s due tomorrow, but my PC won’t print, what do I do now?»
«What do you mean, it won’t print? What happened?»
«Well, I clicked on print, but nothing came out the printer.»
«Did you get an error message?»
«Yeah, I got an error message.»
«Well, what did it say?»
«How should I know?»
If you’re reading this, you’ve probably had this conversation multiple times. It’s interesting, really. We all know that people don’t read dialog boxes, yet when there’s a problem with our UI, when people don’t understand what they’re supposed to do or when they do something wrong, we tend to try to solve the problem by adding more text to more dialog boxes. Just add some explanation; surely people will read it and figure out what they’re supposed to do! Just add a warning message; surely people will read it and click «Cancel» if needed!
Except that they don’t. People don’t read, so you can’t rely on text for solving user interface issues.
Here are a few things you can try instead of adding more text:
If people can’t figure out your user interface, perhaps it’s too crowded. Instead of adding more explanatory text, try removing unneeded options, unnecessary buttons and information the user doesn’t need to see at that moment. The fewer things the user can do, the smaller the chance that he does something he doesn’t actually want to do. The less information the user sees, the smaller the chance that he looks at the wrong data, or misinterprets a piece of data.
Don’t say «Cancel» or «Achtung» when you mean «Undo»1
If the user is about to do a something dangerous, do you really need to warn her? She probably won’t even notice your warning since she’s so used to clicking «Okay» on all those annoying warning dialog boxes. If she is about to change something, do you really need a modal dialog box with a «Cancel» button? How about a palette window which immediately makes the change instead?
What if the user does something that turns out to be an error? Allow her to undo her change.
Deleting a single file in Windows interrupts you twice with horribly designed modal dialog boxes. Here’s what you get after trying to move a file to the bin:
And this is what interrupts you when you try to empty the bin:
Contrast this with gmail’s simple, elegant solution. Deleting mails does not interrupt you. Instead, you get this:
Always Use Verbs as Button Labels
The two Windows dialog boxes shown above have another problem yet: Since people won’t read your dialog boxes, it’s important to make the buttons’ functions blatantly obvious. In the two dialog boxes shown above, users do not know what the buttons do unless they read the dialog boxes. Which they don’t. So they simply assume that «Yes» deletes the file.
Which might turn out to be a wrong assumption if their mail client instead asks «Do you want to keep these files?»
If you need to use dialog boxes, never use «Yes,» «No,» «OK» or «Cancel,» but always use action verbs as labels for their buttons. That way, it’s immediately obvious which button triggers the action the user actually intended.
Provide an Error History
People may dismiss your error messages immediately when they show up, but they may regret their rash actions later. Providing a history log of errors may be useful to your users and the people who have to fix their problems.
Most of your users simply don’t read dialog boxes or explanatory on-screen text. Your user interface must be obvious enough that people can understand it without reading warning messages or explanatory text. Never use warnings when you can use undo instead, and never use plain «Yes» «No» dialogs; use verbs as button labels instead.
Title blatantly stolen from Aza Raskin’s essay «Never Use a Warning When you Mean Undo», in which he writes: «Software should «know» that we form habits. Software should know that after clicking «Okay» countless times in response to the question, we’ll probably click «Okay» this time too, even if we don’t mean to. Software should know that we won’t have a chance to think before accidentally throwing our work away.»
If you require a short url to link to this article, please use http://ignco.de/35