Designing for Behavior Change: Applying Psychology and Behavioral Economics (2013)

Part II. Discovering the Right Outcome, Action, and Actor

Chapter 5. Selecting the Right Target Action

Each of us has different routines, different experiences, and different ways that we respond to the world. To design for behavior change, you need to discover the right action for your users based on this complex terrain of routines, experiences, and responses. The action must be effective at helping them achieve their goals. And, at the same time, you must balance user needs against the needs of the company building the product—to generate revenue and to cost-effectively deploy design and engineering resources.

In Chapter 4, we clarified what the company sought to accomplish with the product (the target outcome, like people losing weight) and generated a list of potential actions that users could take in order to make that happen (like using smaller plates, exercising more, or going on a diet). That initial list of target actions was initially developed in a vacuum, without a lot of discussion about the users themselves—to avoid stereotyped actions that we think people are “likely” to take.

Now it’s time to confront that list of potential actions with real users. We’ll refine the list and then evaluate it according to company and user needs. Along the way, we’ll also gather vital information we need about the target users for designing the product itself.

Research Your Target Users

In order to help users change their behavior, the team must understand where the users are starting from and what behaviors are realistic and worthwhile to change. This process focuses on three distinct questions:

§ Who are the users who will be interacting with the product?

§ How do these (potential) users think and act in their everyday lives?

§ How do these users interact with and behave within the existing application (if any)?

Who Are the Target Users?

Usually the company’s business objectives and market research specify who the product is supposed to serve. For a private company, the target audience consists of those people that the company believes will buy the product. For NGOs and government agencies that don’t “sell” anything, the target audience would be the people who they are tasked with helping, and who they believe will use the product.

Write down who the target users are, as specifically as possible: age, gender, location, number of people, and so on. It can also help to write down who is not being targeted: for example, people without smartphones, people who are wealthy, or expats. The target users may vary across the list of potential actions you identified in Chapter 4. That’s fine. Next to each potential action, write down the target users.

In all likelihood, some of the target users really aren’t a good fit for the product, and you would waste your time trying to target them. That will be part of the user research and discover process; for now, we want to know the potential users that you should investigate further. You may end up targeting only a subset of them.

If the company has no idea who it is trying to serve, then it’s back to the basics. A behavioral product, like any product, must serve a user need. It can only help people change their behavior to the extent that they care about the product at all. To get a handle on the unmet user need, you need a traditional market research or (nonbehavioral) product discovery process. That’s beyond the scope of this book though; from here on, I’ll assume you have a general sense of the target user already.

How Do the People Behave in Daily Life?

By the end of this process, the product team will have built a brand new experience. That new experience has to make sense for its users, given their existing habits and beliefs, their existing terminology, and their existing desires and needs. To do that well, the team needs to learn about their users up front.

To make this discussion concrete, I’ll use an example from my past life as a microtargeter (someone who analyzes data about large numbers of individuals in order to identify people who are likely to take action, and what will appeal to them). One of my company’s clients was an advocacy organization, which I’ll call ActMore so they don’t feel obliged to sue me. ActMore is an environmental NGO, and wanted to help its constituents become more involved in their community of like-minded environmentalists. They had a large number of people who had signed up for their email mailing list and newsletter, and had said they wanted to do more, but hadn’t yet really gotten involved. First, ActMore needed the basics—information about age, location, income level, race, gender, political interests, and so on. My company used data that the organization already had to fill in most of the basics. We could use that to target the appeal and provide guidance on the website.

That type of analysis is all standard stuff and is well covered in any book on product development or assessing market opportunities (as well as in political advocacy books, in ActMore’s case). We then started on the more interesting part, though, focused on behavior. We wanted to understand how strong the members’ interest would be in a specific event the organization was putting together—a rally on Earth Day. We were looking specifically for divisions within the member base: groups of people that would respond differently to appeals to join the rally. Each group would get its own personalized appeal that made sense given its background and level of experience. The product that we were shaping was an outreach campaign and associated website (and, as I remember, there was a phone-calling component as well). So, we started digging into the data available about the members to understand what different types of members the product would need to serve.

With ActMore, and with other companies and organizations I’ve worked with, here are questions that I’ve found are most relevant to ask about the user base, from a behavior-changing perspective:

Prior experience with the action

