Scott Berkun
Microsoft Corporation
March/April 1999
Summary: The first part of a two-part Human Factor column. Offers a process for designing good user interfaces. (3 printed pages)
During the development of a product I'm the only resource for making user interface design decisions, simply because I'm the developer that's writing the user interface code. Most of the time there is great time pressure to complete the project, and any testers or documentation writers working on the project press hard for decisions to be made fast so they can start doing their jobs. In the frenzy of software development, how can we make sure that our product has a good user interface before it's too late? We want to do the right thing, but we're afraid it will take us a lot more time, which we don't have.
—Steve K. Johnson, TBDSystems, Chicago Illinois
At Microsoft we have full-time employees, called usability engineers, who are trained to help product teams understand what the user's needs are, and analyze how well our product user interfaces match those needs. They do a great deal of work, and understand the discipline of UI design and data collection really well. They are critical to the success of our products. As I've learned from the e-mail I've been getting at hfactor@microsoft.com, most developers don't have the luxury of this kind of support, and are on their own to make good interface design decisions. This issue will introduce a basic development process that helps good UI make it into products. Word of warning: There is no magic recipe for good UI, or for writing good code, and I can't guarantee improved interfaces without some extra effort. This is the first of a two-part series on usability. Next issue, I'll provide some resources for those who want more in-depth information on the steps described in this article.
The most important step toward good interface design is understanding the problems your users need you to solve. Specifications for projects are often created in a vacuum: Managers or executives decide that product X or feature Y is critically important, but not much research is conducted into what the real users of the product need or want. Before you start writing code, you need to understand who your users are, what they do all day, and what problems they have with whatever it is your product is going to replace. If you were a tailor, you wouldn't make a tuxedo without first getting the customer's measurements. Understanding the user is important for all products, including software. Even if your project is the first version, potential users of your product are currently doing their job in some other way, and you want to understand the good and bad about whatever it is you are replacing. There are many ways to collect this kind of information, varying in cost, quality, and time required.
The simplest and most informal approach is talking to the intended users of the product. Get information directly from the source as to their work habits, their experience levels, and the problems they struggle with to get their jobs done. Avoid using managers or executives as proxies for what the real consumers' needs are. The users may not understand anything about computer code, but they are experts at whatever it is they do. It's common for small groups of developers and program managers at Microsoft to pay informal visits to users in their workplaces, with the rule that we cannot offer them any help. This gives us a chance to talk with people, discuss how they work, and absorb all the details of the problems they are facing with our products and their jobs. Even if you are short on time, pick a small handful of real users to work with and observe. Working with three or five real users is significantly better than working with none.
Roll the data and anecdotal comments from users into digestible nuggets. If you know that almost half of the users you asked complained about how hard it was to reset a form field in the data processing dialog box, write down a nugget like "Resetting forms is too hard." Repeat this for all of the data that you have. While you're putting the information into nuggets, avoid thinking about solutions. You want to make sure that you get to the root of the problems and not just patch over the symptoms. If you jump too quickly into problem solving, you'll miss the simple ideas that may solve a lot of problems at the same time.
Once you've collected a list of problem nuggets, you should check back with your users. Prioritize the list of problems and send out a short summary by e-mail to the people you talked to. This is a good time for a checkpoint with management or executives—with the list of nuggets, you can describe exactly what problems the product will solve and emphasize that it's based on real user data. The list of nuggets is a great way to deflect random ideas—when your coworker suggests implementing his spifforama-widget idea, you can tell him with confidence that it really doesn't solve the problems that your users need to have solved. The problem list sets the direction the product needs to take, ensuring that all of your development work will be targeted in the right place. Determining what problems need to be solved is often much more difficult than the act of designing the solution.
Designing user interfaces is not a scientific or algorithmic task. There are some rules that I'll cover in future columns, but at best the rules are general and require that you fill in many details. For success in any design problem, it's critical that many ideas are sketched out and considered before the product goes out the door. As many of today's Web sites and software products show, a lot of design ideas turn out to be pretty lame. Bad designs are often the result of too few attempts, not necessarily bad designers. Trying out many ideas is something all good designers do; the trick is to do it without wasting a lot of time or throwing away a lot of code.
Working from the list of problems you created, use the layout editor in Microsoft® Visual Basic®, Microsoft Visual C++®, or even Microsoft Paint, to sketch out different ways to create a user interface to solve the problem. Using paper and pencil is fine too—just be careful not to put too much faith in an idea that doesn't have any pixels. Lots of tricky details crop up when you move from pencil to the real thing. You want to try out as many ideas as you can and you don't want to feel bad about sketching out bad ones. The more ideas you try, the greater the likelihood of creating and recognizing a good one. A good idea is one that solves some or all of the user problems you've defined. The throwaway work can be used to show coworkers and clients that the idea you've picked is relatively good compared to the alternatives, so hold on to them. When I'm working on UI, I start with a wild pile of different ideas and then group similar ones together, shooting for three to five groups. Next I write a simple pro/con list for each group to help express how the designs compare and show the list to teammates to generate more thoughts.
As time closes in, start looking for shared work in the approaches you think have value. If every good approach requires the same frizz-o-matic database widget, go build that first. This buys you time to keep thinking and iterating on which UI approach to choose. This is standard operating procedure: Make sure that development is progressing well, but simultaneously give the hard UI problems sufficient time to bake. Flesh out your best one or two ideas in detailed bitmaps or semifunctional prototypes. Prototypes don't need to be exhaustive, just do enough work to effectively simulate the experience of using the real thing. For static items like a dialog box, bitmaps are enough. For multistep features like writing and printing a report, a prototype is the only way to simulate the real flow the user will experience. It's better to learn about your design problems from your prototype than from your final product.
The more real users you work with at this stage, the more valuable the feedback will be. By talking with and observing enough users, you'll have a feel for which issues are general trends and which are random comments. Apply the useful feedback to your ideas, and update them. Try out a new set of changes based on the feedback, and repeat the process as many times as you can. Each iteration will be a distinct improvement over the last, provided you've been generating good feedback and trying out a wide set of ideas.
That's all for now. Next time I'll describe the last few steps, and provide resources for those who want to learn the powerful in-depth techniques for each step in the process.
Find this interesting, useful, or have a column idea or question? Send mail to hfactor@microsoft.com with your comments and questions.