Diseño orientado a hipótesis

Qué es realmente una hipótesis

Una hipótesis de diseño es un supuesto que alguien del equipo cree que es verdad. El founder, el PM, el IC más senior o la persona recién incorporada que acaba de hacer shadowing a cinco usuarios. Da igual quién la escriba. Lo que importa es si la has puesto bajo un test que conecta con algo medible.

El sentido de escribirla es hacer la creencia comprobable. Después de eso, puedes averiguar si entiendes de verdad a tus usuarios o si has estado proyectándote a ti mismo.

Cada test que vuelve con una respuesta (confirmando o refutando) abre el siguiente conjunto de preguntas. Ese es el bucle. La única disciplina es basar cada hipótesis en algo que hayas visto, en el comportamiento del usuario o en los datos, y no en lo que te gustaría que fuera verdad.

Mejor colaboración, menos documentación

El diseño orientado a hipótesis cambió cómo los equipos con los que trabajé llegaban al curro. Cualquiera podía proponer una hipótesis. Cualquiera podía rebatir la de otro. El PM, el ingeniero, la diseñadora visual, el responsable de QA, todos en la misma sala con el mismo formato de afirmación en la pared.

Cuando el formato es corto y compartido, la conversación va sobre evidencia, no sobre quién tiene derecho a opinar. Solo eso ya reduce la cantidad de documentación interna que necesita un equipo. No escribes un brief de quince páginas para alinearte sobre una funcionalidad. Escribes cuatro líneas, acordáis la métrica y lanzáis un test.

Cómo escribir tu hipótesis

Cuatro líneas. Siempre la misma forma:

Creemos que… [el supuesto]

Para… [la persona o segmento]

Vamos a… [el cambio en el comportamiento del usuario por el que apostamos]

Sabremos que es cierto cuando… [la métrica]

Cuando rediseñamos el prompt de notificaciones de iOS en Fretello, el objetivo era subir la tasa de opt-in para que los principiantes mantuvieran de verdad una rutina. La hipótesis salió así:

Creemos que al exponer la propuesta de valor de los recordatorios,

para guitarristas principiantes,

vamos a ayudarles a construir la rutina de práctica que necesitan para tener éxito aprendiendo,

sabremos que es cierto cuando la tasa de opt-in a notificaciones haya aumentado un X%.

Eso es todo. Cuatro líneas en la pared. Ahora podemos discutir cada línea por separado (¿es la persona correcta? ¿es X% el listón adecuado? ¿“propuesta de valor” significa lo que creemos que significa?) y los desacuerdos se quedan en lo concreto en lugar de volverse filosóficos.

Validar tu hipótesis

Elige el método de validación antes de lanzar nada. Lo cuantitativo (A/B, deltas de opt-in, curvas de retención) te dice qué cambió. Lo cualitativo (entrevistas, walkthroughs, ver a alguien delante de la pantalla) te dice por qué.

Decídelo de antemano. Si no, el equipo redefinirá en silencio el “éxito” en cuanto lleguen los resultados. Lo he visto pasar con hipótesis que escribí yo mismo. La forma de evitarlo es cerrar la métrica y el umbral en la misma conversación en la que cierras la hipótesis.

Después de medir, pueden pasar tres cosas:

• La hipótesis era correcta. Lanza el cambio. La siguiente hipótesis suele escribirse sola: si los recordatorios funcionan para principiantes, ¿también funcionan para los intermedios? ¿Con qué frecuencia?
• La hipótesis era incorrecta. La parte interesante. Ahora sabes una cosa concreta que no es cierta, lo cual vale más que otra opinión.
• El resultado fue ambiguo. Aprieta el experimento, o admite que la pregunta no estaba lo bastante afilada de entrada.

De cualquier forma, el bucle continúa.

Por qué vuelvo siempre a esto

Lo que me gusta del diseño orientado a hipótesis es que hace que un equipo discuta bien. Las discusiones sobre una hipótesis son productivas: alguien tiene evidencia, alguien tiene una teoría distinta, el experimento desempata. Las discusiones sobre features tienden a ser improductivas: alguien tiene una opinión, alguien tiene otra opinión, gana quien grita más fuerte.

He usado este bucle en Fretello, en SellerCrowd y en proyectos más pequeños por el medio. Es portátil. Funciona tanto con una pareja diseñador-PM como con un pod multidisciplinar. La parte más difícil es la disciplina de no saltarse la línea de la métrica porque todo el mundo “ya está de acuerdo”.