Designing Interfaces, 3rd Edition

Chapter 1. Designing for People

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

Why not? After all, that’s probably why you picked up the book in the first place.

In this first chapter, we outline the purpose and outcomes of understanding how people use software. Specifically, you’ll get a sense for what is critical to people when it comes to designing websites, applications and interfaces:

• Overall goals in using your site or application

• The breakdown of tasks in carrying out those goals

• How they think about the particular subject or domain

• The language they use to think and talk about this subject

• How skilled or unskilled they are in doing the work

• Their attitudes toward the subject

Good interface design doesn’t begin with pictures. It begins 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.

A framework for achieving this is described here. It covers four areas. These are not strict rules or requirements for creating great designs. But having a plan for how you will inform yourself and your team in each area will give you confidence that your work is based on real insights into valuable problems to solve for your target customers. Decide for yourself what level of time and effort is appropriate for your project or company. Revisiting these areas regularly will keep key insights at the top of your mind and help focus everyone’s effort, especially user interface (UI) design, on creating great outcomes for people.

The four-part structure for understanding design for people is this:

Context

Who is your audience?

Goals

What are they trying to do?

Research

Ways to understand context and goals

The Patterns

Cognition and behavior related to interface design

Context

The first major element and the first step in designing for people is to understand the human context for your design intention. Interaction design starts with defining and understanding the people who will use your design. Specifically, ground your design decisions in understanding what they may want to do and what they bring to the interaction in terms of expectations, knowledge of relevant subjects or information domains, and their skill level with software.

Know Your Audience

There’s a maxim in the field of interface design: “You are not the user.”

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

Interactions Are Conversations

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

Here are the key points:

• There are two participants in the conversation: the person and the software.

• There is a constant back and forth exchange of information.

• The exchange is a series of requests, commands, reception, processing, and response.

• The human in the conversation needs continuous feedback from the interface that confirms that things are working normally, inputs are being processed, and that they are proceeding satisfactorily toward the goal of the moment.

• For this feedback loop to work, the software—which can’t be as spontaneous and responsive as a real human (at least not yet)—should be designed to mimic a conversation partner. It should be understandable to its partner, it should indicate it’s active (when it’s “listening”), and it should be obvious when it’s responding. Another layer on this is having some anticipated next steps or recommendations, in the same way a considerate person might be helpful to another.

As the UI 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 employ? How can the application set expectations appropriately for the user? How do the user and the machine finally end up communicating meaningfully with each other?

Match Your Content and Functionality to Your Audience

Before you start the design process, consider your overall approach. Think about how you might design the interface’s 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 they care about the subject, how much they already know about it, how receptive they are to learning from you, and whether they’re even interested in the conversation in the first place. If you get any of that wrong, bad things happen—the person 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 entire interface design in subtle ways. For example, do your users expect a short, tightly focused exchange about something very specific, or do they prefer 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 such as Excel, an “open floorplan” interface that exposes a huge number of features in one place. At any given time, the user has hundreds of things that they could 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.

Skill Level

How well can your audience use your interface now and how much effort are your users willing to spend to learn it?

Some of your customers might use it every day on the job—clearly, they’d become an expert user over time. But they will become increasingly unhappy with even small dissatisfactions. Maybe they’ll use it sometimes and learn it only well enough to get by (Satisficing). Difficulties in usage can be tolerated more. Maybe they’ll use it only once. Be honest: can you expect most users to become intermediates or experts, or will most users remain perpetual beginners?

Software designed for intermediate-to-expert users include the following:

• Photoshop

• Excel

• Code development environments

• System-administration tools for web servers

In contrast, here are some things designed for occasional users:

• Kiosks in tourist centers or museums

• Windows or macOS controls for setting desktop backgrounds

• Purchase pages for online stores

• Installation wizards

• Automated teller machines

The differences between the two groups are dramatic. Assumptions about users’ tool knowledge permeate these interfaces, showing up in their screen-space usage, labeling, and widget sophistication, and in 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 that 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 applications—it’s usually just not worth it!

Now that you’ve seen the extremes, look at the applications in the middle of the continuum:

• Microsoft PowerPoint

• Email clients

• Facebook

• Blog-writing tools

The truth is that 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 things 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.

You might someday find yourself in tension between the two ends of this spectrum. Naturally you want people to be able to use your design “out of the box,” but you might also 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 Help Systems, can help you serve both constituencies.

Goals: Your Interface Is Just a Means to Their Ends

Everyone who uses a tool—software or otherwise—has a reason for using it. These are their goals. Goals could be outcomes such as these:

• 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. User experience (UX) 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’re learning ways to support the building of documents, illustrations, and code.

Ask Why

The first step in designing an interface is to learn what its users are really trying to accomplish. Filling out a form, for example, is almost never a goal in and of itself—people only do it because they’re trying to buy something online, renew their driver’s license, or install software. They’re performing some kind of transaction.

Asking the proper 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 that they want a certain feature, ask why they want it—determine their 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.¹

Design’s Value: Solve the Right Problem, and Then Solve It Right

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, defined as helping the user achieve their goal.

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 their goal, with less time and effort spent on their 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.” But, why do they read and send email in the first place? To converse with other people. Of course, other means can 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 this manager? The convenience of choosing when to send or respond? 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 be taking 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 to browse and explore different options. Ask why. His goal is actually a transaction: to buy plane tickets. Again, he could have done that at many different websites, 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?

• Sometimes, goal analysis really isn’t enough. A snowboarding site might provide information (for learning), an online store (for transactions), and a set of video clips (for entertainment). Suppose that someone visits the site for a purchase, but they get sidetracked into the information on snowboarding tricks—they have switched goals from accomplishing a transaction to browsing and learning. Maybe they’ll go back to purchasing something, maybe not. And does the lifestyle and entertainment part of the site successfully entertain both the 12-year-old and the 35-year-old? Will the 35-year-old go elsewhere to buy their new board if they don’t feel at home there, or do they not care? It’s useful to expand your goal framework to include an understanding of the specific business purchase cycle. Your snowboarding customer will have different goals at different stages of this cycle. Alternately, you might want to design how you could foster a long-term loyalty between the brand and the customer. This could be done via content and functionality that fosters an identity, builds a community, and celebrates a lifestyle.

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: expectations, 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 might find the critical feature or design factor that makes your application more appealing and successful.

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

Research: Ways to Understand Context and Goals

Research is the starting point in design for understanding people. Empirical discovery is the only really good way to obtain this information. Qualitative research such as one-on-one interviews gives you the basis for understanding your audience’s expectations, vocabulary, and how they think about their goals or structure their work. You can often detect patterns in what you’re hearing. These are your signals for guiding the design. Quantitative research such as a survey can give numerical validation or disqualification to your quant findings.

