Qué es un user journey y cuándo necesitas uno


Diseñar una buena experiencia digital no empieza preguntando qué pantallas necesita una app. Empieza entendiendo qué intenta conseguir una persona, qué ocurre antes de abrir el producto, qué obstáculos encuentra durante el proceso y qué espera que suceda después. Ahí es donde un user journey empieza a tener sentido.
En UX hablamos constantemente de usuarios, flujos, pantallas, funcionalidades y puntos de contacto. El problema aparece cuando comenzamos a diseñar cada una de esas piezas de manera aislada. Una aplicación puede ser técnicamente correcta, tener una navegación aparentemente sencilla y una interfaz visualmente atractiva y, aun así, ofrecer una experiencia frustrante porque nadie observó el recorrido completo que realiza la persona para resolver una necesidad. Ese recorrido es el user journey. Cuando lo documentamos visualmente mediante etapas, acciones, pensamientos, emociones, necesidades, puntos de contacto y fricciones, hablamos de un user journey map. La diferencia puede parecer menor, pero es importante: el journey es la experiencia; el mapa es la herramienta que utilizamos para entenderla.
“Un user journey no dibuja pantallas: revela lo que el usuario necesita resolver antes, durante y después de usar el producto.”
Puedes escuchar este artículo aquí:
El recorrido empieza antes de la interfaz
Imaginemos una aplicación para reservar una consulta médica. Desde la perspectiva del producto, podríamos pensar que el recorrido comienza cuando el usuario abre la app, selecciona una especialidad, elige un médico y confirma un horario. Desde la perspectiva de la persona, probablemente comenzó mucho antes: siente un malestar, busca información, pregunta a alguien, revisa qué médicos cubre su seguro, compara alternativas y después encuentra la aplicación. Durante el registro descubre que necesita su número de póliza, abandona momentáneamente el proceso, regresa, encuentra un horario y finalmente agenda. Después todavía debe recibir la confirmación, recordar la cita, llegar al lugar correcto, presentar documentos, realizar el pago y quizá consultar posteriormente resultados o indicaciones. La aplicación participa únicamente en algunos momentos de una experiencia mucho más amplia.
Esta forma de observar el problema permite detectar algo que una pantalla aislada difícilmente mostraría: muchas fricciones relevantes ocurren entre sistemas, canales, personas y procesos. Por eso, comprender el viaje completo ayuda a descubrir problemas que no necesariamente se solucionan diseñando una nueva interfaz. A veces la respuesta está en una notificación, en un proceso operativo, en información que debería aparecer antes o en la integración entre dos sistemas.