Do these users have experience taking the target actions? (For ActMore—have they been to other, similar rallies?) How do they think about the action? Are there strong emotional associations, or is this fresh ground? It’s much easier to increase an action than to start a new one. Existinghabits around the goals are especially important.

Prior experience with similar products and channels

If the product employs email and a website, do some users have regular access to computer (and know how to use it) and others don’t?

Relationship with the company or organization

To put it bluntly: do users trust you? You’ll have a harder time making your case, and need a different set of appeals, for the people who don’t trust you versus those that already know you and love you.

Existing motivation

Why would users want to achieve the outcome, completely separate from what the product offers them? In other words, what can the company build upon, so it doesn’t need to do all of the work itself? One especially powerful aspect of motivation is social motivation (positive or negative). What will users’ friends and family think if/when they take each of the actions on the list? Will they face a community of support, ridicule, or simple apathy?

Physical, psychological, or economic impediments to action

This isn’t as common, but sometimes arises. Are there groups of users for whom the action is especially difficult? For example, users that are homebound or don’t have the money to travel to the rally (we faced this with ActMore, in fact).

These five things make up the behavioral profile of the users. To gather this information, you can use the standard tools of market research and product development—look for existing quantitative data on user demographics, deploy field surveys, and conduct qualitative research with users in focus groups and one-on-one interviews.^[79^] If at all possible, include some direct observation in the field—see how people actually act (and not just what they say they do). If you’re just exploring the idea for a product informally, or if no direct contact is possible with the user base (if business or privacy restrictions make it infeasible), then talk to people who have had contact with the target users, and glean what you can from them.

This approach obviously builds on existing tools and techniques. The innovation here is in adding questions directly focused on the target action: not how people feel about the product or their “user needs” per se, but their actual experiences, motivations, and problems vis-à-vis the company’s target outcome and target action.

As you observe your users, you may witness or think up completely new ideas about what behaviors to change. For example, for your weight loss app, you may have thought about having users exercise or go on a diet, but after observing them, you realize that changing behavior to shop at a different grocery could be much more effective. Add that idea to the list and evaluate it along with the others. You may also realize that one (or more!) of the ideas just doesn’t make sense. Later on in this chapter, there’s a formal evaluation process. But if you know at this point without a doubt that one of your early ideas isn’t feasible, save yourself time and cross it off the list.

Along the way, the team might also identify particular terms and concepts that resonate with the users; that’s not the focus now, but it’s still useful—put them aside to inform the UX design later on.

How Do the People Behave in the Application?

If your company or organization already has an existing application or product, great—it can be used to understand the diverse groups of users you have and how they will respond to the new product or feature being considered. If you don’t already have a product serving these users, you can safely skip this step.

In my personal example, we couldn’t work with ActMore’s prior products to learn about users. So, I’ll stretch my example a bit. Assume that ActMore already had a mobile and web platform for facilitating political action—called ActMore Now! In studying an existing product like ActMore Now!, start with standard questions from the user testing arena: how do users feel about the application, what features are they lacking, what different types of people use the product, who is most active in the system and why, etc. Then, add new questions focused on 'margin-bottom:0cm;margin-bottom:.0001pt;line-height: normal;vertical-align:baseline'>Prior experience with the action

What features of the existing application are similar to the targeted action? Have the users built up existing habits that can be leveraged for the new targeted action?

Prior experience with the product

Which features were unsuccessful? What did those failures reveal about the characteristics of the users (particularly low attention space, impatience, or lack of background knowledge about a topic)?

Relationship with the company or organization

Are they showing that they trust you with their current usage of the application?

Existing motivation

What motivations or interests are underlying the most successful features of the application? How does using the current application interact with users’ daily lives, and especially their social lives? Are there communities built around using the application?

As you can see, the questions are very similar to those used when analyzing users outside the context of the product: motivation, prior experience, and trust. But the answers are all the more valuable as a guide because they relate to user behavior in the context of the product itself.

Practically, this process means watching, interviewing, and/or surveying existing users to understand their views of the application, their frustrations, and their joys. Make sure to include some direct observation of people as they go about their lives and use the application.^[80^] It also means analyzing existing usage patterns within the application to see what parts of the application have been successful at catching users’ attention. Especially important is measuring the behaviors of users on tasks related to the application’s top-level goal and analyzing how the population has responded to existing interventions.

Generate Personas

