A note on language
The downloadable template is in Spanish. This page explains what it contains and the reasoning behind each block, so you can judge whether it fits before translating.
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.
It is in Spanish. 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.
{/* --- INICIO DOCUMENTO --- */}
Iniciativa: [nombre] Equipo: [quiénes participaron — cargos, no solo nombres] Fecha: [DD/MM/AAAA] · Próxima revisión: [DD/MM/AAAA]
1. Declarar el problema
[Nuestro producto o servicio] fue diseñado para alcanzar [estos objetivos].
Hemos observado que no está alcanzando [estos objetivos], lo cual causa [estos efectos adversos] a nuestro negocio.
¿Cómo podríamos mejorar [el producto o servicio] para que nuestros usuarios tengan más éxito, medido en [estos criterios]?
2. Hoja de suposiciones
Sin filtro y sin discutir todavía si son ciertas. El objetivo de este paso es sacarlas de la cabeza de cada persona y ponerlas en una lista común.
Sobre el negocio
- Creo que mis clientes necesitan [ ]
- Esa necesidad se resuelve con [ ]
- El valor principal que un cliente obtiene de esto es [ ]
- Voy a conseguir clientes principalmente por [ ]
- El mayor riesgo de este producto es [ ]
- Si esta suposición resulta falsa, el proyecto se cae: [ ]
Sobre las personas usuarias
- ¿Quién es? [ ]
- ¿Dónde entra este producto en su trabajo o en su vida? [ ]
- ¿Qué problema le resuelve? [ ]
- ¿Cuándo y cómo lo usa? [ ]
- ¿Qué necesita que haga? [ ]
3. Priorizar las suposiciones
Se testea primero lo de arriba a la derecha: alto riesgo si es falsa, y poco conocimiento acumulado sobre ella.
| Suposición | Riesgo si es falsa | Cuánto sabemos | ¿Se testea ahora? |
|---|---|---|---|
| [ ] | alto / medio / bajo | conocido / desconocido | sí / no |
| [ ] | |||
| [ ] |
4. La hipótesis
Una por suposición priorizada. Si sale más de una hipótesis por suposición, es señal de que la suposición todavía estaba muy gruesa.
Creemos que [haciendo esto] para [estas personas] lograremos [este resultado].
Sabremos que es válida cuando veamos [esta evidencia], antes de [fecha].
5. El experimento
¿Qué necesitamos aprender primero? [Tipo de usuario, necesidad de negocio, necesidad del usuario, contexto de uso…]
¿Qué es lo más pequeño que podemos hacer para aprenderlo? [Prototipo de baja fidelidad, entrevistas, benchmark, test con cinco personas, botón que todavía no lleva a ninguna parte, encuesta a la base…]
Qué haremos, en concreto: [Descripción del experimento: con quiénes, cuántos, dónde, en qué plazo.]
6. La evidencia
Se define acá, antes de correr nada.
| Criterio | Umbral | |
|---|---|---|
| Resultado cuantitativo | [qué se mide] | [a partir de qué valor lo damos por válido] |
| Resultado cualitativo observable | [qué tendríamos que ver o escuchar] | [en cuántas sesiones de cuántas] |
Fecha de corte: [DD/MM/AAAA]
7. Qué haremos con el resultado
Este bloque se completa antes del experimento. Es el que convierte el ejercicio en una decisión y no en un informe.
Si se confirma: [qué construimos, con qué alcance, quién lo toma]
Si se invalida: [qué dejamos de hacer, qué exploramos en cambio]
Si el resultado es ambiguo: [qué haría falta para desempatar, o cuánto más estamos dispuestos a invertir en averiguarlo]
8. De los resultados a las features
Recién acá aparecen las funcionalidades, y aparecen como consecuencia del resultado que buscamos.
| Vamos a lograr | si la persona | puede lograr | con esta feature |
|---|---|---|---|
| [resultado de negocio] | [persona usuaria] | [resultado de usuario] | [feature] |
Nota de método y limitaciones
Las suposiciones de esta hoja son las que el equipo alcanzó a hacer explícitas en [fecha]. Las que nadie nombró siguen operando igual.
Una hipótesis confirmada en un experimento pequeño describe lo que pasó en ese experimento, con esas personas y en ese contexto. No es una generalización a toda la base de usuarios.
Caduca. Revisar en [fecha]: si el producto, el mercado o el equipo cambiaron, las suposiciones de arriba ya no son las que están operando.
{/* --- FIN DOCUMENTO --- */}
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.