Facilitation as a form of research

I've been running the Strategic Behavioural Design bootcamp for several months now, and I want to share something I wasn't expecting: the teaching is changing how I see the system.

When you build something over several years, you develop a very particular relationship with it. You know where the logic is tight and where it's loose. You know which connections are strong and which are educated guesses. You know the shortcuts, the edge cases, the bits where you'd give different advice depending on context. That knowledge is useful. It's also invisible to you, because it's become part of how you think.

Teaching makes the invisible visible. When you watch someone encounter your system for the first time, you see it through their eyes. And their eyes catch things yours have stopped noticing.

Here are four things I've learned from watching practitioners use BehaviourKit.

People conflate drivers with interventions. When a team is filling in the Drive Grid and they reach a driver like "Environment," they often start listing interventions rather than describing the current state. "We should send more reminders" instead of "people aren't seeing the cue to act." The driver is supposed to describe what's happening. The intervention comes later. But the pull toward solutions is so strong that teams skip diagnosis and jump to fixing, even when the tool is explicitly designed to slow them down.

This tells me the system needs clearer guardrails between the diagnostic phase and the prescription phase. The boundary exists in the chain (drivers first, then levers, then patterns), but in practice, people blur it. I need the UX to hold that boundary more firmly.

People anchor on the first driver they identify. Once a team has named one red zone on the grid, they tend to focus there and stop looking. "Motivation is the problem" becomes the diagnosis, even though three other drivers might also be red. The grid is designed to give a whole-system view, but the human tendency toward premature closure means teams often collapse it into a single-factor explanation.

This is, ironically, a well-documented behavioural phenomenon. Anchoring and satisficing. The very biases the system is designed to help people address are present in how people use the system. Which is both funny and instructive.

Social drivers get underweighted consistently. Almost every team I've worked with spends most of their diagnostic time on the Self row (Heart & Mind, Motivation, Doing) and relatively little on the Social row (Group Values, Flux, Influence). This isn't because the social drivers are less important. It's because individual-level explanations feel more natural. "People don't want to" is easier to articulate than "the group norm signals that this behaviour is unusual."

The social layer is often where the real leverage sits, especially in organisational and community behaviour. But it's the layer that practitioners are least practised at seeing. The grid makes it visible. The facilitation needs to make it salient.

The connection chain is used backwards more often than I expected. I designed the chain to flow from left to right: driver to mechanism to strategy to tactic to pattern. Diagnose first, then select. Some bootcamp participants do the opposite. They find a pattern they like, then work backwards through the chain to find a driver that justifies it. Solution-first, diagnosis to fit.

I understand the instinct. If you've seen a case study where a particular pattern worked brilliantly, you want to use it. Working backwards through the chain lets you construct a rationale. The problem is that the rationale might be post-hoc. The driver you land on might not be the one that's actually present in your situation.

This is a system design problem, not a user problem. If the chain can be navigated in both directions equally easily, some people will start at the wrong end. The system needs to make the diagnostic entry point the natural one and the pattern library less browsable.

Every one of these observations has shaped how I think about the eventual digital product. The facilitation catches these mistakes in real time. A self-service product needs to catch them by design. Which means the product needs to do what I do in the room: hold the diagnostic boundary, prompt for the whole picture, surface the social layer, and make it harder to work backwards from a preferred answer.

Teaching is research. Every bootcamp session gives me data about where the system works, where it misleads, and where human tendencies fight the intended flow.

Go deeper into the Building BehaviourKit series: