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

---

^[83^] This three-part design process has similarities to Sebastain Deterding’s descriptions of game design ([ref50]), and differentiates it from a traditional UX process, where only the product (tool) itself is designed.

Chapter 6. Structuring the Action

Barack Obama was in the midst of the struggle over the Affordable Care Act (aka “Obamacare”). His team wanted to mobilize supporters to call into radio programs in support of the legislation. In the last election cycle and beyond, they had built an impressive set of online tools to onboard potential supporters and get them involved in the campaign—from calling potential voters to making campaign contributions themselves.

But calling into a radio show? That was a particularly nasty challenge, and something that most American’s aren’t familiar with doing, especially about a piece of new, complex legislation.^[84^]

How did the campaign do it? Figure 6-1 gives a screenshot from the campaign’s online mobilization platform, circa February 2010. They intelligently structured the action into something volunteers could reasonably do. They broke the action down into three manageable chunks. They automated parts of the process, such as figuring out what number to call. They simplified and provided “defaults” for other parts of the process, with a script of discussion points to mention during the call. They gave clear instructions. They provided positive encouragement.

Figure 6-1. Image from barackobama.com as of February 2010; snapshot taken by http://www.thepoliticalguide.com/

That’s what this chapter is about—structuring an action so people can actually do it. We’ll start by breaking down the action into its component parts, and then simplifying them and tailoring them to what we know about our users. In doing so, we’ll develop a start-to-finish behavioral planshowing how we envision people using our product to change their behavior.

Start the Behavioral Plan

You know what you want to do—help volunteers call a radio show on behalf of your cause. You know something about your users—they are interested volunteers, but most have never called a radio program as part of an advocacy campaign. Now what?

Well, in order to call into a radio program, the volunteer will need to:

1. Find a quiet time and place with a radio and a phone.

2. Identify the radio program.

3. Listen to the radio program for an appropriate time to call.

4. Get the number to call.

5. Work up the gumption to actually call.

6. Call the program.

7. Convince the person screening calls that the volunteer has something interesting (and not crazy) to say.

8. Say something intelligible on the radio show itself.

9. Tell the volunteer HQ that the call was made, so other volunteers can spread out their efforts to other shows.

That’s a heck of a lot to do. Imagine if your product simply told users to “find a radio program and call them about this issue.” Each person would have to plan out the long list of things required, find the confidence to try this new strange thing, and not get distracted by other concerns along the way. They would also need to do some serious prior planning—planning ahead to find the program, find time in the day to call with having access to a radio, thinking about what to say, and so on.

Good luck. In fact, only a fraction of Americans have ever called into a talk show, and an even smaller subset has called in this premeditated, advocacy-oriented way.^[85^]

To use another example, for someone to take up running as exercise, there’s a lot more that’s required than simply walking out the front door and starting to run. Some of the prior steps include (a) getting running shoes, (b) identifying a route and “reasonable” distance, (c) finding the time to do it, (d) remembering to do it, (e) making sure you haven’t eaten heavily beforehand, and more. Again, a heck of a lot to do.

That’s why we have products that can help people take action and make unwieldy tasks like these feasible. The process starts by writing out the obvious steps a user would normally take to complete the action. Make it detailed. List each physical and mental piece of work that’s required, like the radio program example.

Now that you have a basic list of steps, let’s flesh it out into a full behavioral plan.

Write or Draw It Out, and Add Behavioral Detail

The behavioral plan is a depiction of the individual steps users should take from whatever they are doing now, all the way through using the product and completing the target action. Some of those steps will occur inside of the product, and some require behavior that is completely outside of it. The plan examines, at each step of the way, what’s going on with users and why they would continue to the next step.

For those in the UX world, this should sound familiar, and intentionally so. You can express the behavioral plan with a variety of design tools. I’m partial to customer experience maps, like the one depicted in Figure 6-2. They can not only include the stages of the individual experience, but they can also draw out the “customer types” (similar to our personas), areas of frustration and delight, and user emotions along the way. Related tools include a touch-point inventory and map, empathy maps, and journey maps ([ref108]).^[86^]

