CHAPTER 9: People Can't Read – User Interface Design for Programmers

Can't Read

When you design user interfaces, it's a good idea to keep two principles in mind:

  1. Users don't have the manual, and if they did, they wouldn't read it.
  2. In fact, users can't read anything, and if they could, they wouldn't want to.

These are not, strictly speaking, facts, but you should act as if they are facts, for it will make your program easier and friendlier.

Users don't read the manual.

First of all, they may not actually have the manual. There may not be a manual. If there is one, the user might not have it for all kinds of logical reasons: they're on a plane; they're using a downloaded demo version from your Web site; they're at the beach and the manual is at work; their IS department never gave them the manual. Even if they have the manual, frankly, they are not going to read it unless they absolutely have no other choice (and maybe not even then). With very few exceptions, users will not cuddle up with your manual and read it through before they begin to use your software. In general, your users are trying to get something done, and they see reading the manual as a waste of time, or at the very least, a distraction that keeps them from getting their task done.

The very fact that you're reading this book puts you in an elite group of highly literate people. Yes, I know, people who use computers are by and large able to read, but I guarantee you that a good percentage of them will find reading a chore. The language in which the manual is written may not be their first language, and they may not be totally fluent. They may be kids! They can decipher the manual if they really must, but they sure ain't gonna read it if they don't have to. Users do just-in-time reading on a strictly need-to-know basis.

The upshot of all this is that you probably have no choice but to design your software so it doesn't need a manual in the first place. The only exception I can think of is if your users do not have any domain knowledge—they don't really understand what the program is intended to do, but they know that they better learn. A great example of this is Intuit's immensely popular small-business accounting program, QuickBooks. Many people who use this program are small-business owners who simply have no idea what's involved in accounting. The manual for QuickBooks assumes this and assumes that it will have to teach people basic accounting principles. There's no other way to do it. If a small business owner wants to learn accounting, they actually might just curl up with the QuickBooks manual in a comfortable chair and read it cover to cover. Still, for people who do understand accounting, QuickBooks is reasonably easy to use without the manual.

In fact, users don't read anything.

This may sound a little harsh, but you'll see when you do usability tests that there are quite a few users who simply do not read words that you put on the screen. If you pop up an error box of any sort, they simply will not read it. This may be disconcerting to you as a programmer because you imagine yourself conducting a dialog with the user. "Hey, user!" you say. "You can't open that file, we don't support that file format!" Still, experience shows that the more words you put on a dialog box, the fewer people will actually read it.

The fact that users do not read the manual leads many software designers to assume that they are going to have to educate users by verbosely describing things as they go along. You see this all over the place in programs. In principle it's OK, but in reality, people's aversion to reading means that this will almost always get you in trouble. Experienced UI designers literally try to minimize the number of words in dialogs to increase the chances that they will get read. When I worked on Juno, the UI people understood this principle and tried to write short, clear, simple text. Sadly, the CEO had been an English major at an Ivy League college; he had no training in UI design or software engineering, but he sure thought he was a good editor of prose. So, he vetoed the wording done by the professional UI designers and added a lot of his own verbiage. A typical dialog in Juno looks like the one shown in Figure 9-1. Compare that to the equivalent dialog in Microsoft Windows shown in Figure 9-2.

Intuitively, you might guess that the Juno version, with eighty words of instructions, would be "superior" (in other words, easier to use) than the Windows version with its five words of instructions. In reality, when you run a usability test on this kind of thing, you'll find that:

  1. Advanced users skip over the instructions. They assume they know how to use things and don't have time to read complicated instructions.
  2. Most novice users skip over the instructions. They don't like reading too much and hope that the defaults will be OK.
  3. The few novice users who do earnestly try to read the instructions (some of whom are only reading them because it's a usability test and they feel obliged) are often confused by the sheer number of words and concepts. So, even if they were pretty confident that they would be able to use the dialog when it first came up, the instructions actually confused them even more.

Lesson number one is that if you're an English major from a fancy university, then you are in a whole different league of literacy than the average Joe and you should be very careful about wording dialogs that seem like they might be helpful to you. Shorten it, dumb it down, simplify, get rid of the complicated clauses in parentheses, and do usability tests. But do not write things that look like Ivy League faculty memos. Even adding the word "please" to a dialog, which may seem helpful and polite, will slow people down: the increased bulk of the wording is going to reduce, by some measurable percentage, the number of people who try read the text.


The modem dialog from Juno 4.0. Nobody reads these things.


The equivalent dialog from Microsoft Windows. Although it contains far fewer words, it's much more usable.

Another important point is that many people are intimidated by computers. You probably know this, right? But you may not realize the implications of this. I was watching a friend try to exit Juno. For some reason, she was having quite a bit of trouble. I noticed that when you try to exit Juno, a dialog pops up, as shown in Figure 9-3, saying "Thanks for using Juno. Are you sure you want to exit?"


The Juno exit confirmation dialog doesn't get read, either.

She was hitting No, and then she was kind of surprised that Juno hadn't exited. The very fact that Juno was questioning her choice made her immediately assume that she was doing something wrong. Usually, when programs ask you to confirm a command, it's because you're about to do something that you might regret. She had assumed that if the computer was questioning her judgment, then the computer must have been right, because, after all, computers are computers, whereas she was merely a human, so she hit No.

Is it too much to ask people to read eleven lousy words? Well, apparently. First of all, since exiting Juno has no deleterious effects, Juno should have just exited without prompting for confirmation, like every other GUI program on the planet. But even if you are convinced that it is crucial that people confirm before exiting, you could do it in two words instead of eleven, as shown in Figure 9-4. Without the completely unnecessary "Thank you" and the remorse-inspiring "Are you sure?" this dialog is a lot less likely to cause problems. Users will certainly read the two words, say "um, duh?" to the program and pound the Yes key.


Two words are much more likely to be read than eleven.

Sure, you say, the Juno Exit Confirmation dialog trips up a few people, but is it that big a deal? Everyone will eventually manage to get out of the program. But herein lies the difference between a program that is possible to use versus a program that is easy to use. Even smart, experienced, advanced users will appreciate things that you do to make it easy for the distracted, inexperienced, beginner users. Hotel bathtubs have big grab bars. They're just there to help disabled people, but everybody uses them anyway to get out of the tub. They make life easier, even for the physically fit.

In the next chapter, I'll talk a bit about the mouse. Just as users can't or won't read, users are not very good at using the mouse either, so, you have to accommodate them.