Lean UX: cómo escribir buenas hipótesis
Si trabajas con Scrum, Lean UX, Design Sprints o marcos de trabajo similares, te resultará familiar escribir y validar hipótesis como parte de tu flujo de trabajo. En ese contexto, la formulación de buenas hipótesis se vuelve fundamental, pues gran parte del trabajo depende de actividades que iteran sobre éstas.
Como esta parte del conocimiento se asentó en nosotros hace muchos años atrás (método científico, durante los primeros años de colegio seguramente), les quiero compartir algunas recomendaciones que nos ayuden a refrescar la memoria y mejorar nuestro actual trabajo con hipótesis.
Aviso: el artículo representa un rescate de prácticas donde algunas vienen desde lo teórico y otras vienen desde los proyectos, de la calle, de ponernos rojos y joderla en la vida real. No es exhaustivo, ni una verdad absoluta. Si así y todo te sirve, maravilloso.
El método científico nos dice que la hipótesis es una suposición de algo posible o imposible para sacar de ello una o más consecuencias. Esta idea es de alto valor en la medida que reconocemos que su aporte tiene que ver con la capacidad de establecer relación entre los hechos y permitir entender el por qué se producen.
El nivel de veracidad que se otorga a una hipótesis dependerá de los datos empíricos que apoyan lo afirmado en la misma. Esto corresponde al proceso de validación de la hipótesis, principal responsable de traer de vuelta este concepto a nuestro trabajo con frameworks ágiles.
Cuando nos leímos el hitazo de Jeff Gothelf se nos aclara la película respecto a lo que busca Lean UX:
“En vez de construir algo que asumes que debe funcionar, creas una hipótesis de algo que podría funcionar, luego creas la forma más rápida para validar o invalidar lo anterior”
Esta forma de enfrentar un proceso de investigación y/o diseño de experiencia, recupera un principio que viene promovido por Lean: maximiza el valor y minimiza la basura.
En vez de darle para adelante con todo “porque al equipo se le ocurrió”, “porque siempre lo hemos hecho así” o “porque mi jefe me lo pidió” (válido en algunos equipos), se avanzará con experimentos que pongan a prueba nuestras hipótesis. El resultado de estos experimentos dará entonces información sabrosa que permita construir buenos productos o servicios… siempre y cuando hayamos planteado buenos experimentos que validen o invaliden buenas hipótesis.
Back to the basics.
Si revisamos las características más básicas de las hipótesis encontraremos una muy buena referencia para bajar la probabilidad de meter la pata:
Carácter afirmativo
Las hipótesis deben plantearse con un carácter afirmativo. No se formulan como pregunta, ni tampoco resulta práctico establecerlas como una negación.
Precisa
Una hipótesis debe ser clara y precisa, tan clara que no permita ambigüedades.
Específica
Debe ser formulada para un problema particular y específico. Si nuestra hipótesis cuenta con generalizaciones, será muy difícil lograr buenas conclusiones.
Relevante al problema
Una hipótesis es una guía para la identificación y eventual solución del problema, por lo tanto, debe guardar plena relación con el problema que estemos abordando.
Consistencia y armonía
Nuestra hipótesis y las variables que la componen deben estar libres de conflictos y contradicciones entre ellas.
Testeable
Una buena hipótesis debe permitir que sea probada empíricamente. Lejos la característica más importante en el trabajo con experiencia de usuario.
Algunos ejemplos
Hipótesis: Al final del flujo de pago, los usuarios como Felipe Domínguez (arquetipo definido por el equipo) confunden la etiqueta “cancelar” con “pagar”.
Experimento: Probar el flujo de pago con 10 usuarios del mismo arquetipo, 5 usarán una interfaz con la etiqueta Cancelar, y otros 5 usarán la interfaz con la etiqueta Rechazar.
Hipótesis: Los usuarios que llegan al homepage desde la red display (dando click a un banner) rebotan más que los que llegan de forma orgánica.
Experimento: Usando Google Analytics comparamos el comportamiento de usuarios cuya fuente de origen es Organic y otros que sean Display, mediante la métrica Bounce Rate.
¿Testeando hipótesis?
Así como agile sirve de guía para movernos con facilidad entre columnas del kanban, pero no nos ayudará a poner LA historia correcta en cada columna; la experimentación nos ayuda a refutar o validar hipótesis, pero antes debemos asegurarnos de haber creado experimentos basados en buenas hipótesis.
Testear las hipótesis, o al menos revisar éste u otro checklist, cuando eso nos puede ahorrar buenas horas de trabajo en caminos perdidos, no suena como una idea tan loca.
Si bien está orientado más hacia la validación de hipótesis de negocio, el Validation Board creado por Lean Startup Machine puede servir de inspiración para tu proceso de trabajar con hipótesis.
En general, la elaboración de una buena hipótesis tiene como punto de partida el conocimiento del área en el que se desea hacer la investigación.
Esto en investigación científica es un principio bastante radical, pues se busca evitar recorrer caminos ya transitados, sin embargo, en desarrollo de proyectos digitales no es un mal ejercicio, es más, hay autores que recomiendan desaprender para comenzar más limpios.
Si bien sacar a colación las hipótesis y la experimentación puede llegar a revivir nuestros mayores miedos de infancia, lo cierto es que en la práctica no es nada del otro mundo. En la medida que los equipos logran colaborar en el correcto planteamiento de las ideas, y sueltan la mano respecto a su forma de probarlas, los productos quedan más ricos y el trabajo se vuelve un placer… o al menos esa es mi hipótesis :)
