If you wanted to develop a new product to help people lose weight, what would you do?
How about something that helps people track how many calories they’re eating, like MyFitnesPal?[68] Or a diet plan that says what we should eat and what we should avoid, like the Paleo Diet?[69] How about a diet pill that reduces appetite, like the once highly popular (but unfortunately fatal) fen-phen?[70] Or, of course, an exercise app, like the many other such apps already out there?
These are all things that jump to mind because they’re familiar, and relate to seemingly obvious actions that people can take to lose weight. Brian Wansink has a different approach. He’s studied how we eat food for decades. He directs Cornell’s Food and Brand Lab and has authored over a hundred academic articles and numerous books about eating.[71] He’s also really funny (he used to be a stand-up comic).
Wansink has studied what happens when you give people free but really, really stale popcorn before a movie (they eat it anyway), and what happens when you secretly refill people’s soup bowls while they are eating so they can’t reach the bottom (they don’t notice and just keep eating; see Figure 4-1). He’s coined the term “mindless eating” for how our eating behavior is often on autopilot ([ref181]). And Brian has a new weight-loss product for us—it’s called a smaller dinner plate.
Figure 4-1. A cartoon from Brian Wansink, illustrating that the larger the serving container, the more we eat[72]
He’s started the “Small Plate Movement,” encouraging people to use smaller dinner plates, which in turn decreases how much food they eat without making people feel hungry. His research has shown that we usually have no idea how many calories are in the food we eat, and we don’t even know if we’ve eaten enough to be satisfied. Instead, our minds use cues in our environments to tell us how much to eat and whether or not we’re done eating. One of the most common cues we use is seeing that we’ve eaten everything on our plate.[73] Shrinking the plate in turn shrinks how much we eat.
First of all, that’s amazing. Second, that’s a powerful example of how important it is to carefully think about alternative approaches and evaluate potential changes in behavior before you build the product. In other words, we should think about product discovery explicitly—to determine what’s the right thing to build—rather than jumping to an “obvious” solution, like an exercise app. Part of that discovery process also means finding the right match between the behavior, the users, and the company—to find out what is both interesting for your users and cost-effective for the company.
By the end of the discovery process, we’ll clarify three things:
- The target outcome
What is the product supposed to accomplish? What will be different about the real world when the product is successful? For example, overweight people should lose 10 pounds because of this product.
- The target actor
Who do we envision using the product? Who will do something differently in their lives, and thus accomplish the target outcome? For example, normal, everyday people who eat dinner at home or at a restaurant.
- The target action
How will the actor do it? What behavior will the person actually undertake? For example, users should serve food on a smaller dinner plate.
Throughout the book, we’ll use those three terms to describe the outputs of the discovery process: the outcome, the actor, and the action. Along the way, we’ll elicit, evaluate, and refine these three ideas, until the key stakeholders are all on the same page, and potential problems have been identified early and have been resolved. Here are the five stages of behavior discovery:
Clarify the overall behavioral vision of the product.
Identify the user outcomes sought.
Generate a list of possible actions.
Get to know your users and what is feasible and interesting for them.
Evaluate the list of possible actions and select the best one.
This chapter covers steps 1–3, and Chapter 5 covers steps 4 and 5.
Your company may have already have completed some of the initial stages of the behavior discovery process, though. You should feel free to jump ahead to the part that’s relevant; however, you may also find it useful to quickly scan the earlier parts to see if there’s anything you missed.
Let’s say a company has an overarching vision for its new product and its impact on its users, the company itself, and on society. The vision for the product may come directly from the company’s mission statement. For example, the Sunlight Foundation, a nonprofit that works toward government transparency, gives its mission statement on its website:[74]
OUR MISSION
The Sunlight Foundation is a nonprofit, nonpartisan organization that uses the power of the Internet to catalyze greater government openness and transparency, and provides new tools and resources for media and citizens, alike.
The vision for each of its products clearly follows from this organizational mission. For example, it has a tool, Poligraft, which “allows anyone to uncover levels of influence in federal and state-level politics and the news coverage of it.”
For a company developing a wearable computing device (e.g., the Nike+ FuelBand or Fitbit One), its product vision might be “helps people exercise more.”
Let’s start the discovery process off by simply getting the product vision down on paper. The vision can be general and somewhat vague—that’s fine. It allows us to start the conversation about the more specific, concrete impacts that the product should have—the target outcome.
After you have a general sense of the vision for the product, you should ask the following: what should be different about the world when the product is successful? What’s the specific, concrete change that should occur because of the product? What could a third party see, hear, or touch?
The answer to that question is the product’s desired outcome. Another way of thinking about it is the tangible thing that the company seeks to accomplish with the product (remember, I use “company” as shorthand for corporation, nonprofit, or government agency). The outcome is the company’s concrete and measurable goal that it hopes to accomplish with the product. I like the word “outcome” rather than “goal” because it feels more concrete—it focuses attention on something changing in the world.
Write down an initial statement of the product’s desired outcome (or outcomes).
Next, let’s refine your target outcome with some probing questions.
- Which type?
Does the product ultimately seek to change something about the environment (e.g., clean water) or about people (e.g., healthier bodies)?
- Where?
What is the geographic scope of the impact (e.g., Chesapeake Bay)?
- What?
What is the actual change to the environment or person (e.g., decrease nitrogen pollution)?
- When?
At what point should the product have an impact? We’re looking for the order of magnitude. Unlike the others, this doesn’t need to be precise at this point—“in a few months” or “in five years” is fine.
Write down the answers to these questions with a simple, clear statement that summarizes them. For example, “This product should cause a decrease in nitrogen levels, an environmental pollutant, in the Chesapeake Bay over the next five years.”
Based on that statement of the desired outcome, define a metric that you can use to gauge whether the product is successful or not—nitrogen levels in the water or body mass index (BMI) of school children, for example. You don’t need to settle on the exact measurement yet—but if you can’t define one at all, then the outcome isn’t concrete enough.
Here’s an example of clear outcomes that are readily measurable, and ones that aren’t:
- Clear, measureable outcomes
Californians will have an average BMI of 24. Employees at Company X won’t smoke.
- Unclear, difficult to measure outcomes
Users will gain experience with exercise. Users will understand the dangers of smoking.
Having a clear outcome in mind doesn’t mean that you’re omniscient, or that you’re locking your company into a strict path for the next few years. Instead, it’s a solid point of reference. As problems arise, you can settle disagreements of fact (does this design work or not?) by measuring against the outcome. And, you can settle disagreements of vision (is this the right goal for the product or not?) by redefining the target outcome when needed—as long as the new outcome is also clearly defined.
A common problem that many companies face as they define the product’s target outcome is that they want to talk about something within their user’s heads. Education. Confidence. Even skill at doing something. There are two reasons why states of mind are problematic.
Firstly, they are difficult to measure in a consistent and unambiguous way. States of mind can be measured with surveys, but the results of those surveys are highly dependent on the framing of questions, the order of questions, when and how they are administered, and more. “Highly dependent” = open to debate, misunderstanding, and argument. That’s exactly what we’re trying to avoid.
Perhaps more importantly though, states of mind probably aren’t what the company actually wants. Consider an NGO that trains women to be entrepreneurs: do they want the women to know what it takes to be an entrepreneur, or do they actually want the women to start new, successful businesses? If the clients knew how to be entrepreneurs, but never actually started businesses, would the NGO consider the program a success? Probably not.
Instead, we want the outcome to be something observable, outside of the individual’s head, absolutely unambiguous (to avoid arguments within the company about whether something is successful or not), and easy to measure (so you can gauge success quickly). The target outcome should define the success (or failure) of the product.
If you’re stuck thinking of what the specific outcomes of your product should be, then here are some questions to spur thought before you answer “which, where, what, and when”:
What happens next? If you have an outcome that feels right but isn’t measureable, ask yourself: what happens after that outcome? What can someone see, hear, or touch that occurs next? How do people use the new knowledge/pride/etc. they have? For example, “people learn to dance” becomes “people go dancing once a month.”
What would a stranger see? Imagine someone visited the place where the product is used (including the Internet, if that’s where it’s used), before the product was deployed, and after. That person knows nothing about the product itself, and can’t talk to anyone. What would be different? For example, “users build tighter families” becomes “users exchange more emails and phone calls with estranged family members.”
What’s the impact of the product? Why would someone pay for this product? For example, “users feel in control of their email” becomes “users have zero messages in their inbox at the end of each day.”
If you’re stuck with more than one outcome, that’s OK. They need to be organized. If there’s a clear, top-priority outcome, excellent. If not, get the stakeholders together and see if there is a majority opinion on what’s most important. Or, take the list of desired outcomes and ask for each one: would the product still be “successful” if this did not occur? Drop them, one by one.
If winnowing down the list isn’t feasible, there is another, more challenging route. Create an aggregate outcome that combines the contenders for top-priority. To do this, you need to get very specific and define a formula that combines them in a way that everyone can get on the same page. This formula is a formal definition of success for the product.
For example, say the two “highest priority” outcomes are “the product will cause decreased blood pressure” and “the product will cause decreased BMI.” A definition of success that combines them both would be “the success of the product is defined as 1 point for every decrease in average blood pressure across the target population and 2 points for every decrease in average BMI.”
Unfortunately, most companies just don’t have enough information to understand the complex impacts of the product across related but nonidentical behaviors before the product has actually been built. Personally, I’d avoid making up a formula that combines multiple outcomes and settle on a prioritization that identifies one outcome as the top priority.
You may have noticed that there are two key questions I didn’t suggest asking at this point:
- How?
For now, try to avoid delving into how the product works its magic (i.e., what action it encourages users to take to make the outcome happen). We’ll get to that shortly, after we’re armed with additional information.
- How much?
We don’t need to define a specific level of change caused by the product at this stage. (If you have one in mind, great, but it’s just not required). Often, companies just don’t have enough information to set a realistic target at this point.
Why do we need to define the desired outcomes so carefully and clearly? We want to pull problems into the present and resolve them. If the team has a mess of conflicting objectives, or something that can’t be measured, then there are problems lurking in the future. The team is likely to argue over what the product should look like as each member tries to meet conflicting, unstated objectives. The head of the company may think the product isn’t successful, but the engineers do. The grant funding agency (for NGOs) might cut off funding because it had implicit assumptions about what the product would do that aren’t being met.
A clear statement of measureable outcomes that key stakeholders can sign on to at the beginning of the project can resolve many of these problems early. And, just as with any product development process, finding and resolving problems early on is much cheaper than trying to fix things later.
In addition, a clear outcome statement is essential for revising the product to improve its impact. It forms the basis for measuring the product’s success, finding problem areas, and gauging whether proposed changes to the product are worth their salt.
One possible result of trying to state the desired outcome of the product is that there isn’t one. Either the stakeholders fundamentally don’t agree, or the product was poorly conceived and doesn’t have real-world outcomes. In that case, the product shouldn’t proceed in its current form. In the spirit of failing fast, that’s a really good outcome—and should be embraced, painful as it is.
That doesn’t mean the team needs to have consensus about what the ideal product should do; few companies operate that way. But everyone should know what to expect and sign on to the goal once the decision has been made about the product’s intended outcomes. If there are still deep divisions in the team, then problems lie ahead. The team should move on to other interesting products, or change its membership, rather than arguing for months over a product that’s ultimately doomed.
Thus far, we’ve talked about a product development process that’s focused primarily on the user and what the product can do for him or her. But I’ve found that companies sometimes take two very different approaches to behavior change. They can:
Focus on how the product will benefit the user, which in turn helps the company’s bottom line; or
Focus on how the product will benefit the company, by way of providing value to the user.
This difference is in how companies think about the value of changing behavior; it isn’t related to the behavior itself. The target behavior could be inside the product or outside the product, socially important or trivial; that doesn’t matter as much.[75]
In the first case, a company might have a vision of improving financial wellness (like HelloWallet does) and need to figure out what actions users can reasonably take that will best make that happen. In the second case, a company might have a purely self-interested goal, like increasing customer renewals, but needs to provide real value to the user in order for that to succeed. The second approach includes red-blooded capitalists as well as NGOs that need to make their case to their funders. There’s nothing wrong with that approach—as long as the companies build products that people like. But it does mean that the process of behavior discovery is different.
In the user-centric approach, the discovery process develops these concepts in turn:
Product Vision → User Outcome → Action → Actor
In the company-centric approach, the discovery process adds another step:
Product Vision → Company Objectives → User Outcome → Action → Actor
The product vision is why the product is being developed, at a high level; and the company objectives are what the company seeks to achieve, for itself, by building the product.
Since the previous section highlighted examples of the user-centric approach, let’s now walk through the company-centric process (you can safely skip this is you’re using a user-centric approach).
As before, the discovery process starts by writing down the high-level vision the company has for the product. That vision, however, should answer how the product will generally benefit the company. For example:
This product should expand the company’s appeal into new markets.
This product should increase revenue.
The product should demonstrate the expertise and capacity of the organization to take on new projects, to support new grant funding.
The product should increase public awareness and interest (or brand prestige) of the organization.
With the company’s vision for the product in mind, translate that vision into one or more specific, measurable objectives that benefit the company. For example, ask:
How will the product be judged a success or failure at fulfilling the company’s vision? How will success be measured?
What would a third party observe about the company that’s different, because of the product? Increased retention of customers? Increased upsell? More referrals of new customers?
The company’s objective might be to win 35% of the market for exercise bands among 21 to 35-year-old women. Or, it might be to win at least $1 million of additional grant funding for the next year. Write down that initial company objective.
Based on that initial statement of the company’s objectives, fine-tune it by asking who, what, when, and where the outcome occurs (similar to what we did in the last section):
- Who?
- What?
What is the actual change to the company (revenue, brand value, etc.)?
- Where?
What region or division should be affected?
- When?
How long, very roughly, should it take? If the product doubles sales, but requires 10 years to do so, is that a success or failure?
Write down the answers, and develop a single clear statement that the product development team and company leaders can rally around. You should have enough information to define how the product’s success or failure will be measured (e.g., customer renewal). We don’t necessarily need to define the precise expected value (1.5 increase in sales), nor do we need to define how the product will accomplish this magic, yet.
Building your business or establishing your expertise to funders is great, but your users probably don’t care. Sorry. You need to deliver something of value to them. Without that value, you can’t meet your business objectives.
So, putting aside the financial (or other self-interested) goals of the product for a moment, what does the product mean for users? We want to define the measurable changes in the world that are caused by the product that the user would care about. Here are some questions to help draw out those outcomes:
What does the product deliver? What’s its core value proposition, as the user would see it and measure it?
After users have used the product, what’s different about the world?
What tangible thing would a user look at (or hear or see), sometime after using the product, and say, “Hey, I want to use that product again”? (The product itself doesn’t count, sorry.)
How would you know that your users have gained the maximum value from your product?
What do the users do because of the company’s increased brand awareness?
For example, consider the company objective of winning 35% of the market for exercise bands among 21 to 35-year-old women. A specific user outcome might be: the product helps the user lose 25 pounds over six months. Or the product helps the user drop two waist sizes.
In the previous section, we discussed a set of rules and tips for clarifying target outcomes. All of them apply here: avoid states of mind, make sure the outcome is measurable, find disagreements early, and don’t obsess about how the product will achieve these outcomes yet.
Every product team has constraints. Constraints turn the unmanageable task of “building something” into a real concept that the team can actually design and engineer. We’ve already talked about some of those constraints—the vision of the product, the product’s target outcome, and the company’s business objectives. Now, we want to identify additional constraints that will shape how the product will interact with and affect its users.
Many of these questions are normally answered as part of a project brief for a design consultancy or a marketing requirements document. They may be part of a company’s standard set of operating assumptions. Either way, make sure they are clear. The goal is to avoid dead-ends further down the line.
Here are constraints that are especially relevant for this process:
- Channel
If the product must be a mobile app (for whatever business reason), you need to know that up front.
- Time frame
How much time does the product team have to work? This will be essential when we evaluate particular behaviors that the team needs to design into the product.
- Resources
What resources will be devoted to the team, if known up front?
- Tone
Some companies need a serious application that fits their internal culture and outward identity.
- Scope or target audience
Does the product absolutely need to impact a particular portion of the target audience for political or business considerations?
Be careful about what “constraint” means, though. It’s only a constraint if there is a mandate. If it’s an assumption about how the product should function in order to deliver its behavioral impact, put it aside for now. We’re looking for hard constraints.
After identifying the top-priority outcome that the company seeks to accomplish with the product, the next step is to translate it into actions—a list of specific behaviors that a user might take to make that goal a reality.
Let’s say the top-level outcome is to help users have more money for savings—something near and dear to our hearts here at HelloWallet. There are numerous actions a user could take to make this happen—like finding a higher paying job, selling unused assets, getting a lower mortgage rate, or spending less money on daily purchases.
For most companies, especially those with existing products on the shelf, the universe of possible user actions is tightly constrained by the company’s business model, product strategy, and internal culture; that’s why we drew out these constraints in the previous section. At HelloWallet, for example, we looked for actions that would be appropriate for a wide range of users and weren’t being well covered by existing products. So, job-hunting tools were out, as were mortgage finders.
The goal is to generate a list of potential actions: at least five actions that are very different from one another but still fit within the realm of possibility for the company. For each action, we want to define:
Who is doing the action?
What, specifically and physically, is the person doing?
How does it cause the target outcome?
Usually the “who” is simple—it’s the users of the product. But not always: the user may influence another person, who then does the real work.[76]
Naturally, we want to make sure the proposed action has some chance of being successful. So, dig into the question, how does it cause the target outcome? The proposed action should directly and clearly cause the outcome that the company is seeking. If the current action doesn’t actually cause the target outcome, then ask, is there another, subsequent, physical action that is required to cause the outcome? If there is a clear subsequent action, focus on that one instead. We want the behavior that directly supports the outcome.
For example, going to a seminar about the importance of community engagement is one possible action that people can take to get involved in their communities. But the direct link between the action (go to seminar) and outcome (more members in community organizations) is a bit tenuous. What if the person doesn’t pay attention? What if he has been forced by his spouse to attend lots of “get more engaged” events in the past? A better, more immediate action is “volunteer at local soup kitchen.” That’s the real point of the seminar (we assume) and has a direct link to the outcome we care about.
As we did for the company’s target outcome, we’re looking for a concrete, specific definition. Physical, measurable actions the users will take. Avoid actions that just affect the user’s mental states (reading educational material) and dig deeper into what the user does with his new education that causes him to do something differently, and achieve the outcome.
For example:
Outcome sought: people don’t get lung disease.
Vague action: users avoid cigarettes. (Does that mean they cut down on smoking? Go cold turkey?)
Action that’s too far removed from the outcome: users attend a seminar about the dangers of smoking (OK, but do we care if they attend? Or that they actually stop smoking?).
Clear action: users don’t buy cigarettes at all.
You’ll notice that the action doesn’t specify how exactly the product will help the user not buy cigarettes. It could be by helping him avoid stores where cigarettes are sold. Or by decreasing the desire to smoke with nicotine patches. That’s coming up soon.
Like the target outcome, the target action isn’t written in stone. It should be clearly defined so that it can be built into the product and clearly measured. The definition, and measurement, will help with fine tuning the product. They’ll also help with revisiting and revising the target action itself, if the need arises.
How can you figure out the actions that people could take? What actions could your product cause, which would make the target outcome happen?
There are lots of brainstorming and creative thinking techniques out there. I cut my teeth reading Edward de Bono, who provides fascinating discussions of lateral thinking ([ref45]). But use whatever works for you. Don’t stop until you have at least five different actions.
If you don’t know where to start, here are some approaches that can help:
What does someone do right before the outcome occurs?
What’s unique about the company? What user actions are easier to facilitate because of those unique aspects of the company (specialized skills, a special relationship with the users, etc.)?
What do users already do that’s similar?
Why aren’t people making the outcome happen?
Why would users want to make the outcome happen? What action is most natural for them to take, if they are motivated?
Observe your users in practice. People find creative ways to change their own behavior all the time. Watch them for inspiration on what the product can do.
Draw from a list of random words (yes, I really mean random—this is a technique from Edward de Bono). How is the word related to the outcome? How would a person act based on that word, in support of the outcome?
If possible, start small: go with the small, easy things that the person could do to accomplish the outcome. That will make it faster to test and can be expanded upon later if needed. Look for the existing skills and habits of the users wherever possible, and build on them. Try some crazy ideas. At this stage, don’t self-censor and limit actions that seem impossible.
Some companies will be tempted to skip this step because there is an “obvious” action for their users to take, given the target outcome. Bear with me for a second and give it a shot anyway. It’s sometimes difficult to mentally separate the target outcome from the “best” action for users to take. For example, let’s say you have a clearly defined target outcome: helping users put more money into savings. The “obvious” answer is to set a budget and spend less on something. The problem is that that’s also a really hard action for most users to undertake (at least, head-on). Other, less “obvious” actions may work better (e.g., automatically deducting the money from your paycheck, so it’s never in your checking account to tempt you).
The action doesn’t need to be something that the user would do while using the product itself—dieting is a great example. People don’t (usually) eat while they are logged in to a dieting app on their computer or phone. Dieting occurs when people make choices about what to eat and how much. Many dieting applications are designed to help inform and prepare individuals so that when they are making food and eating choices, they avoid temptation and make better choices for themselves. There’s a danger there, though—the further removed the product is from the action itself, the less likely it will be that it causes people to take action.
As you think of actions, there’s necessarily a leap that occurs between the action and the outcome—the assumption that the action will actually work and produce the outcome the user and company seeks. We’ll draw out that assumption and judge how risky it is a bit later. For now, I suggest focusing on coming up with some cool new ideas, even if some of them are uncertain.
The Minimum Viable Action is the shortest, simplest version of the target action that users absolutely must take to so that you can test whether your product idea (and its assumed impact on behavior) works. It builds on the lean startup concept of the Minimum Viable Product: the smallest set of features that allows the product to be deployed and tested in the field.
You can think about the Minimum Viable Action (MVA) like this. You’ve mapped out what you’d like users to do. Excellent. Along the way, you’ve made some core assumptions about how the user will feel, react to, and interact with the product. The problem is: no one really knows how people will respond, and the more intractable the behavior, the less certainty we have that a product will be able to change it. As I mentioned at the beginning of the book, there aren’t any behavioral magic wands, and we should expect to be wrong about some things. For that reason, I strongly believe in testing ideas out in the field. And, in testing as early as possible to adapt and learn as you go along.[77]
How do you find the Minimum Viable Action? Look over the list of potential actions you’ve generated. I think of the Minimum Viable Action as something that you arrive at by cutting back on what naturally came to mind the first time. Cut back from the obvious until only the necessary remains.
If you have a repeated action, can you start by building the product to support a one-time 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. For example, if you want to help people lose weight by using smaller plates, see if they will use a smaller plate at all before trying to change their dining habits at home.
Even if the target outcome won’t be achieved initially, can you cut the action down into something smaller and shorter but still fundamentally the same basic task? The goal is to test the core premise, as with a Minimum Viable Product (i.e., instead of asking people to replace all of their plates, can they just start with one small plate?).
Can you identify the high-risk, most uncertain, aspects of the action (i.e., having people eliminate other plate options from their house) and either remove them altogether from the target action (e.g., it’s OK if they keep the old plates, as long as they are hidden) or test them before developing the lower-risk aspects (having the person eat dessert on a saucer plate)?
Will the target outcome be achieved if the user takes a shorter, simpler action?
I waited to introduce the concept of a Minimum Viable Action because I find that people don’t naturally think about the smallest possible action to change behavior. We like to think big. That’s fine. It’s useful, good, and most natural (i.e., easiest) to express that big vision first. That provides a blueprint that the team can go back to and draw upon as the product develops.
However, once those big behavior change thoughts are up on a board, and we see all of the pain we’re thinking of putting our downtrodden users through, then reality should hit—the more work that users have to do, the less they are likely to do it (with some important exceptions I’ll cover later). Hence, the Minimum Viable Action.
Here are some examples of actions that the team might think up in order to help users learn Spanish:
Complete an online training course.
Visit Spain for a few weeks to be forced to speak Spanish.
Label each item in the household with their Spanish names.
And here are some simpler MVAs to test the core assumptions of the approach and its impact more quickly:
Complete a single module of an online training program.
Get a Spanish-language conversation partner who is committed to only speaking Spanish with the user.
Label a few items in daily use with their Spanish names.
OK. Now that we have a rough set of potential actions that “the users” can take, the next chapter will dig deeper into exactly who the users are so we can evaluate what action will be most effective for them to take.[78]
Talking about desired outcomes and target actions can be a bit abstract, especially given the tremendous range of possible products that this approach can be applied to. So, let’s looks at some concrete examples (Table 4-1 and Table 4-2). Since the approach is somewhat different for user-centric versus company-centric products, I’ve broken them up into two different tables. To make the comparison clearer, I’ve started both tables off with a single product—an exercise tracker—to show how the analysis would proceed from each perspective.
Table 4-1. User-centric examples
EXAMPLE 1 | EXAMPLE 2 | EXAMPLE 3 | |
|---|---|---|---|
Product | Exercise tracker and app (e.g., Fitbit) | Financial wellness app (HelloWallet) | Government transparency app (e.g., Sunlight Foundation) |
Vision | Improve fitness of young city dwellers | Democratize access to financial guidance | Inform public about corrosive power of money in politics |
Outcome | Decrease BMI | Americans have sufficient emergency savings | Decrease in vote buying |
Action | Users should walk 10,000 steps a day | Users automatically transfer money to savings account each month | Users research lobbying money in their congressional district |
Table 4-2. Company-centric examples
EXAMPLE 1 | EXAMPLE 2 | EXAMPLE 3 | |
|---|---|---|---|
Product | Exercise tracker and app | Grocery store website | Conference calling app/website (e.g., Speek) |
Vision | Build new customer base among young city dwellers | Expansion of business into upscale grocery shoppers | Build business around premier features of new conference call system |
Company objectives | Double number of urban customers | Double number of upscale buyers | Increased usage of free Speek app among users |
User outcome/user need | Desire to be healthier | Learn how to cook healthy meals | Easy conference calls |
Action | Users should walk 10,000 steps a day | Users take free cooking classes on grocery website | Users distribute their free Speek URL to conference call participants |
There are a few things to point out here:
Despite our best efforts, there may be a big leap between the outcome and the action. Does user awareness of congressional lobbying decrease vote buying? That’s a tough question to ask. The purpose of this chapter was to provide a clear direction for the product development process, uncover hidden assumptions, and, sometimes, determine that a pivot is needed, and a different approach or behavior should be targeted.
Sometimes the outcome that’s really important is an action that the user takes. The first example could easily have had “users walk” as the outcome, as well as the action. This occurs when the action itself has an unambiguous, real-world outcome (like walking). However, I argue that companies should avoid equating the two in most cases. It’s an easy way to hide assumptions about why the action is important, and thus to potentially choose the wrong action.
- Here’s what you need to do
Define the real-world outcome that the product should have. Avoid states of mind—focus on measurable outcomes that define the success or failure of the product.
Translate company-specific goals (e.g., increased profit) into real-world outcomes that the user actually cares about.
Brainstorm actions that people might make the product’s intended outcome a reality.
Trim each action down to its Minimum Viable Action.
- How you’ll know there’s trouble
The company can’t agree on the intended outcome of the product.
The company knows what it wants but doesn’t offer something that users care about.
- Deliverables
A clearly defined outcome and a list of possible actors and actions they would take
[70] See [ref107] for the story of fen-phen and how it rose to prominence and was later pulled from the market (http://www.nytimes.com/1997/09/23/science/how-fen-phen-a-diet-miracle-rose-and-fell.html?pagewanted=all&src=pm).
[71] See Vita on http://brianwansink.com; version as of publication date: http://brianwansink.com/wansink_vita_11-09.doc.
[72] The size of our plates (and cups, popcorn buckets, etc.) has various effects on eating behavior. One effect is on how much food we put on our plate, another is on how much we eat, and yet another is on how much we consider normal to eat (e.g., [ref182]). See [ref181] for a funny and very accessible account of the research in this space.
[73] Wansink has numerous cartoons summarizing his research and available for teaching purposes. See http://foodpsychology.cornell.edu/.
[75] In other words, this is a different distinction than the one I made in the Preface about behavior change affecting a behavior within a product or outside of it. In either case, a company could start with the benefit for user or the benefit for the company.
[76] For example, that’s common with advocacy websites that try to influence policy makers to change regulations (like on the cost of gasoline), which then change behavior in society to drive outcomes like lower greenhouse gas emissions. My thanks to the folks at ForumOne for pointing this out.
[77] A lean startup approach can certainly help, but isn’t required. In a new product development process, for example, there are steps in the waterfall that are explicitly devoted to testing out product ideas—early on. They just aren’t iterative.
[78] I intentionally place the process of coming up with possible actions before generating user personas because I want the idea-generation process to be free of strong self-censorship on what actions the users are likely to take. I’m sure there are good examples of when these should be reversed, though.
Get Designing for Behavior Change now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