Next, you can use the information you’ve gathered to identify broad groups of (potential) users within your target population. I know the term is a bit loaded, but I like to generate formal user personas—short descriptions of archetypal users, with a simple background statement about a sample user’s life. (You can accomplish the same thing, in your own way, without the life-stories part, as long as you get a clear idea of the groups of users within the population). Since designing for behavior change entails changing nitty-gritty details of peoples’ lives, it’s valuable to keep in mind vivid, realistic, specific personas—and not an amorphous vague concept of “our users.”

Unlike traditional user personas, these personas are all about who are likely to respond differently to behavioral interventions. Each persona should have information about the topics discussed; Table 5-1gives one way to organize them. The examples are inspired by my work at HelloWallet, and the target action is saving money for emergencies among a population that hasn’t used online savings tools before.

Table 5-1. Two sample personas about saving money for emergencies

Repeat the Process for Each Potential Action

These behavioral personas are relative to a particular target action, since the goal is to create a set of personas that are likely to respond differently to the product’s attempts to change behavior. In other words, quickly look over each of the five questions (experience with similar actions, experience with similar products, etc.) and generate additional personas as needed for each of the potential user actions. Often, the resulting personas may be the same across various actions, but be prepared for them to be different. Next to each target action, list the personas that are relevant for it. We’ll simplify down to a few personas once we’ve chosen the target action for the product.

Two Techniques for Generating Them

Here are two approaches to synthesizing the personas themselves. First, you can use the five questions (experience with similar actions, experience with similar products, etc.) to spur ideas for personas in an open-ended way. For example: is there a group of users that is clearly more experienced taking this action than others? What are they like? Who would be an archetypal example of that group?

Second, you can use the questions in a more formal way to selected from a fixed set of possible characteristics. For example, there are five questions, and, at their simplest, each of them is a binary yes-no. Look at each possible combination of answers to those questions. On a first pass, you can eliminate most of them as not relevant to your population (e.g., physical impediments may not be relevant to your product; that cuts the options down in half immediately). After that quick pass through the options, you can ask whether you really have any users that fit those criteria, and what they are like as a group. Each remaining option gives you a persona.

One reason that I like the second method, odd as it may appear, is that is completely covers the range of possible users. It makes you think about each “type” and decide whether or not it’s relevant. Ideally, your personas should be exhaustive and mutually exclusive: every person in the target population best fits into one, and only one, persona. You can do this in a less structured way than the previous example by drawing a simple box that represents your entire user population (Figure 5-1).

Figure 5-1. A sample population breakdown to generate personas. This is from a startup I spoke with about encouraging employees at an office to utilize a package their employer had purchased for them.

For each persona you think of, mark it off as a portion of the box, with a rough estimate of the group’s size. If personas overlap—or one is part of another—that’s OK. Look at each overlapping piece as a separate group of people. As you’re running out of ideas, ask, who isn’t in one of these groups? What are they like? Label each group, see if some of them are redundant from a behavioral perspective (i.e., you expect them to respond to the product’s appeal to change behavior in the same way). Then, use those informal groups to come up with more detailed personas.

Select the Ideal Target Action

By this point, the company has a list of potential actions that users can take, and a set of user personas (with their motivations, prior experience, and impediments to action). Now it’s time to combine them, and narrow down the list.

Before getting too fancy, remove actions that are directly blocked by known impediments, especially if similar actions were tried but weren’t successful in a previous version of the product. Next, take each action and score it along the following criteria, ranking it low, middle, or high. To make the process more concrete, imagine that the target outcome is to help users learn a new language:^[81^]

Impact (on outcome)

How effectively would it achieve the outcome? In other words, assume that every user does the action, without reservation—how much would it help? When learning a new language, the action of repeating one word is not very effective and gets a “low”; practicing some sentences might be “middle”; immersing oneself in a foreign country gets “high.”

Motivation (for user)

What motivation do users have to perform the action? Draw upon the data about the users’ existing motivations and their social interactions around the product. Users may be really excited to travel to a foreign country, or to make new friends by practicing their language skills in person (those two options get a “high” rating). They may have little interest (and negative associations) with rote memorization (that’s a “low”).

Ease (for user)

How similar is this action to things that the users already do in their daily lives (including their interaction with the existing product)? Immersion in a foreign country to learn a language would (usually) be “low.” Repeating words or practicing sentences could be medium or high, depending on what you’ve learned about your users. Existing habits always get a “high” rating. Actions that require users to stop existing habits always get a “low” rating (see Chapter 3). This process may require subject matter experts to gauge the likely impact of the action on users.

