What workshops teach you that reading doesn't

The things you only learn by watching other people try to use your work.

BUILDING BEHAVIOURKIT

Lauren Kelly

1/7/2019

I've been running workshops with BehaviourKit. Card decks and canvases at the ready. A few frameworks I've pulled together from the literature, simplified for practitioners.

Here's what I'm learning.

People love naming things. When you give someone a card that says "loss aversion" and a one-line description of what that means, something clicks. They point at it and say, "That's what's happening in our project." The named thing gives them permission to talk about behaviour in a structured way, rather than just guessing or blaming users.

That part is working. The "behavioural insights" side. Cognitive biases, heuristics, specific findings from the research. When you hand those to a team, they have a frame to put around what they're seeing. It's like giving someone a pair of glasses.

What's not working as well is the "fundamentals" side. The bigger frameworks. When I try to introduce COM-B, even a simplified version, I can see the energy leave the room. It's too abstract. People nod. They write it on a sticky note. Then they carry on exactly as before.

I think I understand why. COM-B tells you that behaviour is a function of capability, opportunity, and motivation. True. Useful as a thinking tool. But it doesn't tell you what to actually do when motivation is low. It names the category of problem without giving you the next step.

It's like a doctor saying, "The issue is in your digestive system." Right. But which bit? And what do I do about it? I know there is the Behaviour Change Wheel. But that has it's own struggles taking into a room without a behavioural science degree in sight.

The unit of understanding for practitioners isn't "theory." It isn't even "framework." It's something more like: a named thing that happens in the world, that I can see in my project, that comes with a clue about what to do next.

A bias. A heuristic. A pattern. Something with a name, a shape, and an example.

I'm also noticing something about how teams use the Drive Grid canvas. When you ask them to rate each driver as "helping" or "hindering," they engage quickly. The 3x3 grid is intuitive. Red and green are universal. But the moment they finish the grid and ask "so what do we do now?" I watch their eyes go back to me.

I'm the routing. The card deck is the content. The workshop is the delivery. But the intelligence that connects "this driver is hindering" to "try this approach" is all in my head. It doesn't live in the system yet.

I don't think that's a problem for now. I'm a consultant. Being in the room is literally what I get paid for. But I'm filing this away. Because if I want BehaviourKit to become something more than workshop materials, at some point the system needs to make recommendations without me standing there.

A few other things I've noticed:

The word "behaviour" makes people flinch slightly. In a design context, everyone talks about "users" and "journeys" and "touchpoints." Saying "this is a behaviour problem" feels clinical. Almost accusatory. As if you're blaming the person for acting wrong. I need to find language that's softer. "What's driving this?" lands better than "what's the behavioural barrier?"

Also: teams consistently want fewer options, not more. When I spread 20 cards on a table, they freeze. When I hand them three and say "one of these is probably closest," they engage immediately. Constraint is a feature, not a limitation.

I'll remember that.

The design community is in an interesting moment right now. Service design is maturing. There's more talk about "systems thinking" and "complexity." But the tools haven't caught up. Everyone is thinking systemically and then reaching for a journey map. The toolbox is narrower than the thinking.

I think behavioural science could fill part of that gap. Not all of it. But the part that says: people are not just points on a journey. They have reasons for what they do. And if you can name those reasons, you can design for them.

That's what I'm trying to build. I just need to figure out the right shape for it.

Go deeper into the Building BehaviourKit series: