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.

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.

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.

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.

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.

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?

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).