Lean UX Canvas: el problema y la hipótesis en una página

¿Qué es y de dónde viene?

El Lean UX Canvas nace de la práctica de Lean UX. Jeff Gothelf, que escribió el libro Lean UX con Josh Seiden, explica el canvas como un orden de trabajo y cuenta que el libro está organizado en torno a él. La idea de fondo es tratar cada funcionalidad como una hipótesis: una suposición sobre qué usuarios necesitan y qué resultado de negocio se conseguirá. Si la suposición es falsa, conviene descubrirlo pronto y barato.

IxDF lo describe como un marco de una página para alinear equipos en torno a supuestos, hipótesis y experimentos, que cubre objetivos de negocio, segmentos de usuarios, supuestos, hipótesis y métricas de éxito. Lo importante no es rellenarlo, sino usarlo para decidir qué probar después.

¿Cuáles son sus ocho cajas?

Gothelf presenta el canvas como un orden de trabajo. Estas son las ocho cajas, en el orden en que sugiere llenarlas:

1. Problema de negocio: qué problema tiene la organización, sin mencionar soluciones.
2. Comportamientos o resultados de negocio: qué conductas medibles deberían cambiar.
3. Usuarios: un proto-persona con sus necesidades, obstáculos y contexto.
4. Resultados y beneficios para el usuario: qué gana la persona si el problema se resuelve.
5. Soluciones: ideas posibles, sin priorizar todavía.
6. Hipótesis: la afirmación que une las cajas 2 a 5.
7. Lo más importante que aprender primero: el mayor riesgo de la hipótesis.
8. Lo mínimo para aprenderlo: el menor trabajo necesario para aprender lo siguiente más importante. Las respuestas son experimentos.

La caja 6 es la que ordena el resto. Si no puedes escribirla en una frase, aún no sabes qué estás probando.

¿Cómo se escribe una hipótesis que se pueda comprobar?

Gothelf propone esta forma: creemos que este resultado de negocio se logrará si este usuario obtiene este beneficio con esta funcionalidad. Tiene tres partes que se pueden comprobar por separado: el resultado de negocio, el usuario y la funcionalidad.

Otras fuentes usan una redacción distinta, por ejemplo, “creemos que esta solución logrará este resultado para este usuario porque estas razones”. La diferencia no es de fondo, pero sí de consistencia: elige una forma y úsala en todo el equipo para que las hipótesis sean comparables.

Una hipótesis buena es aquella que puede salir mal. Si ninguna prueba puede desmentirla, no sirve para aprender.

¿Cómo se prioriza lo que se va a probar?

Gothelf trata la priorización en un lienzo aparte, el Hypothesis Prioritization Canvas. Para elegir por dónde empezar, sugiere una matriz de riesgo frente a valor percibido:

• Alto riesgo y alto valor: prueba primero. Es lo que más puede cambiar el resultado.
• Alto valor y bajo riesgo: no hace falta probarla; Gothelf dice que basta con construir, publicar y medir.
• Bajo valor: en general no se prueba y probablemente no se construye, sin importar lo llamativa que sea la idea. Las de alto riesgo y bajo valor suelen descartarse.

En la matriz, el eje de riesgo depende del contexto (diseño, marketing, marca) y el de valor es el impacto esperado en clientes y negocio. Es una herramienta de conversación, no un cálculo: obliga al equipo a justificar por qué una idea está arriba.

¿Qué pasa después de cada experimento?

Gothelf describe un ciclo simple. Si la hipótesis se mantiene, se repiten las cajas 7 y 8 con el siguiente riesgo más importante y experimentos de fidelidad cada vez mayor, que confirman la señal con algo más costoso. Si la hipótesis no se mantiene, el equipo puede pivotar o descartarla, y revisa el canvas completo, porque el error puede estar en el problema, en el usuario o en la solución.

Esta última parte es la que más se olvida. Un experimento fallido no es un fracaso si cambia la forma en que el equipo entiende el problema.

¿Cuándo NO conviene usar el Lean UX Canvas?

• Cuando el problema de negocio ya está validado y no hay incertidumbre que probar. El canvas añade trabajo sin aprendizaje.
• Cuando el equipo no puede hacer experimentos ni tiene acceso a usuarios. Un canvas sin pruebas se queda en supuestos.
• Para justificar decisiones ya tomadas. Usarlo como trámite convierte las cajas en un documento de aprobación.

Ejemplo

Ejemplo ilustrativo: una app de gestión de gastos para trabajadores independientes tiene una tasa de abandono alta en el primer mes.

• Problema de negocio: muchos usuarios dejan de usar la app antes de conectar su cuenta bancaria.
• Usuario: un trabajador independiente que factura poco al mes y no quiere revisar cada gasto a mano.
• Hipótesis: creemos que la retención al mes subirá si el trabajador independiente ve su resumen de gastos en menos de cinco minutos, porque no tendrá que categorizar cada movimiento.
• Lo más importante que aprender: si el trabajador independiente confía en la categorización automática.
• Experimento mínimo: una prueba con cinco personas que categorizan a mano y luego ven la propuesta automática, sin construir nada.

Si la prueba falla, el equipo sabe que el problema no era el tiempo de carga, sino la confianza. Eso cambia la siguiente hipótesis.

Para pasar de hipótesis a diseño de flujo, el artefacto de user flows suele ser el siguiente paso, y los prototipos sirven para probar la hipótesis sin construirla del todo. Si tu caso tiene un perfil de usuario claro, las personas ayudan a completar la caja 3.

Errores comunes

• Saltarse la investigación con usuarios y escribir la caja de usuarios con suposiciones.
• Tratar las hipótesis como verdades, en vez de como preguntas que hay que responder.
• Construir antes de validar la hipótesis más arriesgada.
• Leer “lean” como sinónimo de poco esfuerzo o de baja calidad.
• No medir si la solución logra el resultado de negocio, solo si el usuario la usa.
• Llenar las ocho cajas en una sola sesión sin volver a ellas.

Fuentes

• Jeff Gothelf, How to use the Lean UX Canvas
• IxDF, Lean UX