Books for software engineers and managers

Designing for Behavior  Change

Applying Psychology and Behavioral  Economics

by Stephen Wendel

Categories:
Tech Lead,
Star Engineer,
Product Manager,
Designer

Four dimensions of  ability

When evaluating a user’s ability to perform a task, we need to satisfy four components:

  1. Action plan – knowing the steps required to take action
  2. Resources – having the resources available to act (e.g. money, time, equipment, etc.)
  3. Skills – having the background knowledge and skills (e.g. knowing how to download an app in the App Store)
  4. Belief in success – reasonable confidence that you’ll be successful

In other words, adding functionality is not enough to satisfy customer needs. We need to understand the user’s context at a deeper level to ensure that these four dimensions are satisfied, providing them the ability to act.

Engineering a solution is often more effective than changing  behavior

Changing user behavior is very difficult. Humans embrace habits and routines, resisting change to those structures both consciously and unconsciously.

Try to engineer a solution before trying to change behavior.

Engineering a solution might look like reasonable defaults, templates, or power actions that perform complex steps on behalf of the user.

Avoid state-of-mind goals

State-of-mind goals sound like “Increase customer confidence by 15% before Q2.” That sounds great, right? Specific. Measurable. Attainable. Relevant. Time-based. SMART.

But is customer confidence really what the business wants? No. They want sales, or reduced churn, or some other tangible change in behavior. Action.

Overall, I’m a little torn on this because one of the most popular metrics in our industry is Net Promoter Score, fundamentally a state-of-mind metric – How likely are you to recommend this product/service to a friend or colleague? However, NPS is easy enough to convert into an action-oriented metric by simply tracking actual referrals that I see a path.

Investigate behavior change outside your  app

Tracking user engagement and behavior within apps is relatively easy. We either use our database or an event logging system like Segment.

However, you should also look for behavior changes that occur outside your app.

For instance, if you build the world’s best strength and conditioning app, then you’re probably also interested to understand the effects of your app on a user’s broader approach to health – changes in sleep, diet, etc.

Use behavior personas, not demographic  personas

Traditional demographic personas sound like “Married moms age 30-45…”

Behavioral personas categorize people based on their actions. For instance, Frugals may always maintain an emergency savings account or pre-game at home before going out.

Where demographic personas trap us into thinking about the person, behavioral personas encourage us to think about how the person behaves in a given context.

Designing for Behavior Change

How strongly do I recommend Designing for Behavior  Change?
7 / 10

Designing for Behavior Change is a good read for software engineers looking to improve business value. This book provides a solid framework for understanding the designs, features, and solutions you’re asked to build. With this book engineers will feel better prepared to ask meaningful questions and deliver what’s intended, not just the pixels and specs as-presented.