Product usability problems require the engineer to take off his engineering hat and think more like a user.
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.
The problem described above wouldn't have arisen if the product developers had a technical writer write all the text that a user would see, or at least review the text before release. Other usability problems require the engineer to take off his engineering hat and think more like a user.
Design 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
In The Mythical Man-Month, Fredrick Brooks suggests that you build your first design so that you can throw it away.2 In practice, engineers rarely use this discipline. Once a programmer starts to crank out code, the program takes on a life of its own. It takes huge resolve to scrap your work even if you know the project would benefit from a clean slate, for all or part of a system. Both programmers and management find it difficult to believe that there could be benefit in throwing away work that represents a number of man-hours of labor and the associated costs.
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.
Building a limited prototype as HTML pages can be useful to simulate navigation. The user presses a button to follow a hyperlink to another page, which shows the new state of the user interface. Crude prototypes, called low-fidelity prototypes, enable a level of investment low enough to keep the team from balking at the idea of throwing the code away and starting again.
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
Another area where standard engineering perception misleads the developer is in testing. Engineers believe that a test should prove or disprove whether the system meets a requirement. This description is a reasonable view of software testing, where the goal is to identify bugs or places where the software doesn't conform to requirements.
Usability testing, on the other hand, isn't about proving the current system. It's about improving it. This type of testing requires a different approach. At the outset, you may not know what the pass criteria will be, except for something general, such as the average user should be able to figure the system out or use it easily. You may find that the current solution isn't very usable, but the test may or may not furnish you with a solution. If a software test fails, the fix is to make the software meet the already-defined requirements. If a usability test fails, a better solution often means redefining requirements or changing the design that meets those requirements.
Often, the software test team is the first group to see the system as a whole and to be confronted with the system's usability issues. The software test team, however, frequently has no clear mandate to identify usability problems. If the software test team is not mandated to report usability issues, then the software development process should define when these issues will be addressed. Too often, no one takes ownership of this area, and the end user suffers.
Engineers usually categorize usability improvements as enhancements, a categorization that by definition almost always defers or lowers the priority of usability issues in favor of solving software bugs. This approach is often backwards. Consider a piece of numeric data that's displayed on a graphical interface as a pie chart. Testing reveals that for certain values the algorithm that draws the pie chart performs a divide by zero leading to a crash. Use of the full system makes it clear that the data presented would be more clearly understood if displayed as a bar chart. In such a situation, all too often the software crash is given priority. The pie-chart code is fixed, and only later, when the engineers consider "enhancements," do they throw out the pie chart and draw bar charts instead. The effort expended on the pie-chart fix is a waste because a more fundamental design change was made. The philosophy should be to build the right product, before building the product right.
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.
Be careful to avoid designing for engineers and remember that most users won't thank you for exposing them to the technical internals of your design. On the other hand, if your target users are engineers, you should take the opposite tack and give the user as much control as possible, even if it means a slightly steeper learning curve.
At the other end of the scale, marketers often overemphasize the novice user. The priority of the salesman is to convince users that they should make a purchasing decision, and when making that decision, these users may only have tried your device for a couple of minutes. While these first impressions make the initial interactions with the device important, be wary of allowing that to compromise the overall experience.
Solve Users' Problems First
Elegant architecture doesn't always translate to elegant user interfaces. Engineers are sometimes lured by architectures that solve the engineers' problems. For example, a web-based interface enables a range of different types of computers, running different operating systems, to access a device. The web interface spares the development team from writing client software for each client platform. This plan saves considerable engineering effort.
Now consider it from the users' perspective. The user experience on a browser will always be inferior to the experience of using a dedicated application. Just compare using web mail to using a mail client such as Outlook or Eudora. I discuss other drawbacks of the browser interface in my Embedded Systems Programming column of August, 2001.3
We're solving engineering problems at the expense of the user experience.
Another example of solving the wrong problem is a design of a front panel that has icons only and no text defining the icons. This design enables the manufacturers to sell the same panel in all international markets with huge savings for manufacturing and distribution if they can avoid having a different product variant for each language. But icons are often less understandable than the equivalent English or German or Japanese text. The user now has to learn the meaning of the icons before being comfortable using the device. Again, we've solved an engineering problem at the expense of usability.
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
When I teach usability classes, I often ask by show of hands how many of the students have met a real end user in the last few months. Numbers vary widely, but it's clear to me that many engineers never meet the people who use the product. For some engineering roles this may not be necessary, but for anyone making design decisions that affect usability, it's vital to have a good feeling for how the system will be used in real life—often a far cry from the way the official documents describe it.
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.
On one occasion, I was sitting in an ambulance with a driver. We were discussing an in-vehicle video recording system which was connected to a panic button. If a patient has to be restrained, a paramedic can press the panic button to record the incident, so if the patient later claims assault, the video evidence can be used to protect the paramedic from false or exaggerated claims. Protocol dictates that once an incident has been recorded, that ambulance can not go on the road again until the fleet supervisor has copied the video recording to an archive, regardless of the nature of the incident that led to the panic button being pressed.
Many of these incidents occur late at night, and dealing with an injured drunk is not an enviable job. The driver pointed out that sometimes the hassle of getting the video copied after a trip reduced the amount of time the ambulance spent on the road. His solution, when the patient got a bit rough was to make sure the camera was off, and then give the patient a few good punches, which usually calmed them down a bit. Some readers may choose to pass moral judgment on paramedics who occasionally give their patients a thrashing, though people who spend their nights breaking up drunken brawls would probably be more forgiving. Fear of such judgment is exactly why this important feedback wouldn't have come to light if the same user had been interviewed in more formal circumstances. If we asked in a questionnaire how often each of the paramedics punched a patient, the answers would have been uniform zeros. The customer requirements fed to us by the driver's supervisor would certainly not make any reference to this behavior.
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.
Endnotes
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]
