How we design for behaviour change

Every product change is a bet on behaviour. You ship an onboarding step to get people to finish setup. You add an invite flow to get teammates in. You redesign a screen to get a decision made faster. If the behaviour does not move, the change was waste, however clean the code and however fast the agent built it.

This is the gap analytics cannot close. Analytics tells you a behaviour did not happen: the invite never got sent, the setup never finished. It cannot tell you why, and it cannot tell you what to build so that it does happen next time. Answering that is a discipline of its own, and it has a name.

There is a mature body of work on why people do and do not do things, built over decades where getting behaviour wrong carried real costs. We did not invent it. What we did was operationalise it for agents, so a coding agent building a feature works from a diagnosis of why your users behave as they do, rather than from a guess about what they might want.

Three ideas do most of the work: COM-B as the diagnosis, the Behaviour Change Wheel as the bridge from diagnosis to intervention, and behaviour change techniques as the active ingredients. They are worth understanding even if you never touch our product, so here they are in plain terms.

The COM-B model says any behaviour sits on three conditions, and all three have to be present at the moment of action. Take one away and the behaviour does not happen, no matter how strong the other two are.

The power of this is diagnostic. When users are not inviting their teammates, the reason is one of three very different things. Capability: they do not know it is possible or cannot find how. Opportunity: there is no prompt at the moment they would want to. Motivation: they see no reason it is worth doing. Each points to a different build. Ship the wrong one and you have spent your agents on a change that could never have worked. The diagnosis comes first precisely so the build is not a guess.

The original COM-B and Behaviour Change Wheel paper ↗ (Michie, van Stralen and West, 2011) is open access if you want the source, and The Decision Lab has a plain-English guide to the model ↗ if you want the shorter version first.

Knowing which of Capability, Opportunity, or Motivation is the constraint tells you what is wrong. The Behaviour Change Wheel tells you what kind of change would fix it. It maps each COM-B component to intervention functions: education and training for a capability gap, environmental restructuring or enablement for an opportunity gap, persuasion, incentivisation, or coercion for a motivation gap, among others.

This is the step most product teams skip. They jump from a symptom straight to a solution they already had in mind. The Wheel forces the honest question in between: given that the blocker is here, what class of intervention actually addresses it? An education fix for a motivation problem fails every time, and it fails quietly.

An intervention function is still a category. To build, you need something concrete. That is what behaviour change techniques give you: a shared taxonomy of named, defined techniques, each the smallest reproducible unit of a working intervention. Goal setting. Prompts and cues. Feedback on the behaviour. Social proof. Rehearsal. Restructuring the physical environment. Dozens of them, each with a precise definition so that two people mean the same thing by the same name.

This matters for one reason: a product requirement grounded in a named technique is testable and traceable in a way a hunch never is. When a spec says add a prompt at the point of decision because the blocker is physical opportunity, and cites the interviews that showed it, anyone can check the reasoning and anyone can measure whether it worked. A requirement that just says users should invite more people cannot be argued with or learned from.

At Dipio the sequence is the same every time. Real interviews surface the behaviour and its blockers in users’ own words, not in the leading language of a survey. We diagnose against COM-B to locate the actual constraint. We select the techniques suited to that constraint and to that context. What comes out is a spec.

Spec-driven development ↗ already made the spec the unit of work for coding agents. GitHub’s Spec Kit ↗, AWS’s Kiro ↗, and the specify, plan, tasks and implement flow now built into most agents all take the same shape: write the spec, and the agent builds it. What every one of them takes as given is the thing that actually decides the outcome, whether the spec was worth building in the first place.

That is the layer we supply. A Dipio spec is validated intent made buildable: what to build, why it should work, the success criteria to hold it to, and the evidence it stands on. Specific enough to hand straight to Spec Kit or Kiro, or to your engineers, and ship without a human rewriting it in the middle.

Turning hundreds of messy transcripts into a defensible diagnosis and the right technique selection, quickly and consistently, is hard. The science it rests on is independently validated: our first paper is in press at Behavioural Public Policy (Cambridge University Press). Read the paper ↗

Coding agents can build almost anything you can specify. That makes the choice of what to build the whole game. A behavioural diagnosis is what keeps that choice pointed at changes that move behaviour, instead of changes that merely ship. It is the difference between an agent that is fast and an agent that is right.

This is why behaviour change design sits at the centre of the Dipio Evidence Loop. The science tells you what is worth building. The loop delivers it straight into the tools that build it.