How to use behavioural science to drive user behaviour

Behavioural models (COM-B, Fogg's Behavioural Model, and other) can help you build better products. Here's how.

Product managers and government agencies have a similar and underappreciated need to drive the behaviour. Health-related decisions of millions of people lead to savings or spending of billions of dollars per year on healthcare. Not surprisingly, governments heavily rely on and fund research in the behavioural sciences to better understand the drivers of human behaviour to shape the behaviour. 

I’d like to introduce two models, COM-B and Fogg’s Behavioural Model (also known as B-MAT), and discuss their application in product management context. Read on if you’d like to structure your user research to identify leverage points to drive the behaviour or build product experiences that help drive expected behaviour rather than create unintended friction. 

COM-B model

COM-B was created as a unifying framework for different behavioural models that preceded it. The authors were unsatisfied with existing models because each had gaps in possible behavioural influences, and none were comprehensive or coherent enough to understand and build a strategy to address them. 

According to the framework, the three drivers of behaviour are capability, opportunity, and motivation. Around these three core drivers of behaviour is a whole ‘behavioural change wheel’, which I won’t cover here. 

Capability

A person can exhibit a behaviour when they have the necessary capacity to do so. The model includes two types of capability: physical and psychological. 

Knowledge, skills, thought processes, and mindset together with friction (or lack of friction) to perform the behaviour constitute capability. If it is not clear to a user how to do an necessary action, they may not be able to perform it even if they have the time and motivation. 

Motivation

The model differentiates between two types of motivation: reflective and automatic. 

Reflective motivation describes the analytical part of motivation, for example, people setting specific goals, evaluating different options and making plans to carry out the behaviour. 

Automatic motivation springs from emotions, values and other internal processes that make people fired up or closed to a particular behaviour. 

When working on a product, optimising an experience or building a new one, it’s critical to consider what type of motivation drives the behaviour you want to see from your users. Appealing to a wrong type of motivation is going to create confusion, and won’t lead to results you expect.  

Opportunity

In COM-B, opportunity is defined through external factors, such as cues that trigger the behaviour or affordances that make that behaviour possible. While the model identifies physical and social as two types of opportunities, there are even more types. 

Opportunity seems to be somewhat of a ‘catch-all’ category in the model because it includes prompts (but only external), external resources (for example, time or money), and social layer (for example, norms). 

The critical difference between capabilities and opportunities is that capabilities are internal, while opportunities are external. 

The relationship between three factors

COM-B stipulates that capability and opportunity function as switchers. It’s not enough for motivation to be present. Both capability and opportunity have to be at a certain level for the behaviour to occur. It can be extended to the notion of capability and opportunity as drivers of motivation and necessary prerequisites of the behaviour. 

The model also finds that performing the behaviour can result in a positive feedback loop, where the behaviour itself increases the capability (for example), in turn increasing motivation. When doing sports, the better you become, the better you are as a player. The more skilled you get at it, the more motivated you’ll be to continue doing that sport. 

In product management, the closest example of that positive feedback loop is found in games. As you progress through levels and invest more and more of your time, you become more skilled, making you more likely to play again. 

Fogg’s Behavioural model

Fogg’s Behavioural model is possibly the most well-known in the tech world. It is devilishly simple and easy to apply. It is also easier to interpret than COM-B within a product management context, as it is a model initially developed for persuasive design. 

Fogg’s Behavioural Model, also known as B=MAT or B=MAP, is not as grounded in social sciences as COM-B. However, FBM became a generally accepted model in science (where it is being applied to interpret behavioural interventions) and product management. 

According to FBM, behaviour occurs when a person has sufficient Motivation, has the Ability to perform it, and there is a cue (Trigger/Prompt). Compared to COM-B, this model places a distinct importance on internal or external Triggers, without which the behaviour will not happen.  

The image illustrates a situation where a user has a lot of motivation but lacks the ability to perform the behaviour. A trigger won’t make that user exhibit the behaviour we are driving for that reason because it falls below the curve. 

As you can see in the picture above, it’s critical to drive the user’s motivation and ability to the point where a trigger would work. The model, however, doesn’t outline how to measure motivation and ability precisely. 

Motivation

BJ Fogg initially outlined three key motivational factors:

1. Pleasure/Pain

2. Hope/Fear

3. Social Acceptance/Rejection

A well-known loss aversion bias stipulates that people are more sensitive to losses than gains. Pain avoidance is a better motivator than potential pleasure. This is reflected in the colloquial wisdom that tech products should solve the most significant pain and not be a ‘vitamin’ that just improves life. 

Hope and Fear are similar because each means anticipation of something: positive outcome in the former and negative outcome in the latter. 

The third type of motivation outlined by BJ Fogg is related to social norms, as there is a tendency for people to seek approval from society and avoid rejection. 

While BJ Fogg proposed these three in the original paper, they only provide a lens to look at motivation with, and not a prescriptive framework that doesn’t allow for other categories. 

The natural frequency of the use case in your solution plays a significant role in defining motivation and acts as a prerequisite for motivation to occur. For example, if a user needs lunch (as people typically do mid-day), they will be motivated to get food by whatever means. Ordering through a delivery service will be one of the ways to do that. However, if a user is not hungry and doesn’t plan to eat soon, there is no natural use case and no need to get food, including food delivery.  

Due to that fact, many products start covering more and more use cases with time to drive the natural frequency of the use case higher. To extend the example, the delivery app may start to offer more services (flower delivery) or suggest new use cases (pre-order food for a special occasion). 

Ability

BJ Fogg uses ability interchangeably with ‘simplicity’. Ability as a category includes internal (knowledge, skills, resources) and external (product friction) factors.

The initial paper suggests six factors as core to consider: time, money, physical effort, brain cycles (can be understood as cognitive friction), social deviance (whether an action requires going against the norm), and non-routineness (how much an action doesn’t fall into existing patterns of behaviour).

Many potential factors influence this category. The lowest (or scarcest) factor influencing ability determines the overall ability level. For example, suppose a user wants to book an appointment with a healthcare provider in a telehealth product but has no money or way to get a loan. In that case, the ability will be at its lowest, even though other factors (product friction, behaviour being routine, presence of available time slots) will be scored high. 

Ability (like other components) is highly dependent on the audience for whom you are building the experience. There are specific limitations/traits of your audience that make them ‘less able’ to perform the use case. The point is best illustrated with an example. Imagine that you are building a product for an audience with an average age of 80 years. If you decide to use a flat UI design with lots of drag-and-drop elements and no buttons (let’s say that’s precisely how similar solutions for younger audiences are designed), you will negatively influence ability. 

Trigger

Triggers initiate a behaviour if enough motivation and ability are present. When there is neither, the trigger will fail to activate the behaviour. The simplest example of a trigger is a push notification. For example, a delivery app telling you that you haven’t ordered for a long time or a language learning service telling you to review the latest lessons. 

BJ Fogg identifies three key characteristics of a successful trigger: 

1. It’s noticeable

2. It’s associated with the behaviour we want to drive

3. It happens when both motivation and ability are high enough for behaviour to occur

Triggers don’t have to be external. It’s easy to visualise how a push message leads to a new delivery order, but many users decide to order food without any prompts from the service. A growing feeling of hunger during a specific period also serves as a trigger. We can’t manufacture internal triggers (such as a feeling of hunger), but we can make the product associate with that internal trigger by repeated exposure (usage). 

There was a curve in the image above where we had two axes for motivation and ability. When the user’s motivation and ability are below the curve, any trigger will fail to initiate the behaviour. No solid rule exists on how much motivation and/or ability should be present or how the curve looks in any particular case. The concept is primarily qualitative. 

Triggers might have unintended consequences, such as when an ill-timed trigger distracts or frustrates the user. That happens when motivation and/or ability are low, and the trigger, which would’ve been welcome at another time, brings negative feelings because the user can’t perform the action. 

BJ Fogg identifies three types of triggers:

Spark – a trigger that simultaneously increases motivation. For example, a push notification about a saved item going out of stock soon. 

Facilitator – a trigger that simultaneously increases ability. For example, a prompt to add friends via uploading a contact book. 

Signal – just a well-timed trigger. For example, a push notification about new restaurants on the platform

Bringing all elements together

There is an apparent trade-off between motivation and ability. If you weren’t looking to invest in real estate, a random offer to sell you a property won’t motivate you to get a mortgage and buy the property. If the same property was offered for a dollar, your ability would drastically improve, making the behaviour more likely to occur. 

The goal is to move as many users into the area above the curve as possible by increasing motivation and ability. 

If you work on a bigger product with multiple segments of the audience using it, you’ll quickly realise that both factors and levels of motivation and ability of these segments are different. We’ll look at how to apply these frameworks to uncover hidden insights. 

Applying behavioural models for user research

When behavioural models can help

We can interpret behaviour through actions that users do in our products. With that view, you can analyse any action you drive users towards and want them to complete with the abovementioned behavioural models. 

Discovering drivers of choice

In most product categories, users have a broad selection of products. Some solutions in the category have a better appeal for users. Behavioural models can help you navigate why people have selected a specific product in your category. 

In this type of research, you’ll focus on the past decisions made by your audience. The goal is to deconstruct the key factors behind their decision through COM-B or Fogg’s Behavioural Model. The models most apply to B2C apps and B2B products built for SMBs. With enterprise products, you are getting a fair mix of stakeholders that influence the decision, so the retrospective analysis may not prove fruitful due to too many blind spots in your research. 

Onboarding & activation

Onboarding is a critical phase in the customer journey, where users learn about the core product’s value for the first. Nudging new users to experience the product’s value through usage within their early experiences is one of the goals of the PLG approach. 

However, many users sign up for the product and never reach the activation moment. Even though some users do not come with an expectation to try the product as they are evaluating multiple different solutions side-to-side, there is a significant opportunity to help your users make an informed decision by actually trying their primary use case. 

Behavioural models will help you understand what needs to happen for your new users to do their primary use case. 

Adoption blockers

Adoption describes whether a user has tried a certain use case or functionality in the product and continued the usage afterwards. When users adopt more use cases in the product, they extract more value from the solution and get more locked in. 

Building new use cases is a typical strategic move that helps improve overall usage retention. And even though new functionality sometimes may not fill the audience's needs, behavioural models can help you identify the blockers to try and continue using the solution you’ve built if it has product-market fit. 

Driving more engagement

Engagement describes how often a particular use case is performed by a user in your product. More usage typically means better retention or sometimes even direct revenue generation, as in products with an ads-based monetisation model. 

The most likely limitation of any use case is the natural frequency of it. Unless there are more meetings to have, Zoom’s users will not suddenly start scheduling more of them. 

Still, there are ways to drive more engagement, even if the natural frequency of the use case is at its limit for a specific user. For example, if a user orders food delivery only for lunch, there is an opportunity to drive users to order food delivery for dinner. Behavioural models can help you navigate what’s required to do so. 

Preventing behaviour

Understanding the drivers of a particular behaviour also means we get control over how to prevent that behaviour from occurring. This category is most challenging to impact meaningfully, as most behaviours we want to prevent are the ones we have the least control over. 

Malicious behaviour and trolling in social apps are potential targets in this category, but these may be hard to research. The agents of malicious behaviour may not be interested in doing research. 

Example: feature adoption in a health&fitness app

Let’s consider a fictional example of a product that solves multiple health and fitness use cases, such as counting calories, logging workouts, showing training programs and other. The team recently introduced the ‘logging workouts’ feature that allows users to record exercises, number of sets, repetitions and weights. There was a great fit for that use case with the existing audience as the team identified that most users do strength/hypertrophy training. 

Brief summary

The primary research goal is to identify key barriers to adopting workout logger functionality/use case. 

The audience the team selects for research is: 

1. Active users

2. Tried logging their strength/hypertrophy workouts at least once in the last 2 months

3. Haven’t logged any workouts since

4. Newbie/Intermediate lifters (based on the numbers they logged previously) 

Later, the team should talk to users who use the functionality consistently to learn what makes it appealing. There is always potential to make the app even better in what it does well to drive further growth. 

Brief guide

We’ll use Fogg’s Behavioural Model, but the approach when using COM-B will be similar. In most interviews, you first gather context about the user and problem space, then gradually narrow it down to problems and solutions you need to research deeper. 

Context

In our example, we are working on a health and fitness app that has functionality for workout logging, so we’ll start by gathering context: user’s fitness goals, workouts and their structure, experience with recording workouts, and overall fitness approach. 

The context is critical to put every insight into the proper perspective. There’s always going to be an interplay between the broader context and the deep problem you are working on, so if you miss out on context, you will be at risk of making wrong conclusions from otherwise relevant information. 

Motivation

The next stage is learning about motivation. The specific questions here will depend on the exact problem you are discovering (shocker!). Still, you can utilise particular motivation theories to build a more granular question structure to cover all the different aspects of motivation. In our case, a few question examples for the motivation stage are:

1. What made you interested in the logging functionality in [our app]?

2. How do you remember sets, weights and repetitions now? 

   1. [If there is a way other than memory], what made you record your workouts this way? 

3. How do you use data from logged workouts? 

   1. What was the last time you looked at, analysed or otherwise used the data you logged?

4. How does logging weights help you achieve your fitness goals? 

5. What happens when you forget to record/remember your numbers? 

6. Tell me about the last time you decided not to log data in your workout.

Examples are not comprehensive.

Ability

Similar to motivation, ability can only be understood within the user's specific context. The insights you will get there are not universal but applicable to specific scenarios, mindsets and contexts. 

Here are a few question examples for our ‘workout logging’ case:

1. Please walk me through your experience using [our app] to log your workout. 

   1. [If used in the gym], how hard or easy was recording weights/repetitions during the workout?

   2. [If used after the session], how hard or easy was remembering and recording weights/repetitions after the workout? And when exactly did you log the data?

   3. What was the [hardest/most annoying] part about logging?

2. What’s the most challenging part about recording weights and repetitions? 

3. [if uses any approaches (but our app) to record data] 

   1. What makes this [approach/app] your preferred way of tracking? 

   2. What do you like the most about [approach/app]?

   3. What do you dislike the most about [approach/app]?

   4. What other approaches/apps have you tried to record the data, and what made the current solution better?

Trigger

When learning about triggers, it’s essential to consider both existing triggers (including internal and external) and what happens when there is a lack of a trigger. Habits and environment can often be a trigger enough. In our example, it could be a habit for a particular user to open a tracking app right after they do an exercise. For natural triggers, it’s essential to consider when they arise. An imaginary example, but it might be true for some user that their trigger to order food delivery is a ride home after a longer-than-expected workday. To dig deep enough to uncover these, you must go through multiple situations of them performing the use case in the past and different contexts. 

In our workout tracking example, example questions are: 

1. The last time you used our app to log a workout, what made you open [our app] to do so?

2. [If logs workouts] What prompts you to record your set/weight/repetitions now? 

3. [If logs workouts] What are the main reasons you forget to log your workout?

You don’t have to build your research guide around these topics, though; you can simply analyse any new or existing research by fishing for insights related to these categories. Given that most teams accumulate quite a sizeable research base, it might be easier and faster to do a secondary analysis of the existing research by breaking down all information into the same buckets. 

Analysis

The analysis of gathered insights mainly comes to identifying the patterns in motivation and ability categories. You will list all relevant insights, focusing on specific blockers and barriers you identified. The ideal situation is when you see recurring problems, issues, and blockers repeated multiple times across different subjects. It signals a pattern, and that means there is bigger likelihood that a barrier is real and worth more attention. 

Analysing trigger-related insights focuses on finding specific issues or blockers and where and how you can embed yourself in a user’s life. Triggers must come at the right moment through the right channel. In my experience, triggers are mostly about experimentation (channels, time for communications, for example), building specific mechanics (e.g., set reminders), and embedding/integrating with 3rd parties. Still, the best ideation comes from understanding context and existing triggers. 

Context-based segmentation

While doing analysis, you may realise that users have similarities or differences based on their context. If a pattern is related to a specific context, you need to separate insights and link them to particular contexts/segments you see. There might be general insights, but segmentation will allow you to prioritise barriers further, as you may value one segment more than the other. 

For example, in our case we might see completely different blockers in each factor between newbie and intermediate lifters. By further understanding the differences in these blockers, we may realise that it is much easier for us to nudge intermediate lifters to use our app to log workouts than newbies. We would build our product adoption strategy accordingly. 

Back to our workout logging case

In our example, sample insights about our app and its logging-related functionality might come to:

Motivation:

+ Intermediate lifters use data to build their programs based on actual weights they lifted; Newbie lifters wanted to see how they progress with weights for fun

– Makes exercising less fun by the need to track each set rigorously

Ability:

– Sometimes, users have low-energy days and don’t want to spend any time on doing the tracking during these days

– Recording weights and repetitions for each set takes too much work 

– Pre-built workouts can change based on equipment availability, but the current design makes it hard to switch/change exercises

– Simply forget to open the app at the start of the session, and don’t see the point in starting to track it mid-session

Triggers: 

+ Users with a smartwatch remember to log weights right after they start tracking their gym session with the watch

The insights are entirely made up, of course, in this example. The team could adapt their strategy if these issues were validated across multiple subjects. For example, to make it less tedious, the team can introduce a feature that allows to track only the top set (the heaviest set) for each exercise. That should address both motivation, ability and trigger.

Applying behavioural models to build product experiences

COM-B and Fogg’s Behavioural Model can help you design and build better solutions. Here’s how.

Designing for behaviour

One of the first things you do when building a new product or experience is simply outlining the audience segment that will benefit from the feature and the primary use case to be delivered. 

Stated another way, your audience performs the primary use case of your new feature to extract the particular value they care about. 

When designing an experience, you should first build a list of: 

1. Factors that increase or decrease motivation for the use case

2. Factors that influence the ability to perform the use case

You create limitations by building the list of these factors before you commit to designing or outlining how the feature/experience should work. These limitations are the guard rails that protect you from making wrong design decisions. You can use these factors as a checklist that needs to be taken care of before you proceed to development. Great solution design, like creativity, shines when there are enough limitations to design around. 

Design crits: analysing the behavioural drivers

Most mature product companies practice design critique sessions where product designers (with other roles being present) review new designs to understand, challenge and ultimately improve the experience by providing an impartial opinion and bringing additional insights.

One way to improve these design critiques is to add a short session where the team is focused on behavioural components (either COM-B or B=MAT) and tries to identify both positive and negative factors in a design. It will improve the usefulness of design critiques and create a habit of thinking through behavioural components before designing. Repeated exposure to stimuli (such as being prodded on behavioural components) results in new habits. 

The example in the image is generic, but it signals an approach where you start thinking about components of behaviour in the design stage. It’s easy to get wrapped up in all of the specifics of what you design, but sometimes you need to step back and consider what is the key use case here, what’s the motivation behind it, and how do we make it fit the knowledge and skills of our specific audience? 

Building/prioritising experiments 

Growth teams can benefit from behavioural models no less (maybe even more?) than other product managers. Growth metrics are about people making specific decisions: to try a product for the first time, to purchase, to expand usage, etc. 

People working on Growth are typically well-versed in analytics and user research. However, some PMs (especially early-career PMs) build their experimentation plans without genuinely understanding the logic of their proposed experiments. They see an opportunity, have an idea, attribute it to a specific metric, and want to run it. Senior management can feel when you don’t have a solid grasp of the logic behind the suggestion and will challenge you. What’s more important is that if you don’t understand why your suggestion could impact a metric, you won’t succeed in growth work. 

I partly covered how to identify factors that lead to improving key growth metrics, and behavioural models can add another dimension to it. Try ideating growth experiments by analysing how to impact behavioural components of a specific action you are trying to drive, and you’ll quickly see how well-thought they were before that. 

Closing thoughts

I have utilised BMAT in the research I’ve carried out, and I’ve seen a colleague (shoutout to Maja Lukomska) carry out COM-B research. These models are not the silver bullet to uncover golden insights, but they provide another perspective and ability to surface insights you previously missed.

Frameworks (JTBDs, BMAT, etc.) just help us adopt a different perspective. And a different perspective is sometimes all we need to connect previously unconnected insights. 

Additional readings

1. Michie et al.: The behaviour change wheel: A new method for characterising and designing behaviour change interventions. Implementation Science 2011 6:42.

2. Robert West, Susan Michie. (2020). A brief introduction to the COM-B Model of behaviour and the PRIME Theory of motivation.

3. BJ Fogg. 2009. A behavior model for persuasive design. In Proceedings of the 4th International Conference on Persuasive Technology (Persuasive '09).