Design Principles
Hypothesis-First Design
Every design decision is a testable assumption — treat it as a hypothesis until user behaviour proves it right or wrong.
Where it comes from
It's another Lean UX principle from Jeff Gothelf: treat every design decision as a hypothesis — a testable assumption about what users will understand and do — rather than a settled fact. The discipline is to make the assumption explicit so it can be checked.
Why it matters for your website
Most design decisions are educated guesses wearing the clothes of certainty. Gothelf's hypothesis-first principle says every design choice — the headline, the flow, the label, the layout — is an assumption about what users will understand and respond to, and should be treated as testable rather than fixed. Pages designed once and never challenged accumulate assumptions that may have been wrong from the start. An audit can't run the experiments, but it can name the assumptions and flag the highest-risk ones.
The danger is quiet certainty. A headline, a flow, a label, a layout each embody an assumption about how users will respond — but once shipped, they tend to harden into 'how it is', and assumptions that were never tested may have been wrong from the start.
Framing decisions as hypotheses keeps them honest. 'We believe this headline will make the value clear to this audience' is a claim that can be checked; 'this is the headline' is not. The reframing doesn't require running every experiment — but it does mean knowing which of your assumptions carry the most risk.
Wrong vs right
Treating the headline, flow, and labels as settled facts, never revisited after launch.
Treating each as a hypothesis — an assumption about user response that can be tested and revised.
Defending a design choice on the basis that it's already live, rather than whether it works.
Naming the assumption behind the choice and asking what evidence would confirm or refute it.
Shipping a page built on untested guesses and never checking whether the guesses held.
Identifying the highest-risk assumptions and prioritising them for testing.
Understanding Hypothesis-First Design
Hypothesis-first design treats every design decision as a testable assumption rather than a fixed truth. In this view, the headline you chose, the flow you built, the label you wrote, and the layout you settled on are all guesses — educated ones, perhaps, but guesses — about what users will understand and how they'll respond. Calling them hypotheses keeps that uncertainty visible.
The risk the principle guards against is unexamined certainty. Once a design ships, its assumptions tend to calcify into 'the way things are', and a page that's designed once and never challenged accumulates beliefs that may have been wrong from the outset. Framing each decision as a claim — 'we believe X will cause Y for users like Z' — makes it something that can be checked rather than merely asserted.
An audit can't run your experiments, but it can do the next best thing. It can name the assumptions a page is built on and flag the highest-risk ones — the places where being wrong would cost the most — so testing effort goes where it matters. It connects to UX debt, actionable metrics, and barrier analysis.
How Kweri checks it
Kweri's role here is exactly the one the principle describes for an audit: it can't run experiments on your users, but it can surface assumptions. Kweri can identify design and copy choices that embody untested beliefs about user response, and flag the higher-risk ones worth validating. What it can't do is tell you whether those assumptions are actually correct — only a test on your real traffic can. So Kweri names the assumptions and prioritises the risky ones, and is explicit that confirming them is your experiment to run.
FAQ
What is hypothesis-first design?
Hypothesis-first design treats every design decision as a testable assumption about how users will respond, rather than a fixed fact. The headline, flow, label, and layout are all hypotheses to be validated, not settled truths.
Why treat design decisions as hypotheses?
Because most are educated guesses, and once shipped they tend to harden into 'how it is' without ever being checked. Framing them as hypotheses keeps the uncertainty visible and makes each decision something that can be tested and improved.
How do I write a design hypothesis?
State the belief, the change, and the audience: 'We believe [this design] will cause [this user behaviour] for [these users].' That format makes the assumption explicit and gives you something concrete to validate or refute.
Can an audit test design hypotheses?
Not directly — an audit can't run experiments on your users. But it can name the assumptions a page is built on and flag the highest-risk ones, so you know where testing effort will pay off most.
Who developed hypothesis-first design?
It's a principle from the Lean UX movement, articulated by Jeff Gothelf. It applies the scientific method to design, treating decisions as hypotheses to be validated through user behaviour.
Related principles
Before designing any conversion solution, you must diagnose exactly what prevents the target behaviour — generic friction reduction fails when the actual barriers are specific and unaddressed.
Deferred UX iteration accumulates like technical debt — first-pass decisions that were never revisited compound into a product that quietly stops working.
Numbers that look impressive but don't tell a meaningful story about real value are vanity — they decorate rather than persuade.
Attribution & sources
Identified by Jeff Gothelf. Catalogued from Lean UX (Jeff Gothelf).
A core principle of the Lean UX movement; the linked reference is used here.
See Hypothesis-First Design on your own site
Run a free Kweri audit — a plain-English review of your site’s speed, accessibility, SEO and design, ranked by what to fix first. No login, no jargon.
Run a free audit →