Moving from Conceptual Designs to Interface Designs - Designing the Interface and Implementing It - Designing for Behavior Change: Applying Psychology and Behavioral Economics (2013)

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

Part IV. Designing the Interface and Implementing It

In the following chapters, we take the conceptual plan for the product and turn it into something real and tangible that people can see and react to. We’ll go through a very similar design process as we did in Chapter 6 Chapter 7 Chapter 8, when we first developed the conceptual plan (Figure 23):

1. Structuring the action to make it feasible and inviting for the user,

2. Constructing the environment to support the action, and

3. Preparing the user to take the action.

But instead of designing the high-level functionality, we’ll use these techniques on the interface designs and on the implementation of the product itself. In terms of the iterative product development process first introduced in the Preface, we’re in the middle of the third stage.

Chapter 9 describes how to extract user stories (in an agile development environment) or formal specs (in sequential product development), and how to generate the initial interface designs based on them.

Chapter 10 discusses the ins and outs of tuning the interface designs for their behavioral impact. And, finally, Chapter 11 talks about how the team actually builds the product itself.

covers the user stories, interface designs, and building the actual product

Figure 23. Part IV covers the user stories, interface designs, and building the actual product

Chapter 9. Moving from Conceptual Designs to Interface Designs

Take Stock

We now have a behavioral plan that says what the product needs to do. We’ve found the Minimum Viable Action, tailored it based on users’ prior experiences, automated parts of it, and made the rest understandable and easier where possible. We’ve thought about how the environment (the product and the user’s real-world context) builds conscious and emotional motivations, provides cues, generates feedback, and side-steps competing behaviors. And, finally, we’ve thought about the information and preparation the user needs to succeed.

What we have is an essential, vital, unavoidably important to-do list for the user and for the product. The design team must now transform the sequence of steps from a dull to-do list into something that people want to interact with. I’ve seen too many apps take their to-do list of user behaviors and string them together into a “product.” Unfortunately, most people just don’t get very excited about a to-do list.

Instead, the final result may look nothing like a sequence of steps. For example, those actions can be carefully embedded in a game, in self-serve modules, or in a simple mobile app with a single screen that evolves over time. There’s nothing wrong with a sequence of steps, but that’s not the only form that a behavior change application can take. Let’s explore how to move from the list of steps to an engaging product.

Extract the Stories or Specs

To move from the conceptual level to interface designs, we need to chop up the behavioral plan into pieces that the product folks and interface designers can use. Those pieces provide the raw material for the team to then flesh out exactly how the product will be structured and how it will do its job. Every product development methodology and every product team has its own way of doing this ([ref26]). For example, some product people absolutely hate written specs. Others live and die by them.

I’ll take two archetypal product development methodologies as examples:

§ An agile+lean product world, where development is broken up into short periods of time (aka “sprints”). The various functional roles within a team work in parallel, and there’s an assumption of rapid iteration of the product across development cycles.

§ A sequential development world, also derisively called “the waterfall method,” where development occurs in distinct sequential phases over longer periods of time. Each team hands off work products to the next stage of development (design, engineering, testing, etc.) in a predefined order.

These are two common methodologies in the field, and the two that I know the best. Since I can’t possibly cover all of the variations out there, you’ll probably need to tweak these examples to your particular needs and team. For each example, though, I’ll walk through the process of chopping up the behavioral design and developing the interface designs accordingly.

Agile+Lean

In the agile+lean development world (where I live now), user stories convey product ideas in outline form ([ref37]; [ref155]). The development team is free to elaborate upon and innovate within those outlines. They are short, plain-English statements of what the user wants to do. Ideally, they also include why the user wants to do it. For example:

As a user, I want to quickly sync my exercise tracker with my phone, so I can see how I did today.

User stories can come straight from the behavioral plan. Each step in the sequence of actions the user takes building up to the target action gets a user story. For example:

§ If the product should trigger the user to act, like sending out text messages to remind her to run, that’s a user story: “As a user, I want to be reminded when it’s time to run so I don’t procrastinate.”

§ If the product should help users develop a particular self-narrative, like thinking about previous times they’ve gone running, that’s a user story: “As a user, I want to think about the previous times I’ve succeeded at running so this new challenge doesn’t seem so scary.”

§ If a tutorial is required, like how to sync up the tracker, that’s a user story: “As a user, I want to know how to update my logs online so my friends can react.”

Each step in the sequence should already be annotated with user motivations—that becomes the “why” part of each user story. Get the idea?

The user stories indicate what the user needs to do to get a particular job done. They are immensely helpful, in part, because they force the product team to think about the specific actions that the user takes from the user’s perspective, and not from a top-down analysis of what the company thinks the user should be doing. As the team extracts the user stories, they will naturally add, remove, or change some of them as they think about the process in a new light. However, if they are unsure of the spirit of the stories and what the stories are trying to convey, they can refer back to the behavioral plan.

Sequential Development

In a sequential development world,[101] formal specs convey product needs to the development team. Each division of the company may have its own template for those requirements. But in general, they encourage specificity, and provide much less flexibility (and room for confusion) than user stories do in an agile development environment. For example:

The application will allow users to sign up for text messages that alert them about their commitment to go running.

The specs tell the team what the product needs to do to get the job done. They usually are written from the product/company perspective, rather than from a user perspective.

At this point in a sequential process, we just want to create the outline of the specs—the parts that come directly from the behavioral plan. We don’t want to develop fully detailed specs yet. Why? Usually, specifications are much more detailed than user stories; they tell the team not only what’s needed but also how to deliver it. We don’t know the “how” part yet; the behavioral plan only provides the “what.” We’ll flesh out the “how” part shortly.

There Are Many Sources for Specs and Stories

The behavioral plan provides one of the sources for user stories/specs. There will be many others—from business considerations to meet customer needs, to technical needs for the data infrastructure. These various stories/specs need to be prioritized according to business goals, staffing, and engineering constraints. I’ll talk about ways to balance between behavioral and other concerns in the next chapter. For now, and for the sake of simplicity, I’ll focus on just the stories/specs derived from the behavioral plan.

Don’t Specify the Interface Just Yet

As the user stories/spec outlines are extracted from the behavioral plan, there’s a natural tendency to overspecify, and indicate how the product should look and not just what it should do. Resist that temptation for now!

There’s a tension between structured planning and creativity. Thus far, we’ve used a rather planning-heavy process—thinking through what the user should do, what the environment does, and how the user should be prepared. It’s just too tempting to think that the things we want users to do, and the way we want them to behave is how they’ll actually behave.

When, in reality, there’s a lot more required. Users have to want to change their behavior. When there’s a product helping them change, that means they have to want to use the product. The product must not turn them away: no product can be effective at changing behavior if people never use it. The desire to change won’t pull most people through an ugly, uninteresting product. Developing a product that people enjoy using takes more than a top-down behavioral plan—it takes creativity, and it takes the team’s product development and interaction design expertise.

So, how can you integrate planning and creativity? Part of the solution is development philosophy: think of the planning for behavior change we’ve done so far as specifying desired product functionality, and not specifying how the product will accomplish it. Another, more subtle, part of the solution is to avoid a strong reference point by intentionally separating the behavioral plan from the interface design process. The goal is to avoid using the plan as an implicit, unintentional starting point for what it should look like that strongly shapes what the final interface design looks like.

How can you open up the design process and avoid getting a cookie-cutter product? Don’t try to push an interface design into the user stories/spec outlines. Keep them focused on the what, and not the how. Then, let the design team (or members of the product team who are fleshing out the requirements) put aside the behavioral plan for a bit, and work only from the user stories/spec outlines and the previously developed personas. Brainstorm ideas on how the product might look; sketch them out. Prototype them. That process is a special type of magic.

Provide Structure for Magic to Occur

With user stories or an outline for formal specifications in hand, it’s time for the team to specify the exact form that the product features will take, and the content on each screen.

There are no strict rules here, and there are already many books on how to lay out an application’s information architecture and do the user experience and interaction design ([ref38]; [ref157]). Since this isn’t a book of interaction design or user experience design, I’ll leave that to others.

Instead, think of the interface design process as a form of structured magic. Creative thought conjures up interesting, usable content and interaction, within well-defined constraints. The constraints, if not too restrictive, make it possible for the creative process to occur; otherwise the range of possible options would be overwhelming.

Designing for behavior change provides three types of constraints that shape the magic within:

§ Functional constraints

§ A model of how the mind makes decisions

§ Product design patterns: templates for how the product might look

image with no caption

Functional constraints indicate what the product should accomplish. We’ve developed them already—first in the behavioral plan, and then in the user stories or specification outlines created earlier in this chapter. In Chapter 1 Chapter 2 Chapter 3, we developed an understanding of how the mind makes decisions (keep things simple, don’t assume continual conscious attention, leverage the user’s prior associations, etc.), and what that means for behavior change (the Create Action Funnel and three strategies to pass through it). Product patterns, however, need a bit of explanation.

Product Design Patterns for Behavior Change

One question you may be asking yourself as you start to design the structure of the application is this: what type of application is best for behavior change? Is it a game? A serious-minded tutorial? I’m a firm believer that there is no “best” way to structure a product for behavior change. Instead, it’s the psychology that matters, and many different types of products can work. If you don’t know where to start though, there are a variety of templates you can draw from.

Software products, like physical products, usually fall into well-defined categories. People involved in the product development space know what a new social media app is basically going to look like and do, even before the first line of code has been written. We know what an edutainment app for kids is basically going to do. We know what a shoot-’em-up game looks like or what a note-taking app looks like for example.

These categories, or product genres, provide us with an overall set of expectations for the product. Each new product innovates at the margins. Only the rare product actually creates a new genre and gets traction with users; usually it’s in hindsight that we recognize a new genre out of things that have already been built.

In the behavior change space, a variety of templates have already been established that can be used for mobile and online applications. Often a given product employs more than one of these templates in different parts of the application. In that sense, you can think of the templates not just as genres for entire products, but as reusable design patterns for behavior change that you can deploy within your app where needed ([ref75]; [ref3]).[102] Each pattern provides guidelines for promoting behavior change in a particular context, and a template for the look and feel of that part of the application. Dan Lockton’s Design with Intent Toolkit (2010) and Stephen Anderson’s Mental Notes Deck (2013) each provide examples of these behavior change templates.[103]

One set of patterns for behavior change can be applied to high-touch, functionality-rich online or mobile applications, especially where there are major decisions to be made or frequently repeated behaviors. They offer many opportunities to interact with users and reshape the context of the decision and action to best suit the individual user. A different set of patterns can be applied to limited, low-touch interventions—like sending an email or text message. Here are examples of both high-touch and low-touch design patterns.

High-Touch Approaches

Decision-making support

A user is planning for his kid’s education, and the application helps him evaluate the options to save up for it. The app could analyze and present the information, automate part of the process, and make the user aware of other priorities and challenges. HelloWallet is one such product.[104]

Behavior change games

Users are in a classroom setting and are learning about cooperation. Two people play a game together that requires cooperation and communication, learning as they experience it. Way is one such game.[105] Under the banner of behavior-change games (and serious games and games with a purpose, etc.),[106] designers have developed games with explicit social or behavioral “lessons.” Users may play the games as part of a job requirement (as in military simulations or job training games), physical or mental therapy, or in a school context.

Gamification

A user wants to get healthy by eating better and exercising more. As the user does the tasks, he forms teams and competes against others for status in a shared scoring system. Keas is one such product.[107] Whereas behavior change games deploy full-fledged games, gamification employs aspects of game design in nongame contexts—often social rewards and elements of competition around a set of target actions (see Deterding 2011 and Zichermann and Cunningham 2012 for two perspectives on gamification).

Planners

Users want to eat healthier and plant a vegetable garden toward that end. They decide to make a specific plan for what should go into their garden, when to plant it, and how to design the garden for optimal growth and beauty. Mother Earth News has a vegetable garden planner, for example.[108]

Reminders

A user wants to organize his day, and the application reaches out to remind him when and where to go grocery shopping, what time to pick up the kids, etc. To-do list and self-organization apps like Omnifocus and Nozbe are examples.[109]

Social sharing

A user hopes to go running each morning. He shares that goal with friends via their mobile running app, and their support and their ability to hold him accountable keeps him on target. RunKeeper is one such product.[110]

Goal trackers

A user wants to exercise and needs a product in which to set a goal and track progress toward it. Tracking the behavior (either manually or automatically), provides feedback so the individual can adjust his behavior. Fitbit One and Jawbone Up are two such products.[111] Trackers are a mainstay of the Quantified Self Movement.[112]

Tutorials

Going back to the vegetable garden example, let’s say users want to learn how to build a raised bed, and the site provides how-to videos. There are countless such tutorials out there; master gardener Ed Bruske has a sample collection up on MonkeySee.com.[113]

Low-Touch Behavior Change

High-touch interactions aren’t always feasible—you may only have a single shot at interacting with the user, may be limited to a passive medium (like one-way email or print), or know that the opportunity for user attention is fleeting. Here are some patterns that are more appropriate in a low-touch environment (a single email, a few text messages, a single web page or print ad):

An appeal to “think differently”

Users spend a lot of money on electricity and would prefer to spend less. They see a comparison of their spending to their neighbors—making them think differently about how much they should and can spend. Opower does this (successfully)—with a simple physical letter.[114]

Call to action

A user is concerned about a major political issue, like the Keystone XL Pipeline (either for or against it). He receives an email with a link to quickly send a letter or donate to the cause. The user can take the action in a few seconds and move on. There’s nothing more to the email or landing page. Lots of advocacy organizations do this, such as the Sierra Club.[115]

How-to tips

A woman is about to have her first child and is uncertain about what she needs to do to prepare. Through here mobile phone, she receives simple, short tips each week on what to do. Text4Baby does this.[116]

Simple reminders and planning prompts

Employees of a company don’t want to get sick with the flu (or get their families sick). They receive simple mailers reminding them when and where to get vaccinated, and a prompt to plan for when they’ll go themselves. [ref130] did this, with up to an 8% boost in vaccination rates.

Status reports

The user is new to the city and wants to get to know people. He receives regular notices on upcoming events in his areas of interest. Meetup.com[117] does this, as do many organizations that host in-person activities.

I don’t know of any rigorous studies comparing these high-touch and low-touch approaches, but my intuition and personal experience says that you have more freedom to innovate and have greater impact with high-touch approaches.

How to Use Design Patterns

If you need a template to start with, how do you select one? First and foremost, find something that makes sense with the company and its products. Some companies aren’t comfortable with a gamified experience, and won’t build one. That’s perfectly fine. Pick something that fits the culture.

A design pattern can fail to fit the corporate culture even if the underlying psychology could work. For example, love it or hate it, the National Rifle Association is a stalwart advocate for individual ownership of firearms. When they want to encourage their members to act, a serious call to action design pattern fits their image. It would be very strange if they asked members to buy a slick protest-planning armband that encouraged them to set an “individual protest goal” and support them with small daily affirmations (think: an NRA Fitbit). The NRA could certainly use thepsychology of providing goals and support as part of their campaign; but the product template, the expected look and feel, of a geek-chic NRA armband tracker would be rather odd.[118]

Second, identify what’s familiar—familiar to the target population (not necessarily familiar to the “market”). In other words, if the product seeks to help people exercise more, and the user base is familiar and comfortable with pedometers, then a souped-up pedometer will have an easier time integrating into the users’ lives than something completely new and different. A good dose of user research early on can help: keeping the discussion user-centric and focused on the real experiences and expertise of the target audience.

You also don’t need to, and shouldn’t feel obligated to, follow one of these templates at all. If you can, build something entirely new and different. Take something as mundane as employee hygiene at a restaurant (good for the employee and for the customers!). You can build a social game to encourage hygiene that will be really successful, as long as it addresses the core psychology, the Create Action Funnel. You can also build a personal reminder app, again, as long as it addresses the psychology. Or you can do something that no one has ever seen before.[119] It’s the psychology underlying the product that matters, as long as the look and feel of the product doesn’t turn people off.

Draw It Out

While designing the interactions and the look and feel of the product, the product team will develop wireframes (or mockups, or prototypes, as fits their style) of what the user actually sees and interacts with.[120] While developing those wireframes, the team should focus on the core value and usability of product. They’ll need to answer the following questions:

§ Does the user experience actually make sense (especially given the user research)?

§ What’s a clear way to express the content to the user that fits her prior experience?

§ What’s an engaging, interesting way to interact with the user?

The person adding a behavioral perspective to the product team (whether a dedicated behavioral social scientist, an interaction designer, product manager, or whomever) should serve as a resource as these ideas are being put on paper. She can answer questions about behavior and the desired product functionality (similar to a product owner role in a Scrum environment).[121] She can provide behavioral feedback as the UX expert and product manager identify how to best translate the behavioral strategies into attractive, sensible features for the user. Beyond this feedback, though, remember to let the creative process work, to build a good, clean product.

Human behavior and emotions are complex and hard enough to decipher, let alone to change them. I’ve found that it takes all of one’s energy to focus on behavioral change; designing a sensible, beautiful product is just too much to do at the same time. If the behavioral expert is a separate person within the product team, then it’s time to leave it to the nonbehavioral, product experts. If the behavioral expert wears many hats and is also a product manager or user experience expert, take off the behavior change hat. Go look at beautiful products for a while to clear your head. Then design one. There’s time to return to behavioral considerations later.

A Cautionary Tale: My 2012 Exercise Band

In 2012, a new wearable computing band hit the market. The product combined exercise and sleep tracking, with a band you wear at night and one you wear during the day. It sounded great, and I preordered mine—I received it right before Christmas. The product turned out to be an excellent example of what happens when a company makes something that is strongly focused on behavior change, but forgets to build a good product. (I won’t mention their name, since the company is continuing to revise and improve its products, and it isn’t the only company to build an exercise band that had problems in the early stages!)

My wife and I made the product into a twofer gift: I would use the exercise band, and my wife would use the sleep tracker. So, on Christmas day, I installed the app and started trying out the exercise band.

The product did a lot of things right, from a behavioral perspective. It automatically tracked sleep and exercise, which are difficult to do by hand. It had a simple, clean user interface. It helped me set reasonable goals to start with, and then provided constant feedback and nice rewards (little icons on the screen) as progress was made.

The next day I went into the office. After a long day of sitting on my duff, I checked how much exercise I’d had. I saw the screen shown in Figure 9-1.

My daily exercise—while sitting at the computer

Figure 9-1. My daily exercise—while sitting at the computer

Believe it or not, I didn’t walk 38 miles that day, while sitting at my desk. I wish I had. Disappointment number one: clearly a bug in the tracking system.

As I got ready to go home, I put on my jacket. The wristband came off. The small magnetic clasp that held it together wasn’t strong enough. (It would accidentally fall off multiple times over the following days; I’m lucky I didn’t lose it.) Disappointment number two: industrial design problem.

The next day, I forgot it on the counter of my desk. Shortly after lunch, I saw the screen shown in Figure 9-2.

A little judgmental aren’t we?

Figure 9-2. A little judgmental aren’t we?

Not the best experience. If the product had been absolutely correct and I had been inactive, maybe I would have taken the message better. But from its lack of knowledge about me, it inferred that zero data meant a problem in my behavior, rather than in its knowledge. A good interaction designer should have caught this.

Ah well. I returned it quickly. I’m still really excited about the concept and look forward to the next version. But for now, this is a cautionary tale about what happens when you focus exclusively on behavior change, and not enough on building a good product first. Remember that behaviorally effective products must also be interesting and usable.

