When to use it
Before you research, when the team already has an idea of what to build and nobody has said out loud what they are taking for granted to get there.
That is the useful moment. Later, once the feature is in the backlog with a date on it, the canvas becomes paperwork: nobody fills in an assumptions sheet in order to find out that the whole quarter rested on one that was false.
This is not the statistical hypothesis. There is no null hypothesis or test of means here. It is the product formulation Jeff Gothelf and Josh Seiden popularised in Lean UX: a belief written so that it can be tested and, above all, refuted. If what you need is to design an A/B test with power and significance, this template helps you decide what to test, not to calculate the n.
It does not replace the research plan either. The canvas states what we believe and what it would take to believe it less; the plan states how that evidence gets collected, with whom and when.
Before you use it
An assumption is not a hypothesis, and the difference matters. An assumption is something the team accepts as true without having tested it ("professional customers need their order the same day"). A hypothesis is that same belief written more granularly, with an expected outcome and a criterion for evidence. Every assumption is a hypothesis nobody has written down yet.
Prioritise by risk, not by ease. The temptation is to start with the assumption you can test in two days. The one to take first is the one that, if false, brings down the rest of the work — and that you also know least about. High risk, low knowledge: that quadrant.
Write the hypothesis around the outcome, not the feature. "We believe a search bar with filters improves the experience" is not testable: it does not say for whom, or what changes in their behaviour. The feature is the bet, not the belief.
Define the evidence before you run the experiment. If the criterion gets decided after seeing the data, the idea we already had always wins. It is where I have seen this fail most often, including in my own work.
It is not a validation effort if you are not willing to kill the idea. It is the line I use to close when I teach this, and it is also the cheapest filter: if the team's answer to "what would we do if this is disproved?" is "we build it anyway", the experiment is not needed. That is why the canvas carries that field inside it, filled in beforehand rather than after.
Everything in brackets gets replaced. The worked example lives on this page and not in the downloadable file.
The document
It gets filled in as a team, ideally with business and engineering in the room. The part of this template that pays off is not the completed sheet: it is the conversation it forces.
The blocks, in order: the problem statement; the assumptions sheet, split into business and user; the risk-and-knowledge matrix that decides what gets tested first; the hypothesis itself, in the "we believe that… we will know it is true when…" form; the smallest experiment that could teach you the thing; the evidence, quantitative and qualitative, with a threshold and a cut-off date; what the team will do with each possible result, including the one where it is disproved; and only at the end, the table that turns outcomes into features.
Initiative: [name] Team: [who took part — roles, not just names] Date: [DD/MM/YYYY] · Next review: [DD/MM/YYYY]
1. State the problem
[Our product or service] was designed to achieve [these goals].
We have observed that it is not achieving [these goals], which is causing [these adverse effects] to our business.
How might we improve [the product or service] so that our users are more successful, measured by [these criteria]?
2. Assumptions sheet
No filter, and no arguing yet about whether they are true. The point of this step is to get them out of each person's head and onto a shared list.
About the business
- I believe my customers need [ ]
- That need is solved by [ ]
- The main value a customer gets from this is [ ]
- I will get customers mainly through [ ]
- The biggest risk in this product is [ ]
- If this assumption turns out to be false, the project collapses: [ ]
About the users
- Who are they? [ ]
- Where does this product fit into their work or their life? [ ]
- What problem does it solve for them? [ ]
- When and how do they use it? [ ]
- What do they need it to do? [ ]
3. Prioritize the assumptions
You test the top right first: high risk if false, and little accumulated knowledge about it.
| Assumption | Risk if false | How much we know | Test it now? |
|---|---|---|---|
| [ ] | high / medium / low | known / unknown | yes / no |
| [ ] | |||
| [ ] |
4. The hypothesis
One per prioritized assumption. If more than one hypothesis comes out of a single assumption, that is a sign the assumption was still too coarse.
We believe that [doing this] for [these people] will achieve [this outcome].
We will know it holds when we see [this evidence], before [date].
5. The experiment
What do we need to learn first? [Type of user, business need, user need, context of use…]
What is the smallest thing we can do to learn it? [Low-fidelity prototype, interviews, benchmark, test with five people, a button that does not lead anywhere yet, a survey to the installed base…]
What we will do, specifically: [Description of the experiment: with whom, how many, where, in what timeframe.]
6. The evidence
This is defined here, before running anything.
| Criterion | Threshold | |
|---|---|---|
| Quantitative result | [what gets measured] | [from what value we take it as valid] |
| Observable qualitative result | [what we would have to see or hear] | [in how many sessions out of how many] |
Cut-off date: [DD/MM/YYYY]
7. What we will do with the result
This block gets filled in before the experiment. It is what turns the exercise into a decision instead of a report.
If it is confirmed: [what we build, at what scope, who makes the call]
If it is invalidated: [what we stop doing, what we explore instead]
If the result is ambiguous: [what it would take to break the tie, or how much more we are willing to invest in finding out]
8. From results to features
Only here do features appear, and they appear as a consequence of the outcome we are after.
| We will achieve | if the user | can achieve | with this feature |
|---|---|---|---|
| [business outcome] | [user] | [user outcome] | [feature] |
Method note and limitations
The assumptions on this sheet are the ones the team managed to make explicit on [date]. The ones nobody named are still operating just the same.
A hypothesis confirmed in a small experiment describes what happened in that experiment, with those people and in that context. It is not a generalization to the whole user base.
It expires. Review on [date]: if the product, the market or the team changed, the assumptions above are no longer the ones in play.
A worked example
On a retail project, the stated problem was that the site was not capturing a segment of professional customers — people buying supplies for their trade, not for their home — and that this segment ended up buying in the physical store.
The assumptions sheet produced a long list, but running it through the risk matrix left two in the top-right corner. The first: that this customer bought in store because of delivery times. The second: that they would be willing to pay more to receive their order the same day.
The second one was the expensive one, and it was the one nobody knew. Written as a hypothesis it came out like this: we believe that by offering 24-hour delivery at a surcharge, for professional customers, we will get them to buy on the site instead of going to the store. We will know it is valid when a meaningful share of that segment clicks the 24-hour delivery option.
The smallest experiment that could teach us that was not building the logistics: it was putting the button there before the service existed behind it, measuring how many people tried it, and talking to the ones who did. Cheap, fast, and with a real cost — the friction of someone who clicks and finds it is not available yet — that has to be stated and bounded up front, not discovered afterwards.
I do not publish the actual numbers from that case. What does travel is the shape: the order in which you arrive at the hypothesis, and the fact that the experiment is designed around the expected outcome rather than around the functionality.
This example lives here only, not in the downloadable file.
Check before you use it
- Is the hypothesis written as a statement, or did it end up as a question?
- Does it name who it happens to and what outcome we expect, or does it only describe the feature?
- Can it be refuted? If no possible result would leave it false, it is not a hypothesis.
- Is the evidence criterion written before the experiment runs, with a threshold and a date?
- Is the assumption you are testing the riskiest one, or the easiest one to test?
- Is the "what we will do with the result" block complete, including the case where it is disproved?
- Would the team be willing to kill the idea? If not, do not run the experiment.
- Did you write down what the experiment costs the people who run into it?
- Did you set a next review date?
Grounding
The structure comes from Lean UX, by Jeff Gothelf and Josh Seiden: the problem statement, the assumptions sheet and the "we believe that… we will know it is true when…" formulation are theirs. So are the risk-and-knowledge matrix and the step from outcomes to features. What I added here is block 7, what we will do with the result, because in real work it is the one that keeps the experiment from being decorative.
The original version of this material was a workshop I put together in 2021 with UX Researcher Alejandra Veas Suárez, for a retail team. This template is that structure taken out of that company's context and rewritten.
To take the hypothesis into the field: the research plan states the method and the deliverables, the interview guide collects the qualitative material, and The heart of your UX research is about how to formulate the questions that will put that hypothesis to the test.
If you do not yet know which method to test it with, How to choose a UX Research methodology is the step before this one.