Hypothesis-driven design

Long specs let teams agree without aligning.

Four lines force the assumption, the person, the behaviour change and the success metric into one sentence. Now the team argues about each line specifically, instead of philosophically.

Fretello’s notifications prompt.

We believe that exposing the value of reminders, for beginner guitar players, will help them build the practice routine they need to succeed. We’ll know this is true when the opt-in rate to notifications rises past a threshold agreed before the test.

What a hypothesis actually is

The point of writing it down is to make the belief checkable. After that, you can find out whether you actually understand your users, or whether you've been pattern-matching on yourself.

Every test that comes back with an answer (confirming or refuting) opens up the next set of questions. That's the loop. The only discipline is to base each hypothesis on something you've seen, in user behaviour or in the data, rather than on what you'd like to be true.

We believe that… [the assumption] For… [the persona or segment] We will… [the change in user behaviour we're betting on] We'll know this is true when… [the metric]

Better collaboration, less documentation

Hypothesis-driven design changed how the teams I worked with showed up to work. Anyone could propose a hypothesis. Anyone could push back on someone else's. The PM, the engineer, the visual designer, the QA lead, all in the same room with the same shape of statement on the wall.

I've used this loop at Fretello, at SellerCrowd, and on smaller projects in between. It's portable. It scales down to a single designer-PM pair and up to a cross-functional pod. The hardest part is the discipline of not skipping the metric line because everyone “agrees” already.

Senior Product Designer · Methodology lead. Cross-functional product pods at Fretello and SellerCrowd. I owned workshop facilitation, hypothesis writing, validation method choice and post-test synthesis.

My wider product and design work spans more than twenty years, including consumer AI at Fretello and five years inside the B2B SaaS contribution-engine rebuild at SellerCrowd.

Validating your hypothesis

Pick the validation method before you run anything. Quantitative (A/B, opt-in deltas, retention curves) tells you what changed. Qualitative (interviews, walkthroughs, watching someone in front of the screen) tells you why.

Decide upfront. Otherwise the team will quietly redefine “success” once results land. I've watched this happen on hypotheses I wrote myself. The fix is to lock the metric and the threshold in the same conversation that locks the hypothesis.

The hypothesis was right. Ship the change. The next hypothesis usually writes itself: if reminders work for beginners, do they also work for intermediates? At what frequency?

The hypothesis was wrong. The interesting part. Now you know one specific thing that isn't true, which is more valuable than another opinion.

The result was ambiguous. Tighten the experiment, or admit the question wasn't sharp enough to begin with.

Either way, the loop continues.