Jakob Nielsen's Alertbox, July 23, 2007:
Defeated By a Dialog Box
Summary:
Interaction techniques that deviate from common GUI standards can create usability catastrophes that make applications impossible to use.
I can operate almost any user interface. After all, I have 33 years' experience using computers and 25 years' professional experience analyzing bad designs: I know most of the ways interaction designers can confuse or annoy users. I've seen it all before. Or so I thought.
Despite my prowess at defeating complicated user interfaces, I was recently stumped by a simple dialog box. I simply couldn't figure out how to proceed, so I had to close the application and use another program to achieve my goal.
The offending software shall remain nameless; it's a nice piece of shareware that I enjoy enough to have paid the fee. Also, a single developer serves as both the programmer and interface designer on the application, so it would be unfair to pick on him.
Where's the OK Button?
The usability problem appeared after I upgraded to the application's newest release and wanted to save a file in a new image format. As the following screenshots show, this brought up the expected "Save As" dialog box, along with a smaller, overlaid dialog box containing a property sheet with the image format's special options.
The dialog boxes that appeared when saving a file.
The options window should have included a Help feature, because many of its options were rather obscure. As is typical of users who don't understand their options, I left the settings at the default values, particularly since I was satisfied with the defaults for those settings that I did understand. This is as it should be: if you pick good defaults, most users can ignore any advanced options and simply proceed.
My obvious next step was to accept the default options by clicking the OK button to dismiss the options box. Surprise: there was no such button!
However hard I tried, I couldn't get the application to show me an OK button. I tried saving in another format. I tried rebooting first the app, and then the entire computer. Nothing worked.
It was impossible for me to get rid of the active dialog box and get back to my "Save As" dialog box. I gave up. Defeated by a dialog box.
What You're Supposed to Do
A week later, I tried the software again. This time, for some reason, I clicked the Save button in the main dialog box without messing with the options. Surprise again: this worked, and my file was saved.Turns out that you don't have to accept the option settings. The software will apply whatever settings are active in the options window when you click Save in the "Save As" dialog box.
This completely non-standard GUI behavior caused a catastrophic failure in usability: the user (me) completely abandoned the application.
Having the user give up represents a usability problem of the highest severity level. It's only because I had positive experiences with several previous releases that I gave this app one more chance. If I'd been trying this piece of software for the first time, there wouldn't have been a second time.
Upon further experimentation, I discovered another way of getting rid of the options box: uncheck the checkbox marked "Show options dialog." This, of course, completely violates the design rules for checkboxes and radio buttons, which are not supposed to have any immediate effect when they are clicked. Only after the user clicks OK should the system take action on any checkbox selections.
Respect the User Illusion
Once you know how to operate this user interface, it's easy enough to use. But of course, users don't magically understand special interaction techniques, whether they appear in a software upgrade or a new application. Most users know only the standard interaction techniques that all of their other applications use.Users understand standard GUI rules such as:
- One window at a time is active, and that's the one you interact with, because that's the one that has input focus.
- The latest window to open is the active one; when one window spawns a sub-window, you have to deal with it first.
- You can change the input focus to another window by clicking within it. (I didn't try this because I "knew" it would be necessary to specify the options first.)
- Dialog boxes are dismissed by clicking OK or Cancel.
When you comply with these standard rules, users can focus on your application's meaning, rather than the physical operation of the mouse. There is enough complexity in the app's feature set; don't add to users' confusion by making them solve problems before they can click a button or type data into a text field. Figuring out which button to click and what data to type is hard enough.
One of the modern GUI's greatest advances is the user illusion that the mouse pointer is an extension of your hand: you own the pointer, which has a certain physicality to it as you use it to manipulate objects on the screen. Of course, all of this is only an illusion, because the mouse pointer is really under software control. Clicking the physical mouse while the on-screen pointer rests on a picture of something isn't really the same as clicking an object.
However, you must retain the user illusion of direct manipulation at all cost, because that's what makes users feel in charge of their computers.
Because there's no true physicality, the user illusion is maintained by complying with the low-level rules for GUI object behavior. Even the smallest deviation bursts the bubble and reveals the fact that users aren't really controlling their destinies.
It's very disconcerting when the laws of nature stop working. It blows away all that you thought you knew, and leaves you feeling weak and threatened.
Obeying design conventions and standards is the way to retain and strengthen users' feelings of mastery over technology.
Solutions
Fixing this usability problem is easy enough. There are four main possibilities, all of which operate within the standard GUI interaction rules:- Retain the current two-window design, but add OK and Cancel buttons to the options dialog. (Although you should usually avoid Cancel and Reset buttons on websites, applications need Cancel because users sometimes experiment with alternate options, so they need a way to back out and retain the standard settings.)
- Eliminate the separate options box and show the options within the main "Save As" window using progressive disclosure: make options visible only when the user clicks a button to change options.
- Have users proceed through a sequence of dialog boxes, so that only one box is visible at any given time. Photoshop uses this approach: first you go through "Save As" and specify where the application should save the file, and which format it should use. You then get a separate dialog box to specify the chosen image format's settings.
- Make the image format options into a preference setting that users must specify in advance, before they issue the Save command. This is dangerous if the options are important, because many users will overlook the need to go through a special step before issuing a command. But for obscure options that most people will never need, the preference route works well because it's less likely to distract or confuse novice users.
The one-dialog design is my preferred solution, because it's the simplest for the common scenario in which users don't want to change the options. Photoshop's two-step design might be better if there are many options or if you need sub-dialogs to specify particularly advanced settings.
The Key Lesson: Consistency
The lesson from this case study is not how to design a better "Save As" dialog. Depending on the circumstances, you could use any of the four designs I listed, or perhaps even design a fifth that works better for your particular type of data. It's easy enough to find out what's best for your users and their tasks: mock up the leading contenders as paper prototypes, and test them with a handful of users.The big lesson here is the need to stick with the design conventions that users know. Whatever design you pick should work in the expected manner.
Don't redesign the meaning of the vocabulary you employ to communicate with users. You can put words together in new ways, as long as you keep using words from the standard language. Just because a GUI uses a visual language of buttons, windows, and the like doesn't change the fact that it's a language. Changing the interaction design primitives has the same effect as writing in Greek to an English-speaking audience.
Learn More
Two full-day courses on dialog box design and deeper application usability issues:- Application Usability 1: Page-Level Building Blocks for Feature Design
- Application Usability 2: Dialogue and Workflow Design
The conference also has several full-day seminars related to ensuring consistency:
- Managing User Experience Strategy
- Design Patterns and Components for User Interfaces