To start a design, you’ll need to characterize the kinds of people who will be using your design (including the softer factors 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 mobile phone app will differ dramatically from the target audience for a piece of scientific software. Even if the same person uses both, their 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 might stop using the mobile app if they find its UI to be too difficult to use after a few days.

Each 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 the following:

• Their goals in using the software or site

• 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 or site, 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 OK. 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.” But 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.

This user-discovery phase will consume time and resources early in the design cycle, especially if you don’t really have a handle on who your audience is and why they might use your designs. It’s an investment. It’s worth it because the understanding you and the team gain gives long-term payback in better designs: solving the correct problems, and fit for purpose.

Fortunately, lots of books, courses, and methodologies now exist to help you. Although this book does not address user research, following are some methods and topics to consider.

Direct Observation

Interviews and onsite 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 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

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 can also use them as longitudinal studies—exploring the context of use over months or even years. Finally, if you’re designing custom software for a single user or site, you’ll want to learn as much as possible about the actual context of use.

Surveys

Written surveys can collect information from many users. You can actually get statistically significant numbers of respondents with these. Because 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.

You can find some further guidelines for writing effective survey questions here:

• Writing Good Survey Questions

• Questionnaire Design Tip Sheet

Personas

Personas aren’t a data-gathering method, but they do help you figure out what to do with your data after you have it. This is a design technique that models the target audiences. For each major user group, you create a fictional person, or “proto-person,” who 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. Personas can help you stay focused. As your design proceeds, you can ask yourself questions such as, “Would this fictional person really do X? What would she do instead?”

Design Research Is Not Marketing Research

You might notice that some of these methods and topics, such as interviews and surveys, sound suspiciously like marketing activities. They are closely related. Focus groups, for example, can be useful, but be careful. In group settings, not everyone will speak up, and just one or two people might dominate the discussion and skew your understanding. There is also the very robust marketing practice of market segmentation. It resembles the definition of target audiences used here, but market segments are defined by demographics, psychographics, and other characteristics. Target audiences from a UI design perspective are defined by their task goals and behaviors.

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’ interactions 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 are usually 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 such as the self-selection of users, you might end up with data that doesn’t reflect your actual target audience—and that can only hurt your design in the long run.

But even 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.

The Patterns: Cognition and Behavior Related to Interface Design

The patterns that follow are some of the most common ways people think and behave as it relates to software interfaces. Even though individuals are unique, people in general behave predictably. Designers have been doing site visits and user observations for years; cognitive scientists and other researchers have spent countless hours watching how people do things and how they think about what they do.

So, when you observe people using your software, or doing whatever activity you want to support with new software, you can expect them to do certain things. The behavioral patterns that follow are often seen in user observations. The odds are good that you’ll see them too, especially if you look for them.

Note

For all of you pattern enthusiasts: these patterns aren’t like the others in this book. They describe human behaviors—not interface design 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, documentation, everything—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 might be in a better place than anyone to advocate for the users.

• Safe Exploration

• Instant Gratification

• Satisficing

• Changes in Midstream

• Deferred Choices

• Incremental Construction

• Habituation

• Microbreaks

• Spatial Memory

• Prospective Memory

• Streamlined Repetition

• Keyboard Only

• Social Media, Social Proof, and Collaboration

Safe Exploration

“Let me explore without getting lost or getting into trouble.”

When someone feels like they can explore an interface and not suffer dire consequences, they’re 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 need to be very bad. Mere annoyance can be enough to deter someone from trying things out voluntarily. Clicking away pop-up windows, reentering data that was mistakenly erased, suddenly muting the volume on one’s laptop when a website 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.

This pattern encompasses several of the most effective usability guidelines, based on research, as identified by usability expert Jakob Nielsen:²

• Visibility of system status

• Match between the system and the real world

• User control and freedom

Here are some examples of what “Safe Exploration” is like:

• A photographer tries out a few image filters in an image-processing application. They then decide that they don’t like the results, and click Undo a few times to get back to where they were. Then they try another filter, and another, each time being able to back out of what they did. (The pattern named Multilevel Undo, in Chapter 8, 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 them back to the main page. No extra windows or pop ups open, and the Back button keeps working predictably. You can imagine that if a web app 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—confusion might ensue. The user can become disoriented while navigating, and might abandon the app altogether.

Instant Gratification

“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! They’ll be more likely to keep using it, even if it becomes more difficult later. They will feel more confident in the application, and more confident in themselves, 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, you should design the UI to make that first thing stunningly easy. If the user’s goal is to create something, for instance, create a new canvas, put a call to action on it, and place a palette next to it. If the user’s goal is to accomplish some task, point the way toward a typical starting point.

This 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, advertisements, and so on. These are discouraging because they block users from finishing that first task quickly.

To summarize, anticipate their need, provide an obvious entry point, provide value to the customer first before asking for something valuable (email address, a sale) in return.

Satisficing

“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 they see first that might get them what they want, and try it—even if it might be wrong.

The term satisficing is a combination of satisfying and sufficing. It was coined 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 after you appreciate the mental work necessary to “parse” a complicated interface. As Steve Krug points out in his book Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability (New Riders, 2014), people don’t like to think any more than they need to—it’s work! But if the interface presents an obvious option or two that the user sees immediately, they’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:

• Use “calls to action” in the interface. Give directions on what to do first: type here, drag an image here, tap here to begin, and so forth.

• 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’ll both be off to a bad start.

• Use the layout of the interface to communicate meaning. Chapter 4 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 websites, using the Back button is easy, so designing easy forward/backward navigation is especially important for web apps, installed applications, and mobile devices.

• Keep in mind that a complicated interface imposes a large cognitive cost on new users. Visual complexity will often tempt nonexperts to satisfice: they look for the first thing that might work.

Satisficing is why many users end up with odd habits after they’ve been using a system for a while. Long ago, a user might have learned Path A to do something, and even though a later version of the system offers Path B as a better alternative (or maybe it was there all along), they see no benefit in learning it—that takes effort, after all—and keep 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 might not be worth the cost to the user.

Changes in Midstream

“I changed my mind about what I was doing.”

Occasionally, people change what they’re doing while in the middle of doing it. Someone might walk into a room with the intent of finding a key that they had left there, but while there, they find a newspaper and start reading it. Or they might visit Amazon.com to read product reviews, but end up buying a book instead. Maybe they’re just sidetracked; maybe the change is deliberate. Either way, the user’s goal changes while they’re using the interface you designed.

This means designers should provide opportunities for people to do that. Make choices available. Don’t lock users into a choice-poor environment with 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) and Modal Panel (Chapter 3) for examples.

You can also make it easy for someone to start a process, stop in the middle, and come back to it later to pick up where they left off—a property often called reentrance. For instance, a lawyer might start entering information into a form on an iPad. Then, when a client comes into the room, the lawyer turns off the device, with the intent of coming back to finish the form later. The entered information shouldn’t be lost.

To support reentrance, you can make dialogs and web forms remember values typed previously, and they don’t usually need to be modal; if they’re not modal, they can be dragged 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 them put any number of projects aside while they work on another one. For more information, see the Many Workspaces pattern in Chapter 2.

Deferred Choices

“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 task-focused user unnecessary questions in the process, they might prefer to 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. Why not allow them to skip most of the questions, answer the bare minimum, and come back later (if ever) to fill in the rest? Otherwise, they might be there for half an hour answering essay questions and finding the perfect avatar image.

Another example is creating a new project in a video editor. There are some things that you do need to decide up front, such as the name of the project, but other choices—where on the server are you going to put this when you’re done? I don’t know yet!—can easily be deferred.

Sometimes, it’s just a matter of not wanting to answer the questions. At other times, the user might 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 bit of “good” 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 they do need to use, clearly indicate required versus optional fields, and don’t make too many of them required. Let them 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.

• Use Good Defaults (Chapter 10) 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 websites store a user’s half-finished form entries or other persistent data, such as shopping carts with unpurchased items.

• If registration is required at a website that provides useful services, users might be far more likely to register if they’re first allowed to experience the website—drawn in and engaged—and then asked later about who they are. Some sites let you complete an entire purchase without registering and then ask you at the end if you want to create a no-hassle login with the personal information provided in the purchase step.

Incremental Construction

“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 in a precise order. 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, they start with some small piece of it, work on it, step back and look at it, test it (if it’s code or some other “runnable” thing), fix what’s wrong, and start to build other parts of it. Or maybe they start over, if they really don’t like it. The creative process goes in fits and starts. It moves backward as much as forward 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 for users to build small pieces. Keep the interface responsive to quick changes and saves. Feedback is critical: constantly show the user what the entire thing looks and behaves like while the user works. If the user builds 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 creative activities are well supported by good tools, they 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.

But bad tools will keep users distracted, guaranteed. If the user must wait even half a minute to see the results of the incremental change they just made, their concentration is broken; flow is disrupted.

If you want to read more about flow, there are multiple books by researcher Mihaly Csikszentmihalyi. One title is Flow: The Psychology of Optimal Experience. (Harper Row, 2009).

Habituation

“That gesture works everywhere else; why doesn’t it work here, too?”

When you use an interface repeatedly, some frequent physical actions become reflexive: pressing Ctrl-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—even pressing a car’s brake pedal. The user no longer needs to think consciously about these actions. They’ve become habitual.

This tendency helps people become expert users of a tool (and helps create a sense of flow, too). Habituation also 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—the user is caught short. They suddenly need to think about the tool again (What did I just do? How do I do what I intended?), and they might need to undo any damage done by the gesture.

Millions of people have learned the following keyboard shortcuts based on using Microsoft Word and other word processors:

Ctrl-X

Cut the selection

Ctrl-V

Paste the selection

Ctrl-S

Save the document

These shortcuts are true universals now. Consistency across applications can be an advantage to use in your software design. 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—that is, the more habituated they are—the more likely they are to make that mistake.

Consider this carefully if you’re developing gesture-based interfaces for mobile devices. After someone learns how to use their device and gets used to it, they will depend on the standard gestures working consistently on all applications. Verify that gestures in your design all do the expected things.

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 pressing Return (if the OK button is the default button). If the dialogs pop up all the time when the user makes intended changes, such as deleting files, clicking OK 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.

Note

I’ve seen at least one application that sets up the confirmation dialog box’s buttons randomly from one invocation to another. You actually must 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.

Microbreaks

“I’m waiting for the train. Let me do something useful for two minutes.”

People often find themselves with a few minutes of downtime. They might need a mental break while working; they might be in line at a store or sitting in a traffic jam. They might be bored or impatient. They want to do something constructive or entertaining to pass the time, knowing they won’t have enough time to get deep into an online activity.

This pattern is especially applicable to mobile devices, because people can easily pull them out at times such as these. The enormous success of the social media technology sector was built in no small part by taking advantage of this. Social and casual gaming, Facebook, Instagram, Snap...all are enjoyed in microbreaks.

Here are some typical activities during microbreaks:

• Checking email

• Reading Streams and Feeds (in Chapter 2) such as Facebook or Twitter

• Visiting a news site to find out what’s going on in the world

• Watching a short video

• Doing a quick web search

• Reading an online book

• Playing a short game

The key to supporting microbreaks is to make an activity easy and fast to reach—as easy as turning on the device and selecting an application (or website). Don’t require complicated setup. Don’t take forever to load. And if the user needs to sign in to a service, try to retain the previous authentication so that they don’t need to sign in every time.

For “Stream and Feed” services, load the freshest content as quickly as possible and show it in the first screen the user sees. Other activities such as games, videos, or online books should remember where the user left them last time and restore the app or site to its previous state, without asking (thus supporting reentrance).

If you’re designing an email application or anything else for which the user needs to do “housekeeping” to maintain order, give them a way to triage items efficiently. This means showing enough data per item so that they can identify, for instance, a message’s contents and sender. You can also give them a chance to “star” or otherwise annotate items of interest, delete items easily, and write short responses and updates.

Long load times deserve another mention. Taking too long to load content is a sure way to make users give up on your app—especially during microbreaks! Make sure the page is engineered so that readable, useful content loads first, and with very little delay.

Spatial Memory

“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 “this document was at the upper 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, and so on—in predictable places, partly because spatial memory for them is so strong. In complex applications, people might also find things by remembering where they are relative to other things: tools on toolbars, objects in hierarchies, and so forth. Therefore, you should use patterns such as Responsive Enabling (Chapter 4) carefully. Adding items to blank spaces in an interface doesn’t cause problems, but rearranging existing controls can disrupt spatial memory and make things more difficult to find. It depends. Try it out on your users if you’re not sure.

Many mobile applications and games consist of just a few screens. Often the start screen is designed to be where users spend all of their time. There might not be any apparent navigation. But users learn to swipe left, right, up, or down to get to the other screens (such as messaging or settings). These other screens are there, just off to the side. Snap is a good example of a mobile app that is designed to use people’s spatial memory.

Along with habituation, which is closely related, spatial memory is another reason why consistency across and within a platform’s applications is good. People might expect to find similar functionality in similar places. For an example, see the Sign-In Tools pattern (Chapter 3).

Spatial memory explains why it’s good to provide user-arranged areas for storing documents and objects, such as the aforementioned desktop. 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 it for them unless they ask!) The Movable Panels pattern in Chapter 4 describes one particular way to do this.

