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.