Cuándo usarla
Antes de investigar, cuando el equipo ya tiene una idea de qué construir y nadie ha dicho en voz alta qué está dando por cierto para llegar ahí.
Ese es el momento útil. Después, cuando la feature ya está en el backlog con fecha, el canvas se vuelve un trámite: nadie llena una hoja de suposiciones para descubrir que el trimestre completo se apoyaba en una que era falsa.
No es la hipótesis estadística. No hay hipótesis nula ni contraste de medias acá. Es la formulación de producto que popularizaron Jeff Gothelf y Josh Seiden en Lean UX: una creencia escrita de manera que se pueda probar y, sobre todo, refutar. Si lo que necesitas es diseñar un test A/B con potencia y significancia, esta plantilla te sirve para decidir qué testear, no para calcular el n.
Tampoco reemplaza al plan de investigación. El canvas define qué creemos y qué haría falta para creerlo menos; el plan define cómo se levanta esa evidencia, con quién y cuándo.
Antes de usarla
Una suposición no es una hipótesis, y la diferencia importa. Una suposición es algo que el equipo acepta como cierto sin haberlo probado ("los clientes profesionales necesitan recibir su pedido el mismo día"). Una hipótesis es esa misma creencia escrita de forma más granular, con un resultado esperado y un criterio de evidencia. Toda suposición es una hipótesis que todavía nadie escribió.
Prioriza por riesgo, no por facilidad. La tentación es partir por la suposición que se puede testear en dos días. La que hay que tomar primero es la que, si resulta falsa, tira abajo el resto del trabajo — y de la que además sabemos poco. Alto riesgo y bajo conocimiento: ese cuadrante.
La hipótesis se escribe con el resultado, no con la feature. "Creemos que un buscador con filtros mejora la experiencia" no es testeable: no dice quién, ni qué cambia en su comportamiento. La feature es la apuesta, no la creencia.
Define la evidencia antes de correr el experimento. Si el criterio se decide después de ver los datos, siempre gana la idea que ya teníamos. Es el punto donde más he visto fallar esto, incluido en trabajo mío.
No es un esfuerzo de validación si no estás dispuesta a matar la idea. Es la frase que uso para cerrar cuando enseño esto, y es también el filtro más barato: si la respuesta del equipo a "¿qué haríamos si esto se invalida?" es "igual lo construimos", el experimento no hace falta. Por eso el canvas trae ese campo adentro y se completa antes, no después.
Todo lo que va entre corchetes se reemplaza. El ejemplo trabajado está en esta página y no en el archivo descargable.
El documento
Se completa en equipo, idealmente con negocio y desarrollo en la sala. La parte que más rinde de esta plantilla no es la hoja llena: es la discusión que obliga a tener.
{/* --- 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 --- */}
Un ejemplo trabajado
En un proyecto de retail, el problema declarado fue que el sitio no estaba captando a un segmento de clientes profesionales —gente que compra insumos para su oficio, no para su casa— y que ese segmento terminaba comprando en tienda física.
La hoja de suposiciones dejó una lista larga, pero al pasarla por la matriz de riesgo quedaron dos arriba a la derecha. La primera: que ese cliente compraba en tienda por un tema de plazos de entrega. La segunda: que estaría dispuesto a pagar más por recibir el mismo día.
La segunda era la cara, y era la que nadie sabía. Escrita como hipótesis quedó así: creemos que ofreciendo despacho en 24 horas con recargo, para clientes profesionales, lograremos que compren en el sitio en vez de ir a la tienda. Sabremos que es válida cuando una proporción relevante de ese segmento haga clic en la opción de despacho en 24 horas.
El experimento más pequeño para aprenderlo no era construir la logística: era poner el botón antes de que existiera el servicio detrás, medir cuántos lo intentaban, y hablar con quienes lo hicieron. Barato, rápido, y con un costo real —la fricción de quien hace clic y se encuentra con que todavía no está disponible— que hay que declarar y acotar antes, no descubrir después.
Los números concretos de ese caso no los publico. Lo que sí se puede llevar de acá es la forma: el orden en que se llega a la hipótesis, y que el experimento se diseña sobre el resultado esperado y no sobre la funcionalidad.
Este ejemplo está solo acá, no en el archivo descargable.
Revisión antes de usarla
- ¿La hipótesis está escrita como afirmación, o quedó como pregunta?
- ¿Nombra a quién le pasa y qué resultado esperamos, o solo describe la feature?
- ¿Se puede refutar? Si no hay resultado posible que la deje en falso, no es una hipótesis.
- ¿El criterio de evidencia está escrito antes de correr el experimento, con umbral y fecha?
- ¿La suposición que estás testeando es la de más riesgo, o la más fácil de testear?
- ¿El bloque "qué haremos con el resultado" está completo, incluido el caso en que se invalida?
- ¿El equipo estaría dispuesto a matar la idea? Si no, no corras el experimento.
- ¿Anotaste qué costo tiene el experimento para las personas que se topan con él?
- ¿Pusiste fecha de próxima revisión?
Fundamento
La estructura viene de Lean UX, de Jeff Gothelf y Josh Seiden: de ahí salen la declaración de problema, la hoja de suposiciones y la formulación "creemos que… sabremos que es verdad cuando…". La matriz de riesgo y conocimiento y el paso de resultados a features también son de esa tradición. Lo que agregué acá es el bloque 7, qué haremos con el resultado, porque en el trabajo real es el que evita que el experimento sea decorativo.
La versión original de este material fue un taller que armé en 2021 junto a la UX Researcher Alejandra Veas Suárez, para un equipo de retail. Esta plantilla es esa estructura sacada del contexto de esa empresa y reescrita.
Para llevar la hipótesis a terreno: el plan de investigación declara el método y los entregables, la guía de entrevistas recoge el material cualitativo, y El corazón de tu investigación UX es sobre cómo formular las preguntas que van a poner esa hipótesis a prueba.
Si todavía no sabes con qué método testearla, Cómo elegir la metodología de UX Research es el paso previo.