Design hypotheses
A design hypothesis is a testable belief about how a change will help a specific user achieve an outcome. It connects ideation to learning: you state what you believe, who it is for, what success looks like, and what evidence would prove you wrong.
Why it matters
Hypotheses turn open HMW questions into commitments you can validate. They make success criteria explicit before build, support prioritisation, and help teams avoid shipping features nobody needed.
Key ideas
- Falsifiable. A hypothesis should state what observable signal would disprove it.
- User-centred. Name the user and the outcome they care about, not only internal metrics.
- Linked to HMWs. Each hypothesis should answer a specific How Might We from upstream work.
- Observable signals. "We'll know we're right when…" must be measurable or detectable in research or analytics.
- Learning over proving. Failed hypotheses are valuable — they save larger investment later.
Useful form: "We believe [change] for [user] will achieve [outcome]. We'll know we're right when [signal/metric]."
How it fits the pipeline
Design hypotheses translate opportunities into testable beliefs before stories and delivery artefacts are written.
Common mistakes
- Vague success criteria ("users will be happier")
- Hypotheses that cannot be tested with available methods
- Skipping the link to parent HMW statements
- Treating hypotheses as marketing claims rather than experiments
Further reading (NN/g)
- — using evidence and metrics to decide what to explore next
- — validating hypothesis maps with user research
- — connecting UX outcomes to measurable business value (NN/g course)
Educational summaries informed by research published by Nielsen Norman Group.