Also, this is why changing menus dynamically can sometimes backfire. 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. So can changing navigation menus on web pages. Try to keep menu items in the same place and in the same order on all subpages in a site.

Incidentally, the tops and bottoms of lists and menus are special locations, cognitively speaking. People notice and remember them more than items in the middle of a list. The first and last items in a list are more likely to be noticed. So, if you want to draw attention to one or two items in a list of items, place them at the beginning or end. Items moved to the middle are less likely to be noticed or remembered.

Prospective Memory

“I’m putting this here to remind myself to deal with it later.”

Prospective memory is a well-known phenomenon in psychology that doesn’t seem to have gained much traction yet in interface design. But I think it should.

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, the night before you might put it on a table beside the front door. 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 mobile device to ring an alarm tone five minutes before each meeting.

Basically, this is something almost everyone does. It’s a 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 most mobile platforms, as mentioned earlier, implement it directly and actively; they have calendars, and they sound alarms. Trello is another example; it is a Kanban board of cards. Memory aids that people use can include the following:

• Notes to oneself, like virtual “sticky notes”

• Windows left on-screen

• Annotations put directly into documents (such as “Finish me!”)

• Browser bookmarks, for websites 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 preceding list were designed with that in mind! What they were designed for is flexibility—and a laissez-faire attitude toward how users organize their stuff. 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 care 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, that no one’s using it and it should be closed. In general, don’t “helpfully” clean up files or objects that the system might think are useless; someone might 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 they left off. (See the Deferred Choices pattern.) Similarly, many applications recall the last few objects or documents they edited. You could offer bookmark-like lists of “objects of interest”—both past and future—and make those lists easily available for reading and editing. You can implement Many Workspaces (Chapter 2), which lets users leave unfinished pages open while they work on something else.

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 idea: how might a user gather reminders from different sources (email, documents, calendars, etc.) into one place?

