Behaviour change demands a different starting point
When the brief is behavioural, the design process needs a different kind of foundation. Screens, journeys and features can describe an experience, but they cannot explain why someone would move from one behaviour to another, or what might stop that movement happening in practice.
For that, we used Bob Moesta’s Four Forces of Progress. The framework starts from a simple but useful premise: people do not move towards a new behaviour simply because the alternative looks better. They move when the push of their current situation and the pull of a better one become stronger than the anxieties of change and the habits of the present.
That distinction matters because most digital products overinvest in pull: clearer benefits, better messaging, smoother journeys, more engaging features. But in behaviour change work, the forces holding someone in place are often more powerful than the thing trying to move them. Design has to work with all four forces, not just make the desired future more attractive.
Mechanisms, not features
With that foundation, the design work itself shifts from features to mechanisms. The mechanics can be borrowed from products that have already proven them at scale, from the readiness scores of wellness wearables to the forgiving streaks of language learning apps.
What changed in our practice is how we treat those borrowed patterns. We stopped collecting them as inspiration and started documenting them as mechanisms, each with a structured anatomy: the behavioural principle underneath it, the evidence it works, the data it needs about a person, and how it may fail for the people we are designing for.
The failure mode is the design brief
Behavioural mechanics are powerful, which is exactly why they need a duty of care. A streak motivates until the streak is broken, which could then be interpreted as failure. Social features provide proof that progress is possible, or they provide comparison that confirms someone's worst beliefs about themselves, the difference being entirely in how that comparison is expressed. Before any mechanism is adopted, we need to understand the potential harm it could create for the person using it, and whether it materially contributes to one or more of the Four Forces of Progress.
Prove the mechanism before building the machine
The final shift is in how we test. Because the value lives in the mechanism rather than the interface, most of it can be proven before anything is built. For example, a guided onboarding conversation can be run by a researcher over a fortnight. If a human applying that mechanism cannot shift behaviour, software automating it will not either. This is Lean Startup logic applied one level deeper than the feature.
The practice we have arrived at is straightforward to state. When the brief is behavioural, start by understanding the Four Forces of Progress. Then design mechanisms grounded in evidence rather than features grounded in convention, build the context that makes those mechanisms intelligent, and prove they move people before committing to build.