On a Napkin

Here’s what you’ll need to do

§ Chop up the behavioral plan into the raw material for designing the product. In an agile world, that’s user stories. In a sequential development world, that’s an outline for the full product requirements.

§ Initially, try to avoid specifying the interface design based on the behavioral plan. Focus on what the product needs to do, and not on how the product should do it.

§ Let the creative team do its magic—coming up with a compelling experience for the product.

§ You can use design patterns for behavior change that are familiar to users, such as trackers or reminders.

§ Develop the wireframes (or mockups).

How you’ll know there’s trouble

§ When the product team is too focused on building a product that addresses behavior that it forgets the fundamentals of product design—usability, feasibility, etc.

Deliverables

§ Wireframes of the user experience


[101] When I was a professional software engineer, both in the early stages of HelloWallet and in prior gigs in the Bay Area of California, we used various sequential development methods. They’ve fallen out of favor in some camps but are still widely used in other companies. The suggestions here come from my own experiences, from discussions with other companies at the Action Design D.C. Meetup and from interviews conducted for this book.

[102] The term “design patterns” is used frequently in the UI world for specific elements of interactions, like how to design form fields. See http://ui-patterns.com for one collection. UI design patterns are at a much lower level than the behavior change patterns discussed here—rather than a specifc UI element, behavior change patterns provide an overall approach to an application or feature.

[103] See http://requisitevariety.co.uk/design-with-intent-toolkit/ and http://getmentalnotes.com/. These two approaches focus on particular tactics to change behavior, and are most similar to a list of tactics I present in Chapter 9. Here, I focus on a higher-level UI approach. In addition, [ref140] provides a list of design patterns for behavior change—which he calls “persuasive design patterns” in his book Evil by Design. He takes a different approach, organizing the patterns around the particular “sin” that they appeal to, and focusing on the underlying psychology. The behavior change design patterns presented here provide common approaches to structuring the overall UI and application functionality. In Chapter 9, I present a list of particular psychological tactics for (beneficial, voluntary) behavior change that is somewhat similar to Nodder’s list.

[104] http://www.hellowallet.com/

[105] http://www.makeourway.com/

[106] See [ref172] for an introduction to the field of Serious Games. See http://gameswithpurpose.org/ for an annotated list of such games.

[107] http://keas.com/

[108] http://www.motherearthnews.com/garden-planner/vegetable-garden-planner.aspx#axzz2W0kvVZrk

[109] http://www.omnigroup.com/products/omnifocus/; http://www.nozbe.com/

[110] http://runkeeper.com/

[111] http://www.fitbit.com/one; https://jawbone.com/up

[112] See http://quantifiedself.com/.

[113] http://www.monkeysee.com/play/10009-how-to-grow-a-vegetable-g arden

[114] http://opower.com/what-is-opower/reports

[115] See https://content.sierraclub.org/sierra-club-programs. As of this writing, one such active campaign could be found at https://secure.sierraclub.org/site/Advocacy?cmd=display&page=UserAction&id =10119.

[116] https://text4baby.org/

[117] http://www.meetup.com

[118] Naturally, one could design and build an NRA Fitbit for Second Amendment-related protests. It could be done (and I’d love to see one, by the way). The point is that it wouldn’t fit the existing expectations and product experience of most NRA members. It would be foreign, and that foreignness would make it more difficult to have an impact on user behavior (and make it more difficult to “sell” overall).

[119] It’s difficult to think up many other ways to structure a hygiene app, isn’t it? That’s part of the power of design patterns—they are reference points for design that lock us in to thinking about the product in a particular way. That’s another reason why it’s important that the design team has creative freedom to think about the look and feel of the app, before starting from the ‘obvious solution’ or using the behavioral plan as a reference point.

[120] This can occur when the team fleshes out specification outlines into full product requirements, or when the design team digs into the user stories, depending on the development methodology employed.

[121] Scrum is one form of agile development. See http://www.mountaingoatsoftware.com/scrum/product-owner for a description of the role.