User journey y user flow no son lo mismo
La confusión entre ambos conceptos es común porque los dos representan recorridos, pero responden preguntas diferentes. El user journey intenta comprender la experiencia completa de una persona alrededor de un objetivo: qué necesita, qué hace, qué piensa, dónde interactúa con una organización y dónde aparecen las dificultades. El user flow, en cambio, representa los pasos y decisiones que realiza dentro de una interfaz para completar una tarea.
Volvamos al ejemplo médico. El journey podría abarcar desde el momento en que una persona identifica que necesita atención hasta que recibe seguimiento después de su consulta. El flow podría representar únicamente: Inicio de sesión → Buscar especialista → Consultar perfil → Seleccionar horario → Confirmar datos → Realizar pago → Confirmación. Ambos son útiles, pero operan en niveles distintos. Cuando todavía existe incertidumbre sobre el problema, primero conviene comprender el recorrido; una vez identificado qué parte debe resolver el producto, entonces podemos diseñar los flows necesarios para convertir esa solución en interacción.
¿Cuándo necesitas realmente un user journey?
La respuesta corta es: cuando existe incertidumbre sobre la experiencia completa que estás intentando resolver. No todos los proyectos necesitan desarrollar un journey extenso y hacerlo simplemente porque aparece dentro de una metodología UX puede terminar generando documentación que nadie volverá a utilizar.
Tiene especial valor cuando diferentes áreas de una empresa explican de manera distinta cómo funciona un proceso; cuando una experiencia combina una app con correo electrónico, WhatsApp, llamadas, sucursales físicas o intervención de personal; cuando existen abandonos y nadie entiende con precisión por qué; o cuando estás por diseñar una funcionalidad importante sin comprender todavía el contexto en el que será utilizada.
También puede evitar inversiones innecesarias. Un journey podría revelar que un problema que aparentemente requiere una nueva pantalla puede resolverse modificando una notificación, automatizando una tarea interna, proporcionando información antes del registro o conectando correctamente dos sistemas existentes. Ahí aparece su verdadero valor estratégico: no sirve solamente para encontrar problemas de usabilidad, sino para descubrir dónde debería intervenir realmente el producto digital.
“Si el equipo sólo entiende lo que ocurre dentro de la app, probablemente todavía no entiende el problema completo.”
Puedes ver este artículo aquí:
Un journey también revela expectativas
Una experiencia digital no se evalúa únicamente por el número de pasos necesarios para completar una tarea. El mismo proceso puede sentirse completamente diferente dependiendo del contexto. Pagar una suscripción de entretenimiento y realizar una transferencia bancaria podrían requerir un número similar de interacciones, pero la carga emocional no es la misma. En una transferencia existen preocupaciones relacionadas con el monto, el destinatario, la seguridad y la confirmación de que la operación realmente ocurrió.
Por eso un journey puede incorporar qué piensa una persona, qué dudas aparecen, qué nivel de confianza necesita y qué momentos generan incertidumbre. Pero debe hacerlo alrededor de un usuario, un escenario y un objetivo específicos. Un mapa demasiado general puede terminar describiendo prácticamente cualquier experiencia y dejar de ser útil. El objetivo no es documentarlo todo, sino identificar aquello que ayuda a tomar mejores decisiones.
El journey debe terminar en decisiones
Un mapa lleno de notas adhesivas puede verse impresionante durante un workshop y no cambiar absolutamente nada en el producto. Por eso el entregable nunca debería ser el objetivo. Después de construir el recorrido hay que identificar dónde están las mayores fricciones, cuáles afectan directamente el objetivo del usuario, qué momentos dependen del producto digital, cuáles pertenecen a procesos internos y cuáles representan oportunidades reales de diseño.
A partir de ahí pueden aparecer decisiones concretas: eliminar pasos, modificar procesos, cambiar el momento en que solicitamos información, crear una funcionalidad, conectar sistemas, introducir automatizaciones, replantear un onboarding o descubrir que una característica que parecía indispensable realmente no lo es. Cuando ocurre eso, el journey deja de ser documentación UX y se convierte en una herramienta para tomar decisiones de producto.

Antes de diseñar pantallas, entiende el viaje
En proyectos digitales existe una tentación permanente por avanzar rápidamente hacia lo visible. Wireframes, interfaces y prototipos producen la sensación de que el producto ya está tomando forma, pero una interfaz puede materializar con enorme precisión una solución equivocada.
Un user journey ayuda a ordenar esas decisiones antes de convertirlas en interfaces. Permite responder primero qué está intentando lograr realmente una persona, dónde aparecen las fricciones y qué tendría que ocurrir para que pueda alcanzar su objetivo de manera más sencilla. Una vez entendido ese recorrido, resulta mucho más fácil decidir dónde debe participar la tecnología, qué funcionalidades tienen sentido, qué flows hay que diseñar y cuáles pantallas son realmente necesarias.
¿En tu producto estás diseñando el recorrido que necesita el usuario o únicamente las pantallas que necesita el sistema?
¿Tu idea necesita más claridad antes de convertirse en código? En Sr. Zorro App Design Studio te ayudamos a definir, validar y diseñar productos digitales listos para desarrollo. Conoce más en www.srzorro.com.
Escrito por: Editorial
Fuentes
Nielsen Norman Group — Journey Mapping 101Definición, componentes y usos del journey mapping.https://www.nngroup.com/articles/journey-mapping-101/
GOV.UK Service Manual — Map and understand a user's whole problemEnfoque para comprender el recorrido completo del usuario más allá de una transacción digital.https://www.gov.uk/service-manual/design/map-a-users-whole-problem
GOV.UK Service Manual — Researching user experiencesInvestigación de acciones, pensamientos y emociones a lo largo de una experiencia.https://www.gov.uk/service-manual/user-research/researching-user-experiences
Figma — ¿Qué es un flujo de usuario?Conceptos y diferencias entre flujos, journeys, wireframes y otros artefactos UX.https://www.figma.com/es-la/resource-library/flujo-de-usuarios/
Atlassian Team Playbook — Customer Journey MappingCriterios para definir alcance, persona, escenario, acciones, necesidades y puntos de dolor.https://www.atlassian.com/team-playbook/plays/customer-journey-mapping




Comentarios