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.
Everyone who uses a tool, software or otherwise, has a reason to use it. For instance:
Finding some fact or object
Performing a transaction
Controlling or monitoring something
Conversing with other people
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. 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.
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.
Empirical discovery is the only really good way to obtain this information. To get a design started, you’ll need to characterize the kinds of people who will use whatever you design (including the “softer” categories just mentioned), and the best way to do that is to go out and meet them.
Each user group is unique, of course. The target audience for, say, a new cell phone will differ dramatically from that for a piece of scientific software. Even if the same person uses both, his expectations for each are different—a researcher using scientific software might tolerate a less-polished interface in exchange for high functionality, whereas that same person may trade in his new phone if he finds its UI to be too hard to use after a few days.
Every user is unique, too. What one person finds difficult, the next one won’t. The trick is to figure out what’s generally true about your users, which means learning about enough individual users to separate the quirks from the common behavior patterns.
Specifically, you’ll want to learn:
Their goals in using the software you design
The specific tasks they undertake in pursuit of those goals
The language and words they use to describe what they’re doing
Their skill at using software similar to what you’re designing
Their attitudes toward the kind of thing you’re designing, and how different designs might affect those attitudes
I can’t tell you what your particular target audience is like. You need to find out what they might do with the software you design, and how it fits into the broader context of their lives. Difficult though it may be, try to describe your potential audience in terms of how and why they might use your software. You might get several distinct answers, representing distinct user groups; that’s okay. You might be tempted to throw up your hands and say, “I don’t know who the users are,” or, “Everyone is a potential user.” That doesn’t help you focus your design at all—without a concrete and honest description of those people, your design will proceed with no grounding in reality.
Unfortunately, this user-discovery phase will consume serious time early in the design cycle. It’s expensive, but always worth it, because you stand a better chance at solving the right problem—you’ll build the right thing in the first place.
Interviews and on-site user visits put you directly into the user’s world. You can ask users about what their goals are and what tasks they typically do. Usually done “on location,” where users would actually use the software (e.g., in a workplace or at home), interviews can be structured—with a predefined set of questions—or unstructured, in which you might probe whatever subject comes up. Interviews give you a lot of flexibility; you can do many or a few, long or short, formal or informal, on the phone or in person. These are great opportunities to learn what you don’t know. Ask why. Ask it again.
Case studies give you deep, detailed views into a few representative users or groups of users. You can sometimes use them to explore “extreme” users that push the boundaries of what the software can do, especially when the goal is a redesign of existing software. You also can use them as longitudinal studies—exploring the context of use over weeks, months, or even years. Finally, if you design custom software for a single user or site, you’ll want to learn as much as possible about the actual context of use.
Written surveys can collect information from many users. You can actually get statistically significant numbers of respondents with these. Since there’s no direct human contact, you will miss a lot of extra information—whatever you don’t ask about, you won’t learn about—but you can get a very clear picture of certain aspects of your target audience. Careful survey design is essential. If you want reliable numbers instead of a qualitative “feel” for the target audience, you absolutely must write the questions correctly, pick the survey recipients correctly, and analyze the answers correctly—and that’s a science.
Personas aren’t a data-gathering method, but they do help you figure out what to do with that data once you’ve got it. This is a design technique that “models” the target audiences. For each major user group, you create a fictional person that captures the most important aspects of the users in that group: what tasks they’re trying to accomplish, their ultimate goals, and their experience levels in the subject domain and with computers in general. They help you stay focused. As your design proceeds, you can ask yourself questions like, “Would this fictional person really do X? What would she do instead?”
And there’s more. You might notice that some of these methods and topics, like interviews and surveys, sound suspiciously like marketing activities. That’s exactly what they are. Focus groups can be useful too (though not so much as the others), and the concept of market segmentation resembles the definition of target audiences we’ve used here. In both cases, the whole point is to understand the audience as best you can.
The difference is that as a designer, you’re trying to understand the people who use the software. A marketing professional tries to understand those who buy it.
It’s not easy to understand the real issues that underlie users’ interaction with a system. Users don’t always have the language or introspective skill to explain what they really need to accomplish their goals, and it takes a lot of work on your part to ferret out useful design concepts from what they can tell you—self-reported observations usually are biased in subtle ways.
Some of these techniques are very formal, and some aren’t. Formal and quantitative methods are valuable because they’re good science. When applied correctly, they help you see the world as it actually is, not how you think it is. If you do user research haphazardly, without accounting for biases like the self-selection of users, you may end up with data that doesn’t reflect your actual target audience—and that can only hurt your design in the long run.
But if you don’t have time for formal methods, it’s better to just meet a few users informally than to not do any discovery at all. Talking with users is good for the soul. If you’re able to empathize with users and imagine those individuals actually using your design, you’ll produce something much better.
Before you start the design process, consider your overall approach. Think about how you might design its overall interaction style—its personality, if you will.
When you carry on a conversation with someone about a given subject, you adjust what you say according to your understanding of the other person. You might consider how much he cares about the subject, how much he already knows about it, how receptive he is to learning from you, and whether he’s even interested in the conversation in the first place. If you get any of that wrong, then bad things happen—he might feel patronized, uninterested, impatient, or utterly baffled.
This analogy leads to some obvious design advice. The subject-specific vocabulary you use in your interface, for instance, should match your users’ level of knowledge; if some users won’t know that vocabulary, give them a way to learn the unfamiliar terms. If they don’t know computers very well, don’t make them use sophisticated widgetry or uncommon interface-design conventions. If their level of interest might be low, respect that, and don’t ask for too much effort for too little reward.
Some of these concerns permeate the whole interface design in subtle ways. For example, do your users expect a short, tightly focused exchange about something very specific, or do they look for a conversation that’s more of a free-ranging exploration? In other words, how much openness is there in the interface? Too little, and your users feel trapped and unsatisfied; too much, and they stand there paralyzed, not knowing what to do next, unprepared for that level of interaction.
Therefore, you need to choose how much freedom your users have to act arbitrarily. At one end of the scale might be a software installation wizard: the user is carried through it with no opportunity to use anything other than Next, Previous, or Cancel. It’s tightly focused and specific, but quite efficient—and satisfying, to the extent that it works and is quick. At the other end might be an application like Excel, an “open floor plan” interface that exposes a huge number of features in one place. At any given time, the user has about 872 things that she can do next, but that’s considered good because self-directed, skilled users can do a lot with that interface. Again, it’s satisfying, but for entirely different reasons.
Here’s an even more fundamental question: how much effort are your users willing to spend to learn your interface?
It’s easy to overestimate. Maybe they use it every day on the job—clearly they’d be motivated to learn it well in that case, but that’s rare. Maybe they use it sometimes, and learn it only well enough to get by. Maybe they’ll only see it once, for 30 seconds. Be honest: can you expect most users to become intermediate-to-expert users, or will most users remain perpetual beginners?
Software designed for intermediate-to-expert users include:
Code development environments
System-administration tools for web servers
In contrast, here are some things designed for occasional users:
The differences between the two groups are dramatic. Assumptions about users’ tool knowledge permeate these interfaces, showing up in their screen-space usage, labeling, widget sophistication, and the places where help is (or isn’t) offered.
The applications in the first group have lots of complex functionality, but they don’t generally walk the user through tasks step-by-step. They assume users already know what to do, and they optimize for efficient operation, not learnability; they tend to be document-centered or list-driven (with a few being command-line applications). They often have entire books and courses written about them. Their learning curves are steep.
The applications in the second group are the opposite: restrained in functionality but helpful about explaining it along the way. They present simplified interfaces, assuming no prior knowledge of document- or list-centered application styles (e.g., menu bars, multiple selection, etc.). Wizards frequently show up, removing attention-focusing responsibility from the user. The key is that users aren’t motivated to work hard at learning these interfaces—it’s usually just not worth it!
Now that you’ve seen the extremes, look at the applications in the middle of the continuum:
The truth is, most applications fall into this middle ground. They need to serve people on both ends adequately—to help new users learn the tool (and satisfy their need for instant gratification), while enabling frequent-user intermediates to get their work done smoothly. Their designers probably knew that people wouldn’t take a three-day course to learn an email client. Yet the interfaces hold up under repeated usage. People quickly learn the basics, reach a proficiency level that satisfies them, and don’t bother learning more until they are motivated to do so for specific purposes.
Alan Cooper coined the terms "sovereign posture” and "transient posture” to discuss these approaches. Sovereign-posture applications work with users as partners; users spend time in them, give them their full attention, learn them well, and expand them to full-screen size. Transient-posture programs are brought up briefly, used, and dismissed. These roughly correspond to the two extremes I posited, but not entirely. See the book About Face 2.0: The Essentials of Interaction Design for a more nuanced explanation of postures.
Someday you will find yourself in tension between the two ends of this spectrum. Naturally you want people to be able to use your application “out of the box,” but you also might want to support frequent or expert users as much as possible. Find a balance that works for your situation. Organizational patterns in Chapter 2 such as Multi-Level Help, Intriguing Branches, and Extras on Demand can help you serve both constituencies.
Even though individuals are unique, people behave predictably. Designers have been doing site visits and user observations for years; cognitive scientists and other researchers have spent many hundreds of hours watching how people do things and how they think about what they do.
So when you observe people using your software, or performing whatever activity you want to support with new software, you can expect them to do certain things. The behavioral patterns listed below often are seen in user observations. Odds are good that you’ll see them too, especially if you look for them.
A note for patterns enthusiasts: These patterns aren’t like the others in this book. They describe human behaviors, not interface elements, and they’re not prescriptive like the patterns in other chapters. Instead of being structured like the other patterns, these are presented as small essays.
Again, an interface that supports these patterns well will help users achieve their goals far more effectively than interfaces that don’t support them. And the patterns are not just about the interface, either. Sometimes the entire package—interface, underlying architecture, feature choice, and documentation—needs to be considered in light of these behaviors. But as the interface designer or interaction designer, you should think about these as much as anyone on your team. You may be in the best position to advocate for the users.
“Let me explore without getting lost or getting into trouble.”
When someone feels like she can explore an interface and not suffer dire consequences, she’s likely to learn more—and feel more positive about it—than someone who doesn’t explore. Good software allows people to try something unfamiliar, back out, and try something else, all without stress.
Those “dire consequences” don’t even have to be very bad. Mere annoyance can be enough to deter someone from trying things out voluntarily. Clicking away popup windows, re-entering data mistakenly erased, suddenly muting the volume on one’s laptop when a web site unexpectedly plays loud music—all can be discouraging. When you design almost any kind of software interface, make many avenues of exploration available for users to experiment with, without costing the user anything.
Here are some examples:
A photographer tries out a few image filters in an image-processing application. He then decides he doesn’t like the results and hits “Undo” a few times to get back to where he was. Then he tries another filter, and another—each time being able to back out of what he did. (The pattern named Multi-Level Undo, in Chapter 5, describes how this works.)
A new visitor to a company’s home page clicks various links just to see what’s there, trusting that the Back button will always get her back to the main page. No extra windows or popups open, and the Back button keeps working predictably. You can imagine that if a web application does something different in response to the Back button—or if an application offers a button that seems like a Back button, but doesn’t behave quite like it—then confusion might ensue. The user can get disoriented while navigating, and may abandon the application altogether.
A cell phone user wants to try out some intriguing new online functionality, like getting sports scores for the World Series in real time. But he’s hesitant to try it because the last time he used an online service, he was charged an exorbitant amount of money just for experimenting with it for a few minutes.
“I want to accomplish something now, not later.”
People like to see immediate results from the actions they take—it’s human nature. If someone starts using an application and gets a “success experience” within the first few seconds, that’s gratifying! He’ll be more likely to keep using it, even if it gets harder later. He will feel more confident in the application, and more confident in himself, than if it had taken a while to figure things out.
The need to support instant gratification has many design ramifications. For instance, if you can predict the first thing a new user is likely to do, then you should design the UI to make that first thing stunningly easy. If the user’s goal is to create something, for instance, then show a new canvas and put a palette next to it. If the user’s goal is to accomplish some task, point the way toward a typical starting point.
It also means that you shouldn’t hide introductory functionality behind anything that needs to be read or waited for, such as registrations, long sets of instructions, slow-to-load screens, or advertisements. These are discouraging because they block users from finishing that first task quickly.
“This is good enough. I don’t want to spend more time learning to do it better.”
When people look at a new interface, they don’t read every piece of it methodically and then decide, “Hmmm, I think this button has the best chance of getting me what I want.” Instead, a user will rapidly scan the interface, pick whatever he sees first that might get him what he wants, and try it—even if it might be wrong.
The term "satisficing” is a combination of “satisfying” and “sufficing.” It was devised in 1957 by the social scientist Herbert Simon, who used it to describe the behavior of people in all kinds of economic and social situations. People are willing to accept “good enough” instead of “best” if learning all the alternatives might cost time or effort.
Satisficing is actually a very rational behavior, once you appreciate the mental work necessary to “parse” a complicated interface. As Steve Krug points out in his book Don’t Make Me Think, (New Riders) people don’t like to think any more than they have to—it’s work! But if the interface presents an obvious option or two that the user sees immediately, he’ll try it. Chances are good that it will be the right choice, and if not, there’s little cost in backing out and trying something else (assuming that the interface supports Safe Exploration).
This means several things for designers:
Make labels short, plainly worded, and quick to read. (This includes menu items, buttons, links, and anything else identified by text.) They’ll be scanned and guessed about; write them so that a user’s first guess about meaning is correct. If he guesses wrong several times, he’ll be frustrated and you’re both off to a bad start.
Use the layout of the interface to communicate meaning. Chapter 4, Layout, explains how to do so in detail. Users “parse” color and form on sight, and they follow these cues more efficiently than labels that must be read.
Make it easy to move around the interface, especially for going back to where a wrong choice might have been made hastily. Provide "escape hatches” (see Chapter 3). On typical web sites, using the Back button is easy, so designing easy forward/backward navigation is especially important for web applications, but it’s also important for installed applications and devices.
Satisficing is why many users end up with odd habits after they’ve been using a system for a while. Long ago, a user may have learned Path A to do something, and even though a later version of the system offers Path B as a better alternative (or was there all along), he sees no benefit in learning it—that takes effort, after all—and he keeps using the less-efficient Path A. It’s not necessarily an irrational choice. Breaking old habits and learning something new takes energy, and a small improvement may not be worth the cost to the user.
“I changed my mind about what I was doing.”
Occasionally, people change what they’re doing in the middle of doing it. Someone may walk into a room with the intent of finding a key she had left there, but while she’s there, she finds a newspaper and starts reading it. Or she may visit Amazon to read product reviews, but ends up buying a book instead. Maybe she’s just sidetracked; maybe the change is deliberate. Either way, the user’s goal changes while she’s using the interface you designed.
What this means for designers is that you should provide opportunities for people to do that. Make choices available. Don’t lock users into a choice-poor environment with no global navigation, or no connections to other pages or functionality, unless there’s a good reason to do so. Those reasons do exist. See the patterns called Wizard (Chapter 2), Hub and Spoke (Chapter 3), and Modal Panel (Chapter 3) for examples.
You also can make it easy for someone to start a process, stop in the middle, and come back to it later to pick up where he left off—a property often called “reentrance.” For instance, a lawyer may start entering information into a form on a PDA. Then when a client comes into the room, the lawyer has to turn off the PDA with the intent of coming back to finish the form later. The entered information shouldn’t be lost.
To support reentrance, you can make dialog boxes remember values typed previously (see Good Defaults in Chapter 7), and they don’t usually need to be modal; if they’re not modal, a user can drag them aside on the screen for later use. Builder-style applications—text editors, code development environments, and paint programs—can let a user work on multiple projects at one time, thus letting the user put any number of projects aside while she works on another one.
Online surveys hosted by surveymonkey.com sometimes offer a button on each page of a survey that says, “I’ll finish it later.” This button closes the browser page, records the choices made up to that point, and lets the user come back to finish the survey later.
“I don’t want to answer that now; just let me finish!”
This follows from people’s desire for instant gratification. If you ask a user several seemingly unnecessary questions while he’s trying to get something done, he’d often rather skip the questions and come back to them later.
For example, some web-based bulletin boards have long and complicated procedures for registering users. Screen names, email addresses, privacy preferences, avatars, self-descriptions…the list goes on and on. “But I just wanted to post one little thing,” says the user plaintively. Why not skip most of the questions, answer the bare minimum, and come back later (if ever) to fill in the rest? Otherwise he might be there for half an hour answering essay questions and finding the perfect avatar image.
Another example is creating a new project in Dreamweaver or other web site editors. There are some things you do have to decide up front, like the name of the project, but you can defer other choices easily—where on the server are you going to put this when you’re done? I don’t know yet!
Sometimes it’s just a matter of not wanting to answer the questions. At other times, the user may not have enough information to answer yet. What if a music-writing software package asked you up front for the title, key, and tempo of a new song, before you’ve even started writing it? (See Apple’s GarageBand for this lovely bit of design.)
The implications for interface design are simple to understand, though not always easy to implement:
Don’t accost the user with too many upfront choices in the first place.
On the forms that he does have to use, clearly mark the required fields, and don’t make too many of them required. Let him move on without answering the optional ones.
Sometimes you can separate the few important questions or options from others that are less important. Present the short list; hide the long list. See the Extras on Demand pattern in Chapter 2.
Use Good Defaults (Chapter 7) wherever possible, to give users some reasonable default answers to start with. But keep in mind that prefilled answers still require the user to look at them, just in case they need to be changed. They have a small cost, too.
Make it possible for users to return to the deferred fields later, and make them accessible in obvious places. Some dialog boxes show the user a short statement such as “You can always change this later by clicking the Edit Project button.” Some web sites store a user’s half-finished form entries or other persistent data, like shopping carts with unpurchased items.
If registration is required at a web site that provides useful services, users may be far more likely to register if they’re first allowed to experience the web site—drawn in and engaged—and then asked later about who they are. In fact, TurboTax 2005 allows a user to work through an entire tax form before creating a username.
“Let me change this. That doesn’t look right; let me change it again. That’s better.”
When people create things, they don’t usually do it all at once. Even an expert doesn’t start at the beginning, work through the creation process methodically, and come out with something perfect and finished at the end.
Quite the opposite. Instead, she starts with some small piece of it, works on it, steps back and looks at it, tests it (if it’s code or some other “runnable” thing), fixes what’s wrong, and starts to build other parts of it. Or maybe she starts over if she really doesn’t like it. The creative process goes in fits and starts. It moves backwards as much as forwards sometimes, and it’s often incremental, done in a series of small changes instead of a few big ones. Sometimes it’s top-down; sometimes it’s bottom-up.
Builder-style interfaces need to support that style of work. Make it easy to build small pieces one at a time. Keep the interface responsive to quick changes and saves. Feedback is critical: constantly show the user what the whole thing looks and behaves like while the user works. If you deal with code, simulations, or other executable things, make the “compile” part of the cycle as short as possible so the operational feedback feels immediate—leave little or no delay between the user making changes and seeing the results.
When good tools support creative activities, the activities can induce a state of “flow” in the user. This is a state of full absorption in the activity, during which time distorts, other distractions fall away, and the person can remain engaged for hours—the enjoyment of the activity is its own reward. Artists, athletes, and programmers all know this state.
Bad tools will keep someone distracted, guaranteed. If the user has to wait even half a minute to see the results of the incremental change she just made, then her concentration is broken; flow is disrupted.
If you want to read more about flow, look at the books by Mihaly Csikszentmihalyi, who studied it for years.
“That gesture works everywhere else; why doesn’t it work here, too?”
When one uses an interface repeatedly, some frequently used physical actions become reflexive: typing Control-S to save a document, clicking the Back button to leave a web page, pressing Return to close a modal dialog box, using gestures to show and hide windows, or even pressing a car’s brake pedal. The user no longer needs to think consciously about these actions. They’ve become habitual.
This tendency certainly helps people become expert users of a tool (and it helps create a sense of flow, too). Habituation measurably improves efficiency, as you can imagine. But it can also lay traps for the user. If a gesture becomes a habit and the user tries to use it in a situation when it doesn’t work—or, worse, does something destructive—then the user is caught short. He suddenly must think about the tool again (What did I just do? How do I do what I intended?), and he might have to undo any damage done by the gesture.
For instance, Control-X, Control-S is the “save this file” key sequence used by the emacs text editor. Control-A moves the text-entry cursor to the beginning of a line. These acts become habitual for emacs users. When a user types Control-A, Control-X, Control-S at emacs, it performs a fairly innocuous pair of operations.
Now what happens when he types that same habituated sequence in Microsoft Word?
Control-A: select all
Control-X: cut the selection (the whole document, in this case)
Control-S: save the document (whoops)
This is why consistency across applications is important!
Just as important, though, is consistency within an application. Some applications are evil because they establish an expectation that some gesture will do Action X, except in one special mode, where it suddenly does Action Y. Don’t do that. It’s a sure bet that users will make mistakes, and the more experienced they are—i.e., the more habituated they are—the more likely they are to make that mistake.
This is also why confirmation dialog boxes often don’t work to protect a user against accidental changes. When modal dialog boxes pop up, the user can easily get rid of them just by clicking “OK” or hitting Return (if the OK button is the default button). If dialogs pop up all the time when the user is making intended changes, such as deleting files, it becomes a habituated response. Then when it actually matters, the dialog box doesn’t have any effect, because it slips right under the user’s consciousness.
I’ve seen at least one application that sets up the confirmation dialog box’s buttons randomly from one invocation to another. One actually has to read the buttons to figure out what to click! This isn’t necessarily the best way to do a confirmation dialog box—in fact, it’s better to not have them at all under most circumstances—but at least this design sidesteps habituation creatively.
“I swear that button was here a minute ago. Where did it go?”
When people manipulate objects and documents, they often find them again later by remembering where they are, not what they’re named.
Take the Windows, Mac, or Linux desktop. Many people use the desktop background as a place to put documents, frequently used applications, and other such things. It turns out that people tend to use spatial memory to find things on the desktop, and it’s very effective. People devise their own groupings, for instance, or recall that “the document was at the top right over by such-and-such.” (Naturally, there are real-world equivalents too. Many people’s desks are “organized chaos,” an apparent mess in which the office owner can find anything instantly. But heaven forbid that someone should clean it up for them.)
Many applications put their dialog buttons—OK, Cancel, etc.—in predictable places, partly because spatial memory for them is so strong. In complex applications, people also may find things by remembering where they are relative to other things: tools on toolbars, objects in hierarchies, and so on. Therefore, you should use patterns like Responsive Disclosure (Chapter 4) carefully. Adding something to an interface doesn’t usually cause problems, but rearranging existing controls can disrupt spatial memory and make things harder to find. It depends. Try it out on your users if you’re not sure.
Along with habituation, which is closely related, spatial memory is another reason why consistency across and within applications is good. People may expect to find similar functionality in similar places.
Spatial memory explains why it’s good to provide user-arranged areas for storing documents and objects, like the aforementioned desktops. Such things aren’t always practical, especially with large numbers of objects, but it works quite well with small numbers. When people arrange things themselves, they’re likely to remember where they put them. (Just don’t rearrange things for them unless they ask!) The Movable Panels pattern in Chapter 4 describes one way to do this.
Also, this is why changing menus dynamically sometimes backfires. People get used to seeing certain items on the tops and bottoms of menus. Rearranging or compacting menu items “helpfully” can work against habituation and lead to user errors.
Incidentally, the tops and bottoms of lists and menus are special locations, cognitively speaking. People notice and remember them more than stuff in the middle of menus. They are the worst items to change out from under the user.
“I’m putting this here to remind myself to deal with it later.”
We engage in prospective memory when we plan to do something in the future, and we arrange some way of reminding ourselves to do it. For example, if you need to bring a book to work the next day, you might put it on a table beside the front door the night before. If you need to respond to someone’s email later (just not right now!), you might leave that email on your screen as a physical reminder. Or, if you tend to miss meetings, you might arrange for Outlook or your Palm to ring an alarm tone five minutes before each meeting.
Basically, this is something almost everyone does. It’s part of how we cope with our complicated, highly scheduled, multitasked lives: we use knowledge “in the world” to aid our own imperfect memories. We need to be able to do it well.
Some software does support prospective remembering. Outlook and PalmOS, as mentioned above, implement it directly and actively; they have calendars (as do many other software systems), and they sound alarms. But what else can you use for prospective memory?
Notes to oneself, like virtual “sticky notes”
Windows left onscreen
Annotations put directly into documents (like “Finish me!”)
Browser bookmarks, for web sites to be viewed later
Documents stored on the desktop, rather than in the usual places in the filesystem
Email kept in an inbox (and maybe flagged) instead of filed away
People use all kinds of artifacts to support passive prospective remembering. But notice that almost none of the techniques in the list above were designed with that in mind! What they were designed for is flexibility—and a laissez-faire attitude toward how users organize their information. A good email client lets you create folders with any names you want, and it doesn’t care what you do with messages in your inbox. Text editors don’t care what you type, or what giant bold magenta text means to you; code editors don’t care that you have a “Finish this” comment in a method header. Browsers don’t know why you keep certain bookmarks around.
In many cases, that kind of hands-off flexibility is all you really need. Give people the tools to create their own reminder systems. Just don’t try to design a system that’s too smart for its own good. For instance, don’t assume that just because a window’s been idle for a while, no one’s using it and it should be closed. In general, don’t “helpfully” clean up files or objects that the system may think are useless; someone may be leaving them around for a reason. Also, don’t organize or sort things automatically unless the user asks the system to do so.
As a designer, is there anything positive you can do for prospective memory? If someone leaves a form half-finished and closes it temporarily, you could retain the data in it for the next time—it will help remind the user where she left off. Similarly, many applications recall the last few objects or documents they edited. You could offer bookmarks-like lists of “objects of interest”—both past and future—and make that list easily available for reading and editing.
Here’s a bigger challenge: if the user starts tasks and leaves them without finishing them, think about how to leave some artifacts around, other than open windows, that identify the unfinished tasks. Another one: how might a user gather reminders from different sources (email, documents, calendars, etc.) into one place? Be creative!
“I have to repeat this how many times?”
In many kinds of applications, users sometimes find themselves having to perform the same operation over and over again. The easier it is for them, the better. If you can help reduce that operation down to one keystroke or click per repetition—or, better, just a few keystrokes or clicks for all repetitions—then you will spare users much tedium.
Find and Replace dialog boxes, often found in text editors (Word, email composers, etc.), are one good adaptation to this behavior. In these dialog boxes, the user types the old phrase and the new phrase. Then it takes only one “Replace” button click per occurrence in the whole document. And that’s only if the user wanted to see or veto each replacement—if they’re confident that they really should replace all occurrences, then they can click the “Replace All” button. One gesture does the whole job.
Here’s a more general example. Photoshop lets you record “actions” when you want to perform some arbitrary sequence of operations with a single click. If you want to resize, crop, brighten, and save 20 images, you can record those four steps as they’re done to the first image, and then click that action’s “Play” button for each of the remaining 19.
See the Macros pattern in Chapter 5 for more information.
Scripting environments are even more general. Unix and its variants allow you to script anything you can type into a shell. You can recall and execute single commands, even long ones, with a Control-P and return. You can take any set of commands you issue to the command line, put them in a for-loop, and execute them by hitting the Return key once. Or you can put them in a shellscript (or in a for-loop in a shellscript!) and execute them as a single command. Scripting is very powerful, and as it gets more complex, it becomes full-fledged programming.
Other variants include copy-and-paste capability (preventing the need to retype the same thing in a million places), user-defined "shortcuts” to applications on operating-system desktops (preventing the need to find those applications’ directories in the filesystem), browser bookmarks (so users don’t have to type URLs), and even keyboard shortcuts.
Direct observation of users can help you find out just what kinds of repetitive tasks you need to support. Users won’t always tell you outright. They may not even be aware that they’re doing repetitive things that they could streamline with the right tools—they may have been doing it so long that they don’t even notice anymore. By watching them work, you may see what they don’t see.
In any case, the idea is to offer users ways to streamline the repetitive tasks that could otherwise be time consuming, tedious, and error prone.
“Please don’t make me use the mouse.”
Some people have real physical trouble using a mouse. Others prefer not to keep switching between the mouse and keyboard because that takes time and effort—they’d rather keep their hands on the keyboard at all times. Still others can’t see the screen, and their assistive technologies often interact with the software using just the keyboard API.
For the sakes of these users, some applications are designed to be “driven” entirely via the keyboard. They’re usually mouse-driven too, but there is no operation that must be done with only the mouse—keyboard-only users aren’t shut out of any functionality.
Several standard techniques exist for keyboard-only usage:
Selection from lists, even multiple selection, usually is possible using arrow keys in combination with modifiers (like the Shift key), though this depends on which platform you use.
The Tab key typically moves the keyboard focus—the control that gets keyboard entries at the moment—from one control to the next, and Shift-Tab moves backwards. This is sometimes called “tab traversal.” Many users expect it to work on form-style interfaces.
Dialog boxes and web pages often have a “default button”—a button representing an action that says “I’m done with this task now.” On web pages, it’s often Submit or Done; on dialog boxes, OK or Cancel. When users hit the Return key on this page or dialog box, that’s the operation that occurs. Then it moves the user to the next page or returns him to the previous window.
There are more techniques. Forms, control panels, and standard web pages are fairly easy to drive from the keyboard. Graphic editors, and anything else that’s mostly spatial, are much harder, though not impossible. See Spring-Loaded Mode, in Chapter 8, for one way to use keyboards in graphic editors.
Keyboard-only usage is particularly important for data-entry applications. In these, speed of data entry is critical, and users can’t afford to move their hands off the keyboard to the mouse every time they want to move from one field to another, or even from one page to another. (In fact, many of these forms don’t even require users to hit the Tab key to traverse between controls; it’s done automatically.)
“What did everyone else say about this?”
People are social. As strong as our opinions may sometimes be, what our peers think tends to influence us.
Witness the spectacular growth of online “user comments”: Amazon for books, IMDb.com for movies, photo.net and flickr for photographs, and countless retailers who offer space for user-submitted product reviews. Auction sites like eBay formalize user opinions into actual prices. Blogs offer unlimited soapbox space for people to opine about anything they want, from products to programming to politics.
The advice of peers, whether direct or indirect, influences people’s choices when they decide any number of things. Finding things online, performing transactions (should I buy this product?), playing games (what have other players done here?), and even building things—people can be more effective when aided by others. If not, they might at least be happier with the outcome.
Here’s a more subtle example. Programmers use the MATLAB application to do scientific and mathematical tasks. Every few months, the company that makes MATLAB holds a public programming contest; for a few days, every contestant writes the best MATLAB code they can to solve a difficult science problem. The fastest, most accurate code wins. The catch is that every player can see everyone else’s code—and copying is encouraged! The “advice” in this case is indirect, taking the form of shared code, but it’s quite influential. In the end, the winning program is never truly original, but it’s undoubtedly better code than any single solo effort would have been. (In many respects, it’s a microcosm of open-source software development, which is driven by a powerful set of social dynamics.)
Not all applications and software systems can accommodate a social component, and not all should try. But consider whether it might enhance the user experience to do so. And you could be more creative than just tacking a web-based bulletin board onto an ordinary site. How can you persuade users to take part constructively? How can you integrate it into the typical user’s workflow?
If the task is creative, maybe you can encourage people to post their creations for the public to view. If the goal is to find some fact or object, perhaps you can make it easy for users to see what other people found in similar searches.
Of the patterns in this book, Multi-Level Help (Chapter 2), most directly addresses this idea; an online support community is a valuable part of a complete help system for some applications.
 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.
 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.