Table of Contents
¡Hola a todos!
Este artículo se basa en el escenario presentado en nuestro artículo ‘División de historias de usuarios‘. Si aún no has tenido la oportunidad de echarle un vistazo, te animamos a que lo hagas antes de continuar con la lectura de este artículo. Sólo queremos asegurarnos de que no se pierda el contexto, pero, sólo como un resumen rápido…
- …trabajamos en el departamento de productos de una empresa llamada ‘Frame Store’. Vendemos marcos …
- … lo que solíamos recibir de nuestra gente de negocios es una gran idea, inspiradora ( ¡a veces no 100% realista y racional! ) de una característica muy bonita y genial …
Y… estos son los supuestos que nos gustaría validar:
- Si los usuarios pueden personalizar su menú, podrán encontrar las opciones fácilmente, mejorando el rendimiento y la satisfacción.
- Si los usuarios pueden buscar las opciones del menú, podrán encontrarlas fácilmente, lo que mejorará el rendimiento y la satisfacción.
Validando estas hipótesis buscamos reducir el riesgo de fracaso y estar seguros de que estamos dando un valor real al usuario.
Pasemos a los siguientes apartados donde descubrirás con más detalle cómo puedes reducir los riesgos, esto es ‘tan sencillo como’ seguir una validación basada en hipótesis o, lo que es lo mismo, trabajar sobre la hipótesis (con datos empíricos) antes de tomar cualquier decisión y seguir adelante.
Identifica tus suposiciones
Para nuestro ejemplo, tenemos los siguientes supuestos:
- Si los usuarios pueden personalizar su menú, podrán encontrar las opciones fácilmente, mejorando el rendimiento y la satisfacción.
- Si los usuarios pueden buscar las opciones del menú, podrán encontrarlas fácilmente, lo que mejorará el rendimiento y la satisfacción.
Tenemos que hacernos algunas preguntas para estar seguros de que son factibles, deseables y viables.
Algunos ejemplos de estas preguntas podrían ser…
- ¿Nos enfrentamos a algunos retos tecnológicos que podrían hacer que estas hipótesis no fueran realistas?
- ¿Intentamos resolver un problema real de nuestros usuarios?
- ¿Tiene sentido que nuestra empresa mejore esa parte del proceso ahora mismo?
Con estas 3 preguntas podemos tener una idea de muy alto nivel si nuestra hipótesis es factible, deseable y viable. Podríamos iterar más en cada una de ellas, tratando de profundizar en alguna de estas características. Esto es sólo un buen punto de partida.
Reformular los supuestos como «hipótesis»
Este paso podría parecer innecesario, pero en realidad es necesario para cambiar la forma en que visionamos las ideas en nuestra mente (y cómo las compartimos con los demás).
Las suposiciones son algo que damos por sentado, es lo que es. Por otro lado, las hipótesis son como una suposición tentativa. Implícitamente estamos diciendo que no tenemos pruebas de la certeza de la hipótesis.
- Creemos que, si los usuarios pueden personalizar su menú, podrán encontrarlos fácilmente, mejorando el rendimiento y la satisfacción.
- Creemos que, si los usuarios pueden buscar opciones de menú, podrán encontrarlas fácilmente, mejorando el rendimiento y la satisfacción.
Un buen ejercicio aquí es también la creación de «hipótesis nulas», como:
- Creemos que, si los usuarios pueden personalizar su menú, podrán encontrar las opciones de la misma forma que antes, no mejorando el rendimiento ni la satisfacción.
- Creemos que, si los usuarios pueden buscar opciones en el menú, podrán encontrar las opciones de la misma forma que antes, lo que no mejora el rendimiento ni la satisfacción.
Estos son los que queremos demostrar que son falsos.
Clasifíquelos por orden de importancia
Un buen consejo para priorizar las hipótesis es evaluar qué podría pasar si esa hipótesis se demuestra falsa. En otras palabras, cuál es el coste del retraso (un concepto que algunos de ustedes ya conocen de la metodología Safe).
¿Cuál sería el impacto para nuestra aplicación, o incluso a un nivel más alto, para nuestra empresa?
Diseñar las pruebas adecuadas
Como buen consejo yo diría ‘probar primero lo que tiene más riesgo‘. Esto podría aplicarse a cualquier cosa, no empecemos por lo más fácil sólo para darnos cuenta de que lo más complejo es imposible de conseguir. Descartémoslo cuanto antes.
Si no sabemos cómo hacer volar un avión… ¿por qué deberíamos empezar a construir los asientos para los pasajeros? No tiene sentido
Existen múltiples formas de realizar una prueba sobre la hipótesis (cualitativa y cuantitativa)… vamos a repasar algunas de ellas:
Tests A/B
Implementar un producto mínimo de valor con las hipótesis que necesitamos validar. No necesitamos tener implementada toda la funcionalidad, solo las características más importantes.
Si queremos validar nuestra hipótesis ‘Creemos que, si los usuarios pueden buscar las opciones del menú, podrán encontrarlas fácilmente, mejorando el rendimiento y la satisfacción‘, implementemos un campo de búsqueda, pero eso es todo, nada más, nada del otro mundo.
Liberémoslo a la mitad de nuestros usuarios y veamos cómo va. No invirtamos mucho tiempo en algo que quizás nadie quiera. Una vez que comprobemos que a nuestros usuarios les gusta y les aporta valor, ¡trabajaremos para mejorarlo!
Fake door
Esto requerirá incluso menos implementación que la prueba AB de la función PERO podría generar más frustración a nuestros usuarios. Para validar nuestra hipótesis vamos a…
- Añadir el campo de búsqueda a nuestra página de destino
- Dejar que los usuarios escriban la información que necesitan buscar
- No realice ninguna búsqueda, el portal podría mostrar un mensaje como «Lo sentimos, esta función aún no está disponible, estamos trabajando en ella».
- Envía a nuestro sistema de análisis cuántas personas utilizan realmente la función.
Como he dicho antes, creo que este tipo de comunicación debe manejarse adecuadamente para reducir la frustración de los usuarios (algunas empresas utilizan mensajes como «lo siento, esta función aún no está disponible en su país»… una especie de mentira piadosa pero que podría ser menos perjudicial).
Este proceso de validación podría ejecutarse dentro de una prueba AB, simplemente sustituyendo la implementación del MVP por esta Puerta del Destino.
Encuestas
Preguntemos a nuestros usuarios y veamos cuál es el resultado. Lo importante aquí es no hacer preguntas directas en las que estemos llevando a los usuarios a la respuesta que esperamos sea la correcta.
Preguntemos a nuestros usuarios y veamos cuál es el resultado. Lo importante aquí es no hacer preguntas directas en las que estemos conduciendo a los usuarios a la respuesta que esperamos sea la correcta.Durante todos estos años, he escuchado como cien veces «¡recuerda el Walkman amarillo!» … ¡cómo olvidarlo! Ese ejemplo nos enseña lo que no tenemos que preguntar pero, el verdadero valor está en ‘qué tenemos que preguntar’. Me llevó varios días encontrar unas pocas preguntas que no interfirieran.
Como consejo, intente formular las siguientes preguntas:
- ¿Crees que …
- ¿Cómo te sientes cuando…
Intenta evitar las respuestas de sí/no. Siempre prefiero ir con una escala de «menos probable» a «muy probable» o similar.
Hay que tener en cuenta que nuestro producto debe ser diseñado e implementado teniendo en cuenta la validación de hipótesis desde el primer día. No podemos retrasar la integración de un marco de pruebas AB hasta la última de nuestras implementaciones, ¡hay que priorizarlo!
Realización de las pruebas
¡Vamos a hacerlo! ( pero ¡paso a paso! )
Puedes utilizar herramientas como Firebase para realizar tu AB. Colocamos allí la segmentación de tus usuarios que quieres trasladar al test y esperamos a que los datos que recibes sean lo suficientemente significativos (algunas herramientas como Firebase lo dicen por sí mismas).
¿Cuánto tiempo tardarás? Depende del tráfico que tenga en esa parte del portal/aplicación. Los cambios en la página de aterrizaje le darán datos significativos antes que los cambios en alguna página detallada, como los perfiles de los usuarios o cualquier otra con menos tráfico.
En cuanto a las encuestas, elige bien a tus candidatos para tener una representación realista de tus usuarios. Imagina que más del 75% de nuestros usuarios en el portal de Frame Store son personas mayores de 50 años. Nuestros candidatos deben representar esta distribución, así que no elijas muchos candidatos de 20-30 años.
Sintetizar lo aprendido
En esta fase de la validación de la hipótesis debemos tener la mente abierta. Puede que se demuestre que la hipótesis es falsa. Esto nunca debe considerarse un error, es un éxito. Hemos podido ahorrar tiempo y dinero a la empresa dejando de perseguir algo que no tiene valor.
Muchas empresas fracasaron porque no pudieron validar las hipótesis, pero no sólo eso. Vi casos en los que, después de diseñar y realizar la prueba adecuada, fracasaron al leer los resultados. ¿Cómo puede ser eso posible? eso es simplemente porque la gente está demasiado comprometida con la hipótesis que no acepta que se pueda demostrar que es falsa. La gente vendió la idea a la alta dirección antes de demostrar que era correcta y ahora,… ‘¡Vaya… no puedo volver atrás y decirles que lo que pensaba no era cierto, que estaba equivocado! Este es un gran error, el mayor que podemos cometer en este momento. Gastamos tiempo y dinero en validar una hipótesis y ahora, ¡vamos a gastar tiempo en implementarla aunque no le sirva a nadie! Una locura…
Ten la mente abierta, cambia tu pensamiento a «Vaya… por suerte hemos demostrado que nuestra suposición era falsa antes de seguir adelante con ella. Ahora sabemos más sobre las necesidades de nuestros usuarios y podemos formular nuevas hipótesis«. Nadie ha fallado.
Actúa
Implementar con la certeza de dar valor a tus usuarios es la mejor sensación de la historia! les escuchas y trabajas con el equipo ( UX, desarrolladores, QAs,… ) para hacer realidad las ideas!
¡Hay una pequeña posibilidad de fracaso (¡será casi imposible reducir el riesgo a 0!) pero nada si lo comparas con los cambios de fracaso cuando pones a tu equipo a trabajar implementando un supuesto que no has validado!
Conclusiones
Espero que este artículo le dé algunas pistas para mejorar su proceso de validación de hipótesis. Nuestro consejo… valida, valida y… ¡itera!
Te deseamos todo lo mejor en este largo pero muy satisfactorio proceso.