Printable PDF


I turned on my new DVD player and was greeted with a menu called the "root menu." To someone like me who reconfigures Unix kernels just for fun, the root menu was obviously the first menu in a tree of menus and sub menus. But what does that title mean to the general population who isn't as computer savvy? They might not think of a root menu as the base level of a tree-like data structure and be puzzled by the term. The engineer who picked the term was allowing the engineering mind-set to dominate the user-interface design. In this article, we'll explore why this mind-set is not where you want to be when designing a user interface.


Design user interfaces for the user

Engineers have an obligation to plan that users will execute all paths in the code. In an if..else statement, the programmer codes and tests the if branch and gives roughly equal attention to making sure the else case also works. Rarely does the engineer think about how often a user will follow each path, except when optimizing the code—though fast modern processors often negate even this exercise.

Transfer the same thinking to a user interface and you can end up offering the user choices where, to the user, the intended option is overwhelmingly obvious. When you exit many commonly used desktop applications, for instance, you get the option of saving your work, discarding it, or canceling out of the dialog box. Most of the time you'll answer "Yes" to save your work. Occasionally you'll make a slip, press the wrong button (the "No"), and lose your work. On the rare occasion that you intend to discard your work—for example, you want to get rid of what you just changed—it's likely that you'll still answer "Yes" accidentally because you're so used to selecting that answer.

If the designer stopped to think that the user will want to answer "Yes" 99% of the time, they wouldn't bother asking. They could just offer "Yes" or "cancel" and perhaps bury an "Exit Without Saving" option under one of the menus for the unusual case where it's needed. Other alternative solutions to this particularly puerile popup are discussed in Alan Cooper's book, About Face.1

Low-fidelity prototypes


When it comes to usability trials, a more iterative approach is necessary. The more versions you thrown away, the closer you're getting to your ultimate goal. Consider the process to be like that of a photographer who takes a large number of pictures, most of which will never be used. If ten photos are taken, the chances are only one might be good enough to use. If the photographer only takes five, he might miss the one that makes the front page. In photography, the cost of the rejects is very low. Building user-interface prototypes is not so cheap. The compromise is to code early prototypes that are crude.


In low-fidelity prototypes, it's a good idea to minimize the use of color. Avoid icons when you can use the text, since you'll not be using professional graphics designers to produce polished icons at this stage—plus it's not worth your time to make your own. The idea is to define the navigation and functionality of the interface; visual details can be refined later.

Usability testing





Target your audience

Engineers like powerful interfaces. They want to have full control of the technology they're using and will often sacrifice ease-of-use for power. Look at the Unix shell. Many engineers think it's a wonderful tool. I do, too, but wouldn't recommend it to a novice user. Engineers like to be in control, but that may not be true of your target users. Ask an airplane full of people if any of them would be interested in flying the plane. Many of the engineers on board would jump at the chance because they love having all of that technology at their fingertips. But look around at all the people who have no interest. They just want to get from A to B—and leave all the technical complexity to someone else. After all, that's why they paid for their ticket.



Solve the users' problems first



We're solving engineering problems at the expense of the user experience.


These examples show that the extra development or manufacturing cost will eventually be borne by customer. It's important to consider the trade-off in this light—in some cases, spending more to get a more user-friendly device is worth the cost; in other cases, it's not. In general, engineers will consider the right solution to be the one that reduces their engineering effort without factoring usability into the equation. When that happens, the users are the losers.

Get to know the real users


Users will provide lots of detail about how a system is used in practice, but it's also important to understand the motivations of the user. Questionnaires or formal interviews can suppress important input. Sometimes, it's more important to get the user's guard down and listen for anecdotal evidence of user needs.



I was able to get a better feel for exactly how this system was used partly because I spoke to the driver in his ambulance. He was on his own turf. His comfort level was much higher than it would have been if he had been invited to the R&D site to discuss his work habits and our system.

Engineers who rub shoulders with real users often learn that engineering priorities in product design can be worlds away from the needs of those users.


1. Cooper, Alan. About Face: The Essentials of User interface Design. Foster City, CA: IDG Books Worldwide Inc., 1995. [back]

2. Brooks, Frederick. The Mythical Man-Month: Essays on Software Engineering. Reading, MA: Addison-Wesley, 1995. [back]

3. Murphy, Niall. Murphy's Law: "It's Worse on a Browser." Embedded Systems Programming, August 2001, p. 25. [back]