Cost (for company)

How easy would it be for the company to implement a solution around the action? True language immersion would be “low” for online products. Live conversation with native speakers could be a “medium,” depending on the existing resources and capabilities of the company. Providing scripts for users to repeat would be easy. This rating may require a lead engineer to assess potential resource costs.

With these ratings in hand, look for obvious outliers. If there’s a stand-out winner, great. If not, remove any hands-down losers. If this doesn’t narrow down the list enough, make a judgment call about what’s most important and feasible for the company, given their business strategy. If resources are tight, then the cost of implementation naturally becomes rather important!

Behavioral economics can be useful here—certain behaviors and ways of thinking are inherently more difficult for (most) users. We covered many of the high-level lessons from this literature in Chapter 1. For example, behaviors that require extensive mental calculations are difficult and often avoided. Actions that focus on long-term gains over short-term losses are also contrary to much of our cognitive machinery (losses are more painful than gains are good, short-term gains are valued more highly than long-term ones).

Beyond that, there’s not more guidance to give here, unfortunately. Keep narrowing down the list until one top choice remains, or two neck-and-neck options that can be tested in practice.

After you’ve decided your target outcome, actor, and action, and have a set of behaviorally informed user personas, then what? Let’s fine-tune the target population a bit.

Define Success and Failure

You now have all the things you need to determine what success and failure would mean for your product before you build it. You know who the product is supposed to serve. You know what action you’re trying to drive. And, you know what real-world outcome that action is supposed to cause. You don’t have all of the details, of course, but that’s OK. At this stage, you have the rough outlines you need.

Write down in a sentence that says what the product is supposed to be doing, and for whom. For example:

This product will help active people (actor) track their exercise (action), and maintain their ideal weight (outcome).

From your user research about what’s feasible for users to accomplish, and from your market research about what will differentiate and sell the product, you should be able to add in additional specifics about the proposed product and its impact on your business. For example:

This product will help 25 to 35-year-old active people in urban areas (actor) track their daily exercise routine (action), to build muscle tone and lose five pounds more per year than they otherwise would (outcome). When successful, it should double our current revenue (company objective).

In this statement, the team is saying: if this happens, the product will be a success; if not, it will be a (complete or partial) failure. In a lean startup environment, you would then generate specific hypotheses around each of these elements, and test your assumptions in the field. Later on, inChapter 12, this statement will also drive the metrics we use to measure whether the product actually succeeded or failed at its goals.

Our goal isn’t to create a false sense of security by thinking we can forecast the future and how the product will actually play out. There are lots of assumptions built into this definition of outcome, actor, and action. We want to draw out those assumptions, to get something that can be explicitly tested and then revised as lessons are learned. And, perhaps most importantly, it helps us fail fast—to make sure that the key stakeholders in the company are on the same page before building the product. If they aren’t, now’s the time to fix it.

How to Handle Very Diverse Populations

While you were generating behavioral user personas, or evaluating how effective your target action would be for each them, you undoubtedly found some differences across the population. One lesson I’ve often found is that, for most behaviors, a one-size-fits-all product won’t work. We are all just too different. An exercise program that recommends that couch potatoes and Olympic athletes run a mile a week is going to fail them both—too difficult for one, and too easy for the other.

If you have a homogenous user base, cool. Not a problem. But if you have very different groups of users, especially with widely varying levels of prior experience, then the product team needs to make some tough choices.

You may confront this problem as you’re initially researching your target user population, because you already have a general sense of what you’ll ask them to do and see trouble coming. Or, it may come out only as you are trying to identify the ideal action for your users and recognize that there really isn’t one ideal action that covers all of them. Whenever it occurs, here are two approaches you can take:

§ Plan to adapt or personalize the app to diverse groups.

§ Narrow down the target audience, and accept that the product won’t work (as) well for some people.

In each case, if a single (nonadaptive) product can’t serve all of the intended audience, it’s best to identify that now rather than after months of wrangling with the product to do impossible things.

Planning for Adaptation or Personalization

Faced with a diverse population, the company can plan to adapt the product to serve its needs. Here are ways that adaptation can work, with an example of a mobile app that encourages daily exercise:

§ The application learns about the user and provides guidance and support relevant for the user’s needs. For example, by swapping in and out relevant actions (run versus walk), or by customizing each action (run for 10 minutes versus run for 5 hours).

§ Benefits. Greatest degree of personalization.

§ Challenges. If the application guesses wrong, it can anger and lose the trust of the user.

§ The application allows the user to self-select what is most relevant for her. For example, “How much would you like to run today?” or “Click here for beginner suggestions or here for advanced ones.”

§ Benefits. No guesswork on the part of the application.

§ Challenges. The user may not know the right level for her. This is especially true for people just starting out with a new behavior.

§ The application has multiple versions. The company then segments the audience and markets/delivers the version of the application that is most appropriate for that audience.

§ Benefits. Clear branding and expectations on the part of users. Can be combined with other techniques like user-level personalization.

§ Challenges. Very costly in terms of resources and team focus.

Narrowing Down the Target Audience

If the proposed product simply can’t be adapted to meet the diverse needs of the target population, then some people are going to be left with a suboptimal experience. If the company tries to create a single (nonadaptive) version of the product that appeals to everyone, then the lowest common denominator is unlikely to please anyone. Instead, the company should intentionally target subsets of the audience and make them the main focus of the product.

There may be clear business reasons to focus on some users over others. For example, maybe parents with children will pay more than single people for a service that promotes healthy eating at home. For NGOs and government agencies, there may be a clear mandate to serve certain populations (like helping subsistence farmers in arid climates to use crop insurance, before working with other farmers).

ADAPTING DYNAMICALLY TO EACH PERSON

You’ve probably noticed that after you’ve searched for a product online, you start seeing ads for it everywhere you go. Advertisers can dynamically adjust which ads you see on the Web based on your unique online history—it’s called behavioral targeting ([ref49]; [ref54]). They collect data across numerous websites and social networking services to build a live profile of what you’re interested in (and what they can make money from), and then deploy ads accordingly.

Similar adaptive techniques are now being explicitly used for persuasion and for behavior change. For example, researchers Kaptein and Eckles developed a method to dynamically create persuasion profiles of individuals as they interacted with an online bookstore; the profiles assessed the types of recommendations that were most effective at convincing each person ([ref102]; [ref148]). This method has been used for positive behavior change as well; for example, researchers provided a series of dynamically targeted reminders to users of an exercise tracker ([ref103]).

Adaptive, individualized content is not widespread yet in the behavior change space. However, over time, I expect that will change.

If you aren’t sure, a simple strategy is this: focus on the people you think you can actually help. Build a product that works for some people and for whom there’s a market. Then expand or adjust it to work for others, if needed. That’s much easier, and more rewarding for the team, than trying to take on the hardest population to serve first, and struggling to get any traction at all.

For example, if you’re developing an exercise tracker that is eventually intended to reach a general audience, it makes natural sense to focus initially on people who are already fit and active.^[82^] Trying to build an exercise tracker that appeals to clinically obese and sedentary people is a much harder problem, and one that you can work up to over time as you build on prior successes. It might take a completely new product to reach that audience, or significant changes to your current product; either way, you’ll at least have some experience under your belt as you tackle the challenge.

No matter what choice you make, make the choice early. Be clear on who exactly you need to serve, before you build the product.

On a Napkin

This chapter is all about getting your ducks in a row so you’re ready to tackle the design.

Here’s what you need to do

§ Research and document the characteristics of your users, especially around prior experience with the action, prior experience with the product, existing motivations to act, their relationship with the company (trust), and barriers to action.

§ Generate behavioral personas—groups of users that you expect will respond differently to your product’s attempts to change behavior.

§ Rate the actions on your list of potential action for users to take (from Chapter 4) in terms of their effectiveness, cost, motivation, and feasibility for the user.

§ Select the ideal target action, based on these criteria.

How you’ll know there’s trouble

§ It looks like all of the users are alike—they usually aren’t. You probably haven’t dug deeply enough into their existing experiences and behaviors.

§ When rating potential actions, all of the actions are rated similarly, or all of them are too expensive to the company or infeasible for the user to be realistic (sorry, go back and think up more user actions).

Deliverables

§ Detailed observations about your users

§ A set of user personas, indicating the main groups of users of our application (or potential users) and their characteristics

§ A clear statement of the target outcome, actor, and action