Por qué la comprobación de hipótesis es el punto de partida equivocado
En mi post reciente sobre el valor de la investigación por descubrimiento en el ahorro de tiempo y dinero toqué pruebas de usabilidad dejar que los equipos diseñen. Pensé que merecía la pena profundizar en cómo se manifiesta en las sesiones y también en la preparación. La palabra "hipótesis" suele aparecer rápidamente en la conversación.
Si no está familiarizado con las pruebas de usabilidad, éstas consisten en que los participantes reclutados en función de su grupo demográfico objetivo intenten realizar tareas con su interfaz, similares a las que intentarían en el mundo real. A través de la observación y la moderación, identificamos los problemas y hacemos recomendaciones de mejora. Todo muy sencillo.
La interfaz que probamos puede ser un sitio web en vivo, aunque suele ser para su optimización, o más comúnmente un prototipo en desarrollo. Los prototipos son muy fáciles de construir hoy en día en comparación con los wireframes que eran comunes en el año 2000. Con algunas de las herramientas disponibles y un equipo de diseñadores con talento se puede desarrollar un prototipo que se vea y se comporte como el real.
Donde entra en juego la "hipótesis" es en el origen del prototipo. Debido a que son relativamente fáciles de construir, cada vez veo más prototipos para pruebas de usabilidad que se construyen enteramente como resultado de las actividades de lluvia de ideas de un equipo. He aquí un rápido resumen de ese proceso:
- Se genera la idea de la propuesta
- Lluvia de ideas en equipo sobre cómo debería evolucionar esa idea hasta convertirse en un diseño
- Se construye el prototipo
- Se realizan pruebas de usabilidad
A grandes rasgos, esta es la forma en que equipos ágiles trabajo: desarrollar el MVP (producto mínimo viable), probarlo, fallar rápidamente y volver a empezar. Pero si no se ha configurado de forma ágil, este enfoque es defectuoso. Por supuesto, los clientes participan, pero demasiado tarde en el proceso.
La hipótesis debe ser investigada
Los prototipos deben probarse. Las hipótesis deben investigarse, no probarse. Si necesita que le convenzan, mire el Marco del Doble Diamante de los Consejos de Diseño. La primera etapa es "Descubrir", que definen como:
El primer diamante ayuda a la gente a entender, en lugar de simplemente suponer, cuál es el problema. Implica hablar y pasar tiempo con las personas afectadas por los problemas".
Se podría argumentar que probar las hipótesis está bien porque el equipo puede tener una mentalidad abierta sobre el resultado y volver atrás si es necesario. Pero, aunque así sea, seguramente es una pérdida de tiempo y dinero.
También he oído decir a gente que necesitaba el prototipo para mostrar al cliente cuáles son sus ideas. Eso es perder el punto de la investigación de descubrimiento, que es definir el espacio del problema que las ideas abordan. La definición de la experiencia viene después.
Si quieres aprovechar al máximo tu presupuesto y tu tiempo, y crear productos digitales diferenciados que ofrezcan una excelente experiencia de usuario, tienes que involucrar a tus clientes desde el principio y durante todo el proceso. Incorporarlos tarde para poner a prueba tu hipótesis suele dar lugar a un producto/servicio deficiente o a un proceso más largo y costoso.
Si quiere saber más sobre la investigación de sus ideas, póngase en contacto con +44(0)800 0246247 o envíenos un correo electrónico a hello@ux247.com.