Streamlined Repetition

“I have to repeat this how many times?”

In many kinds of applications, users sometimes find themselves needing 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—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 entire document. And that’s only if the user wants to see or veto each replacement. If they’re confident that they really should replace all occurrences, 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 actions 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. For more information, see the Macros pattern in Chapter 8.

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 Ctrl-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 pressing the Return key once.

Or you can put them in a shell script (or in a for-loop in a shell script) and execute them as a single command. Scripting is very powerful, and when 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 need to type URLs), and even keyboard shortcuts.

Direct observation of users can help you to determine just what kinds of repetitive tasks you need to support. Users won’t always tell you outright. They might not even be aware that they’re doing repetitive things that could be streamlined with the appropriate tools—they might have been doing it for so long that they don’t even notice anymore. By watching them work, you might 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. For more information, see Macros in Chapter 8.

Keyboard Only

“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:

• You can define keyboard shortcuts, accelerators, and mnemonics for operations reachable via application menu bars, such as Ctrl-S for Save. See your platform style guide for the standard ones.

• Selection from lists, even multiple selection, is usually possible using arrow keys in combination with modifiers (such as the Shift key), though this depends on which component set you use.

• The Tab key typically moves the keyboard focus—the control that receives keyboard entries at the moment—from one control to the next, and Shift-Tab moves backward. This is sometimes called tab traversal. Many users expect it to work on form-style interfaces.

