Caminando por el “Happy Path” y el que no es tan “happy”
Tienes hambre, pero pese a que tienes ingredientes suficientes en la despensa y en la nevera, te da pereza cocinar.
Alargas tu brazo para coger el móvil. Abres tu aplicación de comida a domicilio preferida, buscas tu restaurante de sushi favorito, añades platos a la cesta, pagas, esperas un rato y ya tienes la cena lista.
Esto que he descrito arriba es el happy path (o camino feliz). En este artículo aprenderás qué es, cómo se trabaja y qué hacer con “los otros casos”.
¡Vamos allá!
Qué es el “happy path”
El happy path es el camino ideal que siguen tus usuarios/as. Es el camino más corto, el que no tiene fallos técnicos ni errores humanos. Es el camino que permite que quien utilice esa aplicación pueda conseguir su objetivo de forma rápida, precisa y efectiva.
El mundo ideal, vaya.
Es el camino por el que, consciente o inconscientemente, empezamos a plantear y a diseñar cuando empezamos un proyecto.
En el caso de la comida a domicilio que te describía al principio, el diagrama de flujo sería algo así:
El «camino feliz» al pedir sushi: todo sale bien… pero no siempre es así.
Pero en el mundo real™ no todo funciona a la perfección todo el rato. Si has diseñado varios productos o servicios digitales, ya habrás aprendido que los modelos mentales y el contexto de cada persona hacen que lleguen por caminos diferentes al objetivo deseado.
Empieza con el happy path
El “camino feliz” va muy bien para empezar a trabajar. Es el camino a partir del cual se empiezan a dibujar las ramificaciones.
Siguiendo con el ejemplo anterior:
- ¿Qué pasa si el restaurante no está disponible? → habrá que facilitarle al usuario que pueda buscar otro
- ¿Y si no está disponible el combinado de sushi que quiere? → habrá que recomendar otro similar
- ¿Cómo lo hago para pagar si no tengo tarjeta de débito? → probablemente habrá que pensar e implementar otros métodos de pago, como el pago al contado
- ¿Y si el TPV de quien reparte no funciona? ¿cómo lo hacemos para que el restaurante cobre por el pedido que ya ha enviado?
- ¿Qué pasa si el repartidor no llega? → será necesario tener un buen equipo de atención al cliente para gestionar las dudas y los problemas que puedan surgir
- ¿Y si el combinado que llega no es el que ha pedido? → se necesitará un sistema para hacer reclamaciones, gestionar disputas y solucionar el problema
Todo esto, y decenas de preguntas más, generará otros diagramas de flujo que se enlazarán unos con otros. Sería recomendable hacer también ejercicios de user journey, jobs to be done y arquitectura de la información, por ejemplo.
Los riesgos del camino feliz
Pensar en el happy path puede inducir sesgos.
Puede provocar que no se tenga en cuenta la accesibilidad (“porque solo afectan a un pequeño porcentaje de usuarios”), que se genere deuda técnica o de diseño que “ya se arreglará” (spoiler: no suele pasar) o que se dejen de lado las buenas prácticas en general (“hazlo rápido, que queremos lanzarlo ya” o “no hace falta hacer investigación”).
Está en tu mano tener esto en mente y saber explicarlo y defenderlo.
Hablemos del unhappy path
Según la Wikipedia, todavía no existe un acuerdo sobre cómo llamar a aquellos caminos que son opuestos al happy path. Parece que está ganando la partida unhappy path, porque es el antónimo de happy (feliz).
Estos casos son los que terminan abruptamente. Son aquellas situaciones en las que alguien termina su “camino” por nuestro producto digital antes de haber podido alcanzar el objetivo que tenía en mente.
Puede ser que haya intentado recuperar la contraseña y no haya recibido el correo electrónico de recuperación, que no pueda añadir platos a su cesta o que el sistema de pago no funcione adecuadamente.
Es aquí cuando se producen los edge cases o casos extremos: son esas situaciones que impactan a un número relativo de usuarios, dispositivos o que solo pueden reproducirse bajo circunstancias muy específicas:
- Un bug que solo impacta a los dispositivos de Android
- Un desvío poco común del happy path que lleva a los usuarios a una pantalla de la que no pueden salir
- Que alguien utilice algún símbolo extraño al escoger su contraseña y esto rompa algo de la base de datos
Apuntes finales
Diseñar productos digitales no es fácil. Siempre hay que tener en cuenta multitud de situaciones y posibilidades que podrían suceder.
Si consideramos el principio de Pareto, el happy path requiere el 20% del trabajo y produce el 80% de los resultados. Es en este momento cuando muchos equipos piensan que ya han terminado, pero lo cierto es que todavía falta hacer el 80% del tiempo 😏
Por ejemplo:
- Refinar la parte visual
- Identificar errores y arreglarlos
- Optimizar el flujo principal y los secundarios
- Y un largo etcétera
Al fin y al cabo, el objetivo es que las personas que piden comida quieran utilizar nuestra aplicación y que no se vayan a la competencia 🫣