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

Part IV. Designing the Interface and Implementing It

Chapter 11. Turning the Designs into Code

Put the Interface Design in Front of Users

When the interface designs are ready, the product team should test them in the field—before committing engineering resources to a full implementation. Ideally, that should be done with low-cost clickable prototypes—to increase the realism of the experience for users. But the team can gather rough and dirty feedback from graphic designs, aka comps, too. This process should iterate as many times as needed until the designs are solid and successful in the field.

Besides all of the excellent reasons one normally hears for user testing—to look for usability problems, to get gut reactions on aesthetics, to identify missing functionality—there’s an additional reason in the case of designing for behavior change: you can never be certain the package will “work,” behaviorally, until it does.

As I discussed in Chapter 1, behavioral social science, and with it, the process of designing for behavior change, is still developing rapidly. There aren’t any simple formulas for behavior change. The previous chapters in this book have provided guidelines on leveraging the excellent research that’s available, but field testing and refinement are still absolutely essential to the process.

As you gather user feedback, surprises will occur. The application may be quite engaging for some users, but completely uninteresting to others (or worse, it could be patently offensive). There are two issues in particular to consider as you gather this feedback:

§ Keep in mind what the team defines as “success.”

§ Look for behavioral feedback.

Keep in Mind What the Team Defines as “Success”

Is success reaching 100% of users? Or, could success mean helping 10% of people immensely, and learning how to help the rest over time? If some of the users strongly dislike the product (but others like it), that’s not necessarily a problem. We can easily focus on the negative cases—where the product doesn’t work—and lose sight of the larger signal we get from our initial testing efforts that the product does work in many other cases. Think about whether the behavioral impact needs to be evenly distributed across the users, or whether you should expect diverging opinions and results among test users. Chapter 12 and Chapter 13 discuss the detailed metrics you’ll need within the product itself to gauge success, but it’s important to keep in mind your definition of success even when you’re in this initial phase of gathering feedback from users on prototypes.

Look for Behavioral Feedback

People’s behavior using the prototypes is much more reliable than their conscious, verbal feedback. Recall the discussion of choice overload (Chapter 10). People often say they want many options in their products but actually find those options paralyzing when confronted with them. If you present a screen that lets them customize every aspect of their exercise plan, they may express excitement and interest but be completely befuddled when trying to use it.

Other cognitive quirks also muddy the conscious verbal feedback that participants give. For example, we have a strong tendency to generate meaningful narratives for our past behavior even when luck and circumstance directed our actions. Instead of listening to what people say, look for what they do—do they spend a lot of time trying to make a decision on a particular page, do they actually complete a page sequence, or do they give up early?

Finalize the Designs

Based on the results of the user testing, you and the rest of the product team will have numerous ideas on how to further improve the product. If the schedule and product process allow it, it’s ideal to repeat the design and review process (developing wireframes and specs, reviewing them from behavioral and engineering perspectives, and developing or updating the prototype) as many times as is feasible until the design looks solid. It’s better to find the problems early—in the face of user feedback—than later.

In addition, throughout the user testing process, look for opportunities to cut. I’ve argued previously for targeting the Minimum Viable Action that the user needs to take to meet their behavioral goal. If the user testing process shows that certain interactions are confusing or difficult for users, the first response should be to remove that interaction altogether (if the product still meets its behavioral goals), rather than investing time into “fixing it.” Simpler, shorter interactions will almost always be completed more often than longer, complex ones.

Build the Product

Plan and Prioritize Engineering Resources

In traditional product development processes, there is a point at which the engineering team reviews the proposed application design and comments on resource requirements for each component.^[130^] Engineers provide feedback to the product team on what is feasible to build in the desired time frame and help inform the prioritization of product features. The same process should occur when developing products to change behavior, but with one an additional stakeholder—the behavioral expert (the interaction designer, product manager, or other person tasked with designing for behavior change).

The behavioral expert’s role is to evaluate the likely behavioral impact of each major change; if a proposed feature is not feasible from an engineering perspective, would the remaining functionality have the desired effect? The product manager should weigh the input of the engineering team, behavioral expert, the UX experts (on the usability of the remaining application functionality), and potentially the business/sales team (to inform the salability of the resulting application). For any element that the product manager decides to cut or substantially alter, then the behavioral expert should provide suggestions on how to still meet the behavioral aims of the application (i.e., how to ensure that the application is still effective).

Evaluate Engineering Trade-Offs

Next, the vetted, user-tested designs are taken up by the engineering team to build. Final graphic designs are made, and the coding of the software starts. As the product is engineered, naturally adjustments many be needed to the designs. The product team should work with engineering to track the implementation of the designs and adjust the designs as needed based on engineering roadblocks.

There are two things to keep an eye out for during the engineering process:

§ Ensure that the Minimum Viable Action is still supported. Extraneous pieces can and should be cut, but you can’t deliver psychology in pieces. Either the clear mechanism that helps users take action is there, or it isn’t.

§ Watch out for pauses and inefficiencies in the user experience that break the flow of user actions. Users need to feel that they will be successful at each step, in a reasonable amount of time, and that each step meaningfully builds toward the goal, or else they will give up.

Test It

Software bugs take on a special meaning in a behavior change world: they cut into the credibility, perceived reliability, and sense of immersion that is necessary for many psychological mechanisms to work. The last thing you want is for your users to be consciously thinking about how buggy the product is, or build up a strong association between your product and low quality.

Paraphrasing Dave Ramsey’s guidance about where to seek financial advice (2009): you wouldn’t trust a finance teacher who was broke, and you wouldn’t trust an application to help change your life if the app can’t even function properly.

Go Lean If Possible

Thus far, I’ve intentionally avoided making strong recommendations about product methodology. As I’ve stressed earlier, designing for behavior change can work with any methodology. Thinking about the psychology of your users can happen in a sequential development model just as it can in an agile development approach. But if you’re not sure what to do, the lean startup approach provides a firm foundation.

The lean startup approach ([ref152]) teaches that each iteration of the product should generate validated learning about what the market actually wants. It recommends building the Minimum Viable Product that can test whether product concept will work and getting it into people’s hands as quickly as possible. From a practical perspective, that means taking the most basic, testable part of the designs and building that before anything else (and, of course, not spending more time on the initial designs than is necessary).

The approach is very much in line with the philosophy of designing for behavior change. While you can (and should) design your product thoughtfully, you never really know if the psychology will work until it does. So, though it’s not required when designing for behavior change, it certainly helps to take a lean startup approach when designing and building the product.

On a Napkin

Here’s what you’ll need to do

§ Get the designs in front of users—preferably in the form of a clickable prototype, but graphic designs can work, too.

§ Watch for user behavior as people interact with the prototype, and pay less attention to what they say.

§ As the product is built, evaluate engineering trade-offs for their behavioral implications.

How you’ll know there’s trouble

§ The final product is feasible to build from an engineering perspective, but is disconnected from the behavioral plan and doesn’t provide a compelling story for behavior change.

Deliverables

§ The product!