Introduction to Behavior-Based Design

In general, I think that a product is only as good as its ability to co-opt behavior. Techcrunch is littered with the stale remains of gorgeous products that were executed to perfection, but failed to get any true user adoption.They failed to fit into, or change, the behavior patterns of their users.

This point is obvious. The question now becomes: Why did they fail to fit into, or change, the behavior patterns of their users?

In general, when a behavior doesn’t occur, it’s because at least one of the three following things is missing (or insufficient).

1. Motivation
2. Ability
3. Trigger

In order for a behavior to occur, a person must first be motivated and able to perform the behavior. Then, if they have an ample level of motivation and ability to perform the given behavior, they will follow through when cued/triggered.

This simple model is called the Fogg Behavior Model. It’s named after BJ Fogg, the head of the Stanford Persuasive Technology Lab.

We can break each of the above elements into sub-elements to gain greater clarity. But, for now, let’s just stick at this macro-level using an example behavior: running.

Let’s say that you wanted to go running this afternoon, but didn’t. Why is this?

It could be that you totally forgot to go running because you were caught up in some other activity. Perhaps you were deeply entranced by the new season of House of Cards. In that case, the behavior wasn’t performed due to the lack of a cue/trigger.

Or, you might not have gone running because you didn’t get much sleep the night before and were absolutely exhausted when you got home. In this case, the behavior wasn’t performed due to a lack of ability.

Or, you might not have gone running because, to be honest, you feel pretty good and aren’t overweight — you have no burning desire/purpose to go running. In this case, the behavior wasn’t performed due to a lack of motivation.

So, when we’re looking at a behavior, such as searching with Google, we have to ask ourselves where the problem lies. In most situations, all three elements are guilty. However, there is usually a primary perpetrator — a primary behavioral bottleneck that must be identified and solved.

Triggers

From my experience, the primary behavioral bottleneck with most apps is the trigger.

As I’ve written with Nir Eyal, there are two primary types triggers:

1. Internal
2. External

In general, an internal trigger is created when a user consistently has a great experience with an application. After consistently getting rewarded by an application, an association is made between the application and the need that prompted the opening of the application. For Instagram, the internal trigger could be the thought “Wow! That’s beautiful! I should take a picture”. For Yelp, it could be, “I’m hungry. Where should I eat?”. Since internal triggers take the form of internal drives and thoughts, they’re pretty much impossible to measure or rely on. That’s why external triggers are a product designer’s best friend.

Here are some examples of external triggers:

• Emails
• Push notifications
• Text messages
• Signs/Notes

If a user is presented with a call to action when they’re able and somewhat motivated to perform a behavior, it’s likely that they will. If they then have a good experience inside of the app, they will be reinforced to use it again in the future. If the following occurs enough times, a habit will be formed:

Trigger (usually external) → Open app → Good experience

Companies like Facebook have heavily relied on external triggers in order to build habits into their users. The goal is to get your users thinking about your app as often as possible throughout the day. This does a couple different things:

1. It increases the probability that they’ll open and use the app.
2. It gives us the chance that users will make an association between the application and daily use cases.

For example, imagine if Yahoo started sending users 5-10 notifications a day along these lines:

• Need something? Just type it in here.
• Hungry? We have some great restaurant recommendations for you.
• Want to know if you need a jacket tomorrow? We have some great weather apps for you.
• etc.

I’m not necessarily saying that they should utilize this strategy, but it is likely that this approach would increase usage. Because of current smartphone behavioral dynamics, people are overwhelmed by the number of applications they have. Your app is going to be one of fifty or one-hundred… and it’s likely that yours is not the only new app that your users have downloaded this week. If you’re not front and center in their field of view constantly (as a widget, for example), it’s likely that you’ll be forgotten. This is why external triggers are so important — they remind your users that you exist and can solve problems for them. While any triggers you create may seem annoying to you… that’s not necessarily how your users will feel.You’re constantly thinking about your application, and so when you get a trigger, you’re not surprised or delighted at all. This is why it’s so hard to dog-food notifications. Looking at numbers in the wild is the best way to evaluate their appropriateness and effectiveness.

There’s always a threshold above which the number of notifications gets annoying (and the uninstall rate increases dramatically). However, up until that point, the more triggers the better (from a behavioral perspective).

Ability

If the trigger is not the primary bottleneck, the next best element to tackle is ability. If an app is hard to use, people won’t use it. They will move on the easier, simpler alternative.

This is all about usability. The best way, in my experience, to optimize this element is by doing a large number of user tests (non-task-based in the beginning).

BJ Fogg breaks down ability into six sub-components. I don’t necessarily think that they’re particularly useful for our work here, but I’ll go through them quickly:

1. Time
2. Money
3. Cognitively demanding (mental effort)
4. Physically demanding (physical effort)
5. Social deviance
6. Non-routine

He frames ability in terms of its road-blocks. If a behavior demands a lot of time, then users will likely have a low ability to perform it. If a behavior demands a lot of money, or is cognitively quite challenging to use, same thing… and so on.

I see time-to-task-completion as a great proxy for the general usability of that feature. If a task takes a very short amount of time, it’s likely not cognitively demanding, physically demanding, or non-routine. Therefore, the time variable is probably the best way to get a sense of whether or not an app and its features are understandable and usable.

Motivation

Motivation operates on two different levels:

1. App wide
2. Screen level

The app-wide motivation refers to the problem/use-case the app deals with. For example, let’s say that you’ve been brought into a company to help them optimize the usage/retention of an application that helps people rate the quality of the coffee cups at different local cafes. You could mess around with the triggers and make it stupidly simple to use… but, at the end of the day, it’s an app that solves a problem that nobody has. Therefore, the level of motivation for this behavior is so low that no amount of gamification or tweaking can suddenly unleash the engagement tidal wave.

With every application we look at, we need to be critical and ask: Do people really care about this? Is this a problem that people actually have?

Throughout the entire startup world, this is probably the least asked question. And, when it’s usually asked, it’s in a group-think situation with a foregone conclusion.

So, if an application solves a true problem that people have (app wide motivation)… how else can we amplify motivation?

There are a number of ways, but let’s start with incentive systems. Dan Ariely and I have broken the different types of incentives into four main categories:

1. Monetary
2. Tangible item (thing)
3. Point-based
4. Social

Monetary incentives are straightforward. We won’t go into them here.

Tangible items are also fairly straightforward… and they don’t really apply to the specific problems we’re trying to solve here, so we’ll move on.

Points are non-monetary currency. Here are some examples:

• Points in a video game
• Frequent flier miles
• Punches on a punch-card (loyalty card — below)

Points are the keystone tactic of the gamification crowd. They definitely work in the short term, but there are huge problems with points. The best example of the short term power (but long term folly) of points is Turntable.fm.