Designing Interfaces

Chapter 1. What Users Do

This book is almost entirely about the look and behavior of applications, web applications, and interactive devices. But this first chapter will be the exception to the rule. No screenshots here; no layouts, no navigation, no diagrams, and no visuals at all.

Why not? After all, that's why you may have picked up this book in the first place.

It's because good interface design doesn't start with pictures. It starts with an understanding of people: what they're like, why they use a given piece of software, and how they might interact with it. The more you know about them, and the more you empathize with them, the more effectively you can design for them. Software, after all, is merely a means to an end for the people who use it. The better you satisfy those ends, the happier those users will be.

Each time someone uses an application, or any digital product, they carry on a conversation with the machine. It may be literal, as with a command line or phone menu, or tacit, like the "conversation" an artist has with her paints and canvas—the give and take between the craftsperson and the thing being built. With social software, it may even be a conversation by proxy. Whatever the case, the user interface mediates that conversation, helping the user achieve whatever ends he or she had in mind.

As the user interface designer, then, you get to script that conversation, or at least define its terms. And if you're going to script a conversation, you should understand the human's side as well as possible. What are the user's motives and intentions? What "vocabulary" of words, icons, and gestures does the user expect to use? How can the application set expectations appropriately for the user? How do the user and the machine finally end up communicating meaning to each other?

There's a maxim in the field of interface design: "Know thy users, for they are not you!"

So this chapter will talk about people. It covers a few fundamental ideas briefly in this introduction, and then discusses the patterns themselves. These patterns differ from those in the rest of the book. They describe human behaviors—as opposed to system behaviors—that the software you design may need to support. Software that supports these human behaviors help users achieve their goals.

A MEANS TO AN END

Everyone who uses a tool, software or otherwise, has a reason to use it. For instance:

• Finding some fact or object

• Learning something

• Performing a transaction

• Controlling or monitoring something

• Creating something

• Conversing with other people

• Being entertained

Well-known idioms, user behaviors, and design patterns can support each of these abstract goals. Interaction designers have learned, for example, how to help people search through vast amounts of online information for specific facts. They've learned how to present tasks so that it's easy to walk through them. They are learning ways to support the building of documents, illustrations, and code.

The first step in designing an interface is figuring out what its users are really trying to accomplish. Filling out a form, for example, almost never is a goal in and of itself—people only do it because they're trying to buy something online, get their driver's license renewed, or install a networked printer.^[1] They're performing some kind of transaction.

Asking the right questions can help you connect user goals to the design process. Users and clients typically speak to you in terms of desired features and solutions, not of needs and problems. When a user or client tells you he wants a certain feature, ask why he wants it—determine his immediate goal. Then, to the answer of this question, ask "why" again. And again. Keep asking until you move well beyond the boundaries of the immediate design problem.^[2]

Why should you ask these questions if you have clear requirements? Because if you love designing things, it's easy to get caught up in an interesting interface-design problem. Maybe you're good at building forms that ask for just the right information, with the right controls, all laid out nicely. But the real art of interface design lies in solving the right problem.

So don't get too fond of designing that form. If there's any way to finish the transaction without making the user go through that form at all, get rid of it altogether. That gets the user closer to his goal, with less time and effort spent on his part. (And maybe yours, too.)

Let's use the "why" approach to dig a little deeper into some typical design scenarios.

• Why does a mid-level manager use an email client? Yes, of course—"to read email." Why does she read and send email in the first place? To converse with other people. Of course, other means might achieve the same ends: the phone, a hallway conversation, a formal document. But apparently email fills some needs that the other methods don't. What are they, and why are they important to her? Privacy? The ability to archive a conversation? Social convention? What else?

• A father goes to an online travel agent, types in the city where his family will take a summer vacation, and tries to find plane ticket prices on various dates. He's learning from what he finds, but his goal isn't just browsing and exploring different options. Ask why. His goal is actually a transaction: buying plane tickets. Again, he could have done that at many different web sites, or over the phone with a live travel agent. How is this site better than those other options? Is it faster? Friendlier? More likely to find a better deal?

• A cell phone user wants a way to search through his phone list more quickly. You, as the designer, can come up with some clever ideas to save keystrokes while searching. But why did he want it? It turns out that he makes a lot of calls while driving, and he doesn't want to take his eyes off the road more than he has to—he wants to make calls while staying safe (to the extent that that's possible). The ideal case is that he doesn't have to look at the phone at all! A better solution is voice dialing: all he has to do is speak the name, and the phone makes the call for him.

• Sometimes goal analysis really isn't straightforward at all. A snowboarding site might provide information (for learning), an online store (transactions), and a set of Flash movies (entertainment). Let's say someone visits the site for a purchase, but she gets sidetracked into the information on snowboarding tricks—she switched goals from accomplishing a transaction to browsing and learning. Maybe she'll go back to purchasing something, maybe not. And does the entertainment part of the site successfully entertain both the twelve-year-old and the thirty-five-year-old? Will the thirty-five-year-old go elsewhere to buy his new board if he doesn't feel at home there, or does he not care?

It's deceptively easy to model users as a single faceless entity—"The User"—walking through a set of simple use cases, with one task-oriented goal in mind. But that won't necessarily reflect your users' reality.

To do design well, you need to take many "softer" factors into account: gut reactions, preferences, social context, beliefs, and values. All of these factors could affect the design of an application or site. Among these "softer" factors, you may find the critical feature or design factor that makes your application more appealing and successful.

So be curious. Specialize in it. Find out what your users are really like, and what they really think and feel.

---

^[1] See Eric Raymond's essay, "The Luxury of Ignorance: An Open-Source Horror Story," about his travails with a Linux print utility at http://www.catb.org/~esr/writings/cups-horror.html.

^[2] This is the same principle that underlies a well-known technique called "root cause analysis." However, root cause analysis is a tool for fixing organizational failures; here, you use its "five whys" (more or less) to understand everyday user behaviors and feature requests.