• Most standard controls, even radio buttons and combo boxes, let users change their values from the keyboard by using arrow keys, the Return key, or the space bar.

• 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 press 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 more difficult, though not impossible.

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 one page to another. (In fact, many of these forms don’t even require users to press the Tab key to traverse between controls; it’s done automatically.)

Social Media, Social Proof, and Collaboration

“What did everyone else say about this?”

People are social. As strong as our opinions might sometimes be, we tend to be influenced by what our peers say and do. And we are powerfully attuned to seeking approval from others and belonging to a group. We maintain social media identities. We contribute to groups and people we care about.

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.

We are much more likely to watch, read, buy, join, share, comment, or take any other action if we see that someone we know has recommended it or done it or is present. This is called social proof.

All of these real-world dynamics underpin the massive scale and success of social computing in its many forms. It is fair to say that a social aspect or layer is part of almost all software today. Enabling social dynamics in your software can bring increased engagement, virality, community, and growth.

Here are some examples of social functionality:

User-generated reviews and comments

These allow individuals to get a sense of the wisdom of the crowd. Reviews can be rated, and participants can gain fame or other rewards for being rated as a good reviewer.

Everything is a social object

Text posts, images, video, check-ins, almost anything that users create in social media becomes an object that people can virtually gather around. Anything can be shared, rated, have a discussion thread attached to it, and similar activities.

Collaboration

Business productivity and communication software has been transformed by software that allows people separated by space and time to come together in discussion threads, document reviews, video conferencing, tracking status, live and asynchronous communications, and many other activities.

Social proof motivates people to take action. Social group identity, participation, and recognition are powerfully rewarding to people.

Designing these capabilities into your interface creates the opportunity for social dynamics to increase your audiences’ engagement, reward, and growth.

Of the patterns in this book, Help Systems (Chapter 2) most directly addresses this idea; an online support community is a valuable part of a complete help system for some applications.

For a deep dive into designing for social media, see Designing Social Interfaces: Principles, Patterns, and Practices for Improving the User Experience by Christian Crumlish and Erin Malone (O’Reilly, 2015).

Conclusion

This chapter gave you a tour of the vital context for any successful interaction design: understanding who will be using your software. This is the basis for designs that are fit for purpose and able to be understood easily. To achieve this, ground your design process in the four-part foundation described in this chapter. First, understand the context. This means getting clear on what sorts of people you are designing for, the subject or work domain you are designing for them, and your users’ existing skill level. Second, understanding their goals is important. This is the framework of workflows, tasks, and outcomes you will design for. Third, user research is a valuable activity and skill to help you understand users and their goals. We outlined a number of research activities that you can choose from. Finally, we looked at a number of patterns in human behavior, perception, and thinking that are relevant for designing interfaces. These four elements form the foundation of your design process. In Chapter 2, we look at creating a strong organization foundation for your software or app itself.

¹ This is the same principle that underlies a well-known technique called root-cause analysis. But root-cause analysis is a tool for fixing organizational failures; here, we use its “five why’s” (more or less) to understand everyday user behaviors and feature requests.

² Nielsen, Jakob. “10 Usability Heuristics for User Interface Design,” Nielsen Norman Group, 24 Apr. 1994. www.nngroup.com/articles/ten-usability-heuristics.