Asking a different kind of question

Quick Start, the feature I want to be BehaviourKit's front door, went through three versions this month. The first two failed. The third one works, and the reason it works taught me something I should have understood years ago.

Version one was a simplified diagnostic flow. The full system asks detailed questions about which drivers are present and in what state. The quick version asked fewer questions, lighter touch. It was still too many. By the time a user worked through even a shortened diagnostic, they'd spent fifteen minutes doing a less precise version of the full process. Quicker, but not quick. Simpler, but not simple.

Version two swung in the other direction. I added more structure: context questions, evidence layers, editable fields. The reasoning was that if users had more information, they'd make better choices. The feature became more correct. And much slower. Twenty minutes in, users were doing a worse version of the full diagnostic and wondering why they hadn't just used that instead.

I was stuck in a loop. Make it faster, it gets less correct. Make it more correct, it gets slower. Every time I approached fast enough, I'd worry about accuracy and add something. Every time accuracy felt right, I'd check the clock and strip something out.

The breakthrough came from stepping back and questioning the type of question I was asking, rather than the number of questions.

A diagnostic question asks: "What driver is causing this?" That requires expertise. You need to understand what drivers are. You need to assess which one is present and in what state. You need behavioural science vocabulary, or at least a passing familiarity with the framework. That's a high bar for someone who just wants to know what to do about the fact that their change programme is stalling.

A recognition question asks: "Which of these sounds like your situation?" That requires lived experience. You already know what your problem feels like. You've been sitting with it for weeks. You just need to point at the description that matches.

The difference between those two question types is enormous. Diagnosis requires training. Recognition requires attention.

So instead of asking users to diagnose which driver is at play, I'm asking them to recognise which contradiction they're living with.

"The new behaviour is better, but..."

"...it costs more effort than the old way"

"...it exposes people to judgement"

"...the payoff is invisible or delayed"

"...it clashes with how work actually flows"

"...no one else is doing it yet"

Five contradiction types. Each one maps to a cell in the matrix. Each cell routes to a specific principle and play. The user doesn't need to understand drivers, levers, or mechanisms. They just need to recognise their situation in one of the descriptions.

Three screens. Four taps. Under ten minutes.

Screen one: what's happening? Describe the behaviour you're trying to change.

Screen two: what's getting in the way? Pick the contradiction that sounds closest.

Screen three: here's what to try. The system presents a recommendation, with evidence, with guardrails, with a plain-language explanation of why this move fits this situation.

The system does the thinking. The user does the recognising.

This resolves the speed-vs-correctness dilemma, because the bottleneck was never the number of questions. It was the type of knowledge those questions demanded. Once the questions only demand recognition, the whole flow can be fast without sacrificing the quality of the routing.

There's a design principle that has survived from the very first workshops in 2019: people engage when you hand them three options and freeze when you hand them twenty. Quick Start is the purest expression of that principle. The system holds fifty-two patterns, sixty-three matrix cells, twelve principles, and hundreds of evidence links. The user sees one recommendation, clearly explained.

Constraint is a feature. It always has been.

Go deeper into the Building BehaviourKit series: