Lean UX: hipótesis, experimentos y aprendizaje
Lean UX organiza el diseño en torno a hipótesis que se prueban con experimentos pequeños. Cómo escribir una hipótesis falsable, el ciclo y cuándo no encaja.
¿Qué es y de dónde viene?
Según IxDF, las raíces de Lean UX están en el lean manufacturing, que impulsó Toyota y cuya idea central es eliminar el desperdicio: no construir lo que no se usa. Mary y Tom Poppendieck adaptaron esas ideas al software a comienzos de los años 2000, después llegó el desarrollo ágil (el Manifiesto Ágil es de 2001) y el lean startup de Eric Ries aportó el aprendizaje validado y el ciclo de construir, medir y aprender, que pone a prueba las ideas con experimentos.
Según IxDF, el libro de Jeff Gothelf y Josh Seiden (2013) aplicó estas ideas al diseño y defiende que la UX debe medirse por los resultados de los usuarios. El libro se reeditó después; el sitio oficial anuncia la tercera edición (copyright 2021), organizada en torno al Lean UX Canvas, una hoja de una página para identificar los supuestos más críticos de un proyecto. El punto de partida es ese: qué creemos que es cierto y todavía no hemos comprobado. Para el canvas completo, mira Lean UX Canvas.
¿Por qué le importa a un diseñador?
Porque cambia la forma de justificar el trabajo. En lugar de “entregamos cinco pantallas”, la pregunta pasa a ser “qué aprendimos y qué cambió en el comportamiento”. IxDF lo resume así: los equipos priorizan resultados (outcomes) sobre producción (outputs), y el éxito se juzga por el comportamiento de los usuarios y el valor entregado, no por las pantallas o funciones publicadas.
También reduce el costo de equivocarse. Un experimento pequeño que falla cuesta menos que una funcionalidad completa que nadie usa. Para un diseñador que trabaja con equipos de producto, esa diferencia es un argumento concreto para proponer pruebas antes de construir. Si quieres profundizar en la diferencia entre medir resultados y medir entregables, mira outcomes frente a outputs; y para los ritmos de trabajo, design sprints y el proceso de diseño UX muestran dos formas de organizar las mismas preguntas.
¿Cómo se escribe una hipótesis?
IxDF propone una plantilla: “Creemos que [esta solución] logrará [este resultado] para [este usuario] porque [estas razones]”. Es una forma de dejar explícito lo que el equipo asume.
Gothelf, en un artículo de su blog sobre cómo convertir una hipótesis de Lean UX en una evaluación de IA, añade algo que vale la pena copiar: una línea de falsación, “sabremos que nos equivocamos si [comportamiento observable] no llega a [este nivel] para [esta fecha]”. La escribe primero para no reconstruir la historia después. Así el equipo acuerda antes de construir qué resultado lo haría cambiar de idea. Para más sobre este formato, mira declaración de hipótesis.
Ejemplo ilustrativo de hipótesis falsable: “Creemos que mostrar el costo total desde la primera pantalla reducirá el abandono en el carrito. Sabremos que nos equivocamos si, después de dos semanas con al menos 500 visitas, el abandono no baja más de dos puntos.”
Una advertencia de ese mismo artículo conviene recordarla: una evaluación automática puede indicar si la salida de una función de IA es lo bastante buena para mostrarla a clientes, pero solo los clientes pueden decir si la hipótesis es verdadera y valiosa para ellos. Pasar la evaluación no demuestra que la función logre el resultado de negocio.
¿Cómo se aplica el ciclo?
Una forma práctica de recorrer el ciclo de construir, medir y aprender son cuatro pasos (es una adaptación, no una lista oficial del libro):
- Identificar el supuesto más riesgoso. Qué debe ser cierto para que la idea funcione.
- Construir lo mínimo que lo pruebe. Un boceto, una prueba de concepto, un texto en una landing o una maqueta de flujo.
- Medir con usuarios reales. Entrevistas, pruebas o datos de uso, según la pregunta.
- Aprender y decidir. Seguir, cambiar de dirección o descartar, con la evidencia sobre la mesa.
El paso que más se descuida es el primero. Un equipo que empieza por construir sin identificar el supuesto riesgoso termina con experimentos que no responden nada. Por eso el Lean UX Canvas se centra en identificar los supuestos críticos antes de diseñar.
Para este ciclo, los prototipos de baja fidelidad suelen ser una herramienta útil, porque permiten probar una idea antes de construirla.
Ejemplo
Ejemplo ilustrativo: un equipo de una app de reservas de canchas de fútbol sospecha que los usuarios no completan la reserva porque no saben si la cancha tiene vestidores. Escribe la hipótesis: “Creemos que mostrar los servicios de cada cancha en la tarjeta del listado aumentará las reservas completadas, porque hoy la gente pregunta por esos datos antes de reservar. Sabremos que nos equivocamos si, en dos semanas, la tasa de reserva no sube al menos tres puntos.” Construye una versión con los servicios visibles para la mitad de los usuarios, sin tocar nada más. La medición muestra un aumento y el equipo lo convierte en cambio permanente. Si no hubiera subido, habría descartado la hipótesis y probado otra, sin haber construido el sistema completo de filtros.
Para tu próximo proyecto: escribe una hipótesis con la plantilla y la línea de falsación. Si no puedes escribir la línea de falsación, la hipótesis todavía no es comprobable.
¿Cuándo NO conviene?
- En entornos regulados o con entregables fijados por contrato, como salud, legal o seguros. IxDF advierte que el enfoque no encaja bien en entornos rígidos donde los entregables se fijan por adelantado.
- Cuando la decisión no puede esperar a un experimento, por ejemplo una corrección de seguridad.
- Cuando el equipo no tiene acceso a usuarios reales. Sin ellos, las hipótesis se quedan en opiniones.
- Cuando el experimento no puede medir el resultado. Una hipótesis sin señal observable no se puede aprender.
Errores comunes
- Llamar hipótesis a una funcionalidad. “Agregar un filtro” es una tarea; la hipótesis es el resultado que esperas de ese filtro.
- No definir cómo sabrías que te equivocas.
- Medir vanidad: vistas o clics que no cambian el resultado.
- Experimentar sin cerrar el ciclo. Un experimento sin decisión posterior es solo una prueba.
- Confiar en una herramienta para validar la hipótesis en lugar de hablar con clientes.
- Construir la versión completa antes de probar el supuesto.