Figure 6-2. Part of a customer experience map from Mel Edwards, desonance.wordpress.com

Personally, I don’t have a graphic design background, so I’ve used much simpler tools to accomplish the same thing:

§ The humble flowchart, with notes in a sidebar

§ A written narrative, describing the user’s experience and mental state at each step

§ A hierarchical outline, where each top-level point is a step in the user journey and under each point is a description of what’s happening with the user during that step

No matter which tool you use to express it, developing the initial behavioral plan is a bit different than a normal customer experience map process (if you’re familiar with that process; if not, don’t worry). Namely, make sure you cover the following points:

1. Write/draw out the rough sequence of steps in the real world—not just in your product—that a user must take to complete the action. (That’s what we did in the previous section, listing the nine steps that person would have to take to call into a radio program.)

a. The reason I start with the real world is that for many behaviors—controlling finances, exercising, getting politically active, decreasing energy usage—the product only interacts with part of the story, but all of it determine whether users will actually change their behavior or not.

b. To be successful, you’ll usually need to plan for how the product indirectly affects those other steps.

2. Label each of the steps as:

a. Something that the user must do within the product;

b. Something the product should do in response to the user; and

c. All of the other things that need to be accomplished “in the real world” (outside of the product) on the behavioral plan.

3. Look for missing steps, especially for new users. Take the perspective of a completely new user—one who has never interacted with your product. Are there additional steps required in the beginning (e.g., registration)?

4. Look for one-time steps. Take the perspective of an experienced user—one that has often interacted with your product. Are there steps that can be skipped for experienced folks?

For example, in the case of the Obama campaign, with volunteers calling in to radio programs, some of the steps clearly had to occur outside of the product—such as 1, “Find a quiet time and place with a radio and a phone” and 3, “Listen to the radio program for an appropriate time to call.” Most of the rest could be done within the app. For repeat-callers, they might need to do 2 or 4 (“Identify the radio program” and “Get the number to call”).

That’s the initial behavioral plan. Nothing too fancy. Now it’s time to refine it and add some more behavioral magic.

Tailor It

With a simple sequence of steps in hand, now it’s time to apply what you learned about your users in Chapter 5. This is the same basic process that we went through in that chapter, but now we repeat it for each of the individual steps in the behavioral plan.

1. Take each of the main personas developed in Chapter 5, and walk through the process from their perspective, as if you’ve never thought about the product before:

a. Is this familiar or unfamiliar? What are you thinking? What’re your motivations? Would you continue to use the app?

b. The responses to these questions can be expressed with a set of simple comments on sticky notes.

c. Jot down or attach the personas to the behavioral plan to help keep them in mind.

2. See if the steps can build on existing skills the users already have.

3. Note particular obstacles users face, and see if the steps can be changed to avoid those actions.

You have the most control over steps that occur within the product itself, of course. But you can also use the product to reach out of screen and touch the user’s daily life. For example, guidelines given within the product, and even the marketing materials that surround the product, define the action for the user. They shape how the users think about the action, and what it is they try to accomplish, in their daily lives outside of the product. The basic definition of what behavior is being changed (and how) can and should be tailored to fit the user base.

Back to the Obama example: two of the personas that designers had to contend with were completely inexperienced, first-time volunteers and very experienced and efficient “just get it done” folks, who wouldn’t want to be slowed down by a lot of handholding. Major obstacles for the first-time volunteers would be step 5 (“Work up the gumption to actually call”), and step 8 (“Say something intelligible on the radio show itself”). Clear instructions on the screen, with a sample script, could help inexperienced people get past that hurdle, without unduly interfering with experienced callers.

Simplify It

Pare It Down to the Minimum Viable Action

Remember that the Minimum Viable Action is the shortest, simplest version of the target action that the users absolutely must take to test the idea. As you’ve thought through the target action, and broken it down into a sequence of steps, you might have realized that there are extraneous parts. Or that you can think about the action differently and make it simpler. Or you might have started with a MVA, but were tempted to add on bells and whistles as you sketched out the sequence of steps. Well, now it’s time to tighten up that MVA. Cut back until only the necessary remains:

§ Cut repeated actions down to the first action. One-time actions are easier for users to perform and engineering teams to build than repeated ones, all else being equal. And they still provide valuable insight into whether the software works at supporting the behavior.

§ Cut big actions down to simpler ones. Will the target outcome be achieved if the user takes a shorter, simpler action? The goal is to test the core premise, as with a Minimum Viable Product (i.e., instead of asking people to call all of their local radio stations, can they just call one?).

§ Drop steps in the sequence altogether that are just nice to have. For example, allow the user to take notes on how the call went.

§ Focus on the high-risk, uncertain, parts of the sequence and flesh them out (i.e., getting the person comfortable making a call at all) before developing the lower-risk parts (having the person customize the script to use during the call).

Cheat If You Can

Now that the action itself is back down to the Minimum Viable Action, let’s see how we can shift the burden for the remaining work from the user to the product—i.e., use the “cheating” strategy overall, or within each of the individual steps the user has to take.

Look over the behavioral plan again. It is possible to automate away the whole action? If not the whole action, is it possible to cheat at any of the individual steps along the way?

With the Obama call-in radio program, it was impossible to automate the whole thing. But certain parts of it could easily be automated and defaulted. For example, the advocacy platform could:

§ Automatically match the user up with a call-in radio program and provide the necessary phone number to call, saving the user the need to research relevant radio shows.

§ Make finding a radio unnecessary (incidental to using the software), by streaming the call-in program through the app itself.

§ Provide intelligent defaults for what to say while on the air (e.g., a simple script that the user can edit and personalize as needed).

Obama’s call-in campaign for the Affordable Care Act, shown in Figure 6-1, did all three of these. That’s where it really shined.

By simplifying the process, automating, defaulting, or making steps incidental, you remove unnecessary work for the user. In terms of the Create Action Funnel from Chapter 2, that means decreasing the costs of action (part of the mind’s conscious evaluation) and increasing the basic physical ability to take action. This simplification process allows you to focus attention on more intractable behaviors or more exciting (to the user) parts of the application. Another way to accomplish this is to find potential habits.

Identify Potential Habits

Look over the behavioral plan again. Are there steps that are frequently repeated without much variation? For example, maybe your behavioral plan includes “run each morning for 30 minutes.” Those are candidates for habits. Following the discussion in Chapter 3, is there a clear cue that either already exists or can be added to the product that will tell the user “it’s time to act”? Is there an immediate, meaningful reward at the end of the step? If so, then you can simplify the problem of “help the user do X 1,000 times” to “help the user build a habit around X.”

Make It “Easy”

In addition to simplifying the action itself, you can help make it “easy” for the user to do, in two ways:

§ Easy for the user to understand, and thus for the application to convey to the user

§ Feasible to accomplish, from the user’s perspective

The first one is relatively straightforward. Look at the behavioral plan, and specifically the parts that the application instructs the user to do something. Write down how those parts would be described to a prospective user in at most two sentences.

For each step, ask whether each of the user personas identified in Chapter 5 would understand that description. As needed, run it by some sample users (I’ll talk about formal user testing later, though).

Another way of thinking about understandability is cognitive overhead, or “how many logical connections or jumps your brain has to make in order to understand or contextualize the thing you’re looking at” ([ref48]). Figuring out what to do shouldn’t be guesswork for the user. That may mean making the action slightly more difficult to undertake, in order for it to be easy to understand ([ref116]).

The second part is all about appearances, from the user’s perspective. We briefly discussed this in Chapter 2 under the ability stage of the Create Action Funnel: if you think you aren’t going to be able to do something, you’re less likely to even try. The underlying research comes from Bandura’s concept of self-efficacy: the belief that you yourself can be effective at the task ([ref10]).

Combine Where Possible

Each step in the sequence should represent the largest possible chunk of the work that is still understandable and feasible. Look for ways to combine multiple steps into one. Largest? Yes. There is a tension between breaking the action into steps to make each one more manageable and having so many steps that it overwhelms the user. There’s no hard-and-fast rule, but keep this in mind especially when you see any sequence that’s more than a dozen individual steps!

Avoid Common Mistakes

Here are two of the common mistakes I’ve seen at this stage.

It is Easy!

The first common mistake is to be satisfied when it’s easy for you to do. Too often, especially in my prior political advocacy work, I’ve seen campaigns that expected people to come to a night-long vigil, write a letter to their representatives from scratch about an issue the author knew little about, or organize a local group of activists on their own. These are each daunting, complex tasks to someone who has never done them before—though relatively straightforward to those who have already built up the expertise.

It’s quite difficult to step outside of your own experience (if only because once you think of the action, your System 1 immediately activates the relevant prior experiences, and it really does feel easy on an intuitive level). If there’s any doubt though, run the proposal by someone who has never taken the action before.

Hard Work Builds Commitment

Another common mistake is to believe that work makes commitment, and to allow the user’s tasks to be difficult on purpose. This view is half-right, half-wrong. Effort can build commitment to a product, and a commitment to continue what you’ve started. People that complete difficult tasks (successfully, and without undue grief) are more committed to continuing further. In psychology, and economics, there’s the well-known mental blip called the “sunk cost effect”: the more work you put into something, the less willing you are to let go of it—even when it is not in your economic interest.

If users see the target action as a difficult, substantial task—great. After the action is completed, they will be committed. The product’s job is to get as many people as possible across the finish line. The “make ’em work hard” approach leads to very committed people who finish—but those committed people are only a small subset of the people that could have completed the task; that creates the illusion of effectiveness—because everyone else has already been filtered out!

So, building commitment doesn’t mean that each step needs to be a pain in the butt, or that we should design an application to be difficult. For any “hard” behavior (exercising, learning a language, etc.), there will be things that the product can make easier, and things that it can’t. Make the things that can be made easier easy—and then build up the excitement on the remaining tasks that are hard. Provide users with a sense of accomplishment for the tasks that are truly difficult—and not just badly designed.^[87^]

Provide “Small Wins”

In addition to being easy, each step should be meaningful enough that the user can feel a sense of accomplishment afterward. It’s up to the product to help users feel that accomplishment (often by presenting it as progress toward the target action), but the step itself needs to support it. In the research literature, this is called “small wins”—if after each small step, people feel they’ve done something, and they’re closer to finishing their goal. They are then more likely to continue.

For example, in my work at HelloWallet, we had a tricky problem when we designed our guidance—how much should you encourage people to commit to save each month? Authors such as [ref30] tell their readers to save about $10 a day. That is simple and clean, but either way too easy or too hard for many users. We have users that struggle to put aside $10 each week, let alone each day; we also have users to whom $10 is a rounding error, and a laughable goal. So, we constructed a meaningful step on the path to greater savings that provided small wins, regardless of their financial means—we calculated the target amount as a percentage of income (and then rounded to the nearest clean, simple number that people would remember).

In order for an action to provide a “small win,” it needs another characteristic—it must be clear to the user that the step has actually been completed. In other words, there must be a clear definition of success or failure. Weight loss applications are a great example—they set a specific, unambiguous weight target. An example of an unclear target would be a step that tells users to “cut down” on smoking. It doesn’t allow users to know if they are succeeding: if users have to wonder whether they’ve done it right or not, they are distracted, and you lose them.

On a Napkin

Here’s what you need to do

§ Break the target action into discrete steps that the user needs to complete. These pieces should be:

§ Simple and straightforward (easy to understand)

§ Easy to complete (both appearing easy to the user and being easy in practice to execute)

§ “Small” (so that the user sees clear progress after each step)

§ Meaningful enough to reward after completion

§ Straightforward to see when they are complete (so they the user will clearly know if the action was successful or not, immediately after making an attempt)

How you’ll know there’s trouble

§ When team members can’t clearly and simply convey what the user is supposed to do

§ When no one outside the company has been asked how difficult the action is

Deliverables

§ The behavioral plan: the specific sequence of steps users should take