Flujos de usuario. El mapa que conecta decisiones y pantallas

Editorial

hace 5 días

6 min de lectura

Flujos de usuario. El mapa que conecta decisiones y pantallas Revista ideas antes del código

Una app puede tener pantallas impecables y estar funcionalmente mal diseñada. El problema comienza cuando nadie ha definido con precisión qué debe ocurrir entre una pantalla y la siguiente.

Diseñar una aplicación pantalla por pantalla produce una sensación inmediata de avance. Aparece el login, después el dashboard, el perfil, el carrito, las configuraciones o cualquier otra sección necesaria. El archivo de diseño comienza a llenarse y el producto parece cada vez más real. Sin embargo, entre esas interfaces existe una capa menos visible y mucho más importante: la lógica que determina cómo se conectan, qué decisiones puede tomar el usuario y cómo debe responder el sistema.

Ahí aparecen los flujos de usuario. No son simplemente flechas entre pantallas. Son mapas que representan los caminos que una persona puede recorrer para alcanzar un objetivo dentro de un producto digital. Permiten visualizar acciones, decisiones, condiciones, respuestas del sistema, errores, rutas alternativas y resultados antes de que esa lógica tenga que convertirse en interfaz y código.

“Una pantalla explica dónde está el usuario. Un flujo explica por qué llegó ahí y qué puede suceder después.”

Puedes escuchar este artículo aquí:

Una app no funciona como una colección de pantallas

Todo producto digital funciona, en realidad, como un sistema de decisiones. Cuando alguien inicia sesión, reserva una habitación, compra un producto, solicita un servicio o modifica su cuenta, el sistema necesita interpretar cada acción y determinar qué ocurre después.

Imaginemos una app para reservar una mesa en un restaurante. El usuario selecciona sucursal, número de personas, fecha y horario. Visualmente podrían ser apenas cuatro o cinco interfaces. Funcionalmente, el escenario es mucho más amplio: ¿qué ocurre si no existe disponibilidad?, ¿se muestran horarios alternativos?, ¿es obligatorio iniciar sesión?, ¿puede continuar como invitado?, ¿qué pasa si la disponibilidad cambia mientras confirma?, ¿la reservación requiere pago?, ¿qué sucede si el pago falla?, ¿hasta cuándo puede cancelar?

Cada una de esas preguntas modifica el recorrido y, potencialmente, el comportamiento del producto.

Cuando esos escenarios no se documentan, no desaparecen. Simplemente se descubren más tarde. Y cuando una excepción se detecta durante desarrollo puede implicar modificar interfaces, lógica de negocio, servicios, bases de datos, integraciones o pruebas que ya habían sido construidas.

Por eso un flujo no sirve únicamente para entender cómo navega alguien por una aplicación. También permite detectar ambigüedad antes de que esa ambigüedad se convierta en retrabajo.

Qué debe documentar un flujo de usuario

Todo flujo comienza con una pregunta sencilla: ¿qué quiere conseguir el usuario? Registrarse, reservar, pagar, publicar, solicitar, consultar, modificar o cancelar algo. A partir de ese objetivo se establecen el punto de entrada, las acciones necesarias, las decisiones del recorrido y el resultado esperado.

Un flujo de compra simplificado podría representarse así:

Inicio → Seleccionar producto → Agregar al carrito → ¿Usuario registrado? → Sí: continuar / No: iniciar sesión o crear cuenta → Seleccionar forma de pago → ¿Pago aprobado? → Sí: confirmar compra / No: mostrar error y permitir reintento.

La estructura parece sencilla, pero obliga a responder preguntas importantes antes de diseñar decenas de interfaces.

Dependiendo de la complejidad del producto, un buen flujo debería dejar claras al menos cinco dimensiones: objetivo del usuario, acciones, puntos de decisión, respuestas del sistema y estados finales. En productos más sofisticados también pueden aparecer permisos, roles, reglas de negocio, procesos automáticos, dependencias externas y excepciones.

Es ahí donde el flujo deja de ser solamente una herramienta de UX y se convierte en una pieza de documentación funcional.

Revista ideas antes del código Flujos de usuario. El mapa que conecta decisiones y pantallas

El camino ideal es solamente una parte del producto

Un error frecuente es documentar únicamente el llamado happy path o ruta ideal: aquella en la que todo funciona correctamente.

El usuario introduce los datos correctos, existe disponibilidad, el servidor responde, la tarjeta es aceptada y la operación termina exitosamente. Ese recorrido es importante porque representa la experiencia deseada, pero un producto real también tiene que saber qué hacer cuando las condiciones cambian.

¿Qué ocurre si la contraseña es incorrecta? ¿Si el usuario no tiene permisos? ¿Si una cuenta ya existe? ¿Si no hay resultados? ¿Si el pago es rechazado? ¿Si un servicio externo deja de responder? ¿Si una operación requiere autorización?

Todas esas situaciones generan estados que deben resolverse.

Algunos necesitarán un mensaje. Otros requerirán una nueva interfaz, una validación, una ruta alternativa, una notificación o incluso una regla adicional de negocio. Si estas condiciones aparecen primero en los flujos, pueden discutirse con producto, diseño y negocio antes de que ingeniería tenga que interpretarlas durante la construcción.

“La complejidad de una app no está en cuántas pantallas tiene, sino en cuántas decisiones debe resolver correctamente.”

User journey, user flow y wireflow no son lo mismo

Aunque suelen aparecer dentro del mismo proceso de diseño, estos documentos responden preguntas diferentes.

El user journey observa la experiencia en un contexto más amplio: necesidades, momentos, canales, expectativas y puntos de contacto que pueden existir antes, durante y después de utilizar un producto digital.

El user flow se concentra en un objetivo específico dentro del sistema y responde: ¿qué acciones y decisiones deben ocurrir para que el usuario llegue de un punto a otro?

La arquitectura de información, por su parte, organiza aquello que el producto debe mostrar: contenidos, categorías, niveles, relaciones y navegación.

Finalmente, cuando un flujo se relaciona directamente con wireframes o interfaces concretas puede convertirse en un wireflow o screen flow. En ese momento ya no solamente muestra la lógica del recorrido, sino también qué interfaz representa cada momento de esa lógica.

La distinción importa porque no deberíamos necesitar una pantalla terminada para descubrir cómo debe funcionar el producto. Primero puede definirse el comportamiento; después se determina cuál es la mejor interfaz para representarlo.

De las decisiones a las reglas de negocio

En un proyecto sencillo, un flujo puede resolverse con unos cuantos nodos, decisiones y conectores. En una plataforma con diferentes tipos de usuarios, permisos o procesos de autorización, la documentación necesita mayor profundidad.

Pensemos en un sistema donde un administrador puede modificar información directamente, un operador solamente consultarla y un cliente puede solicitar un cambio que necesita aprobación.

El recorrido podría ser:

Usuario solicita modificación → Sistema identifica su rol → ¿Tiene permiso para modificar? → Sí: guardar cambio → No: enviar solicitud de aprobación → Responsable revisa → ¿Aprueba? → Sí: actualizar y notificar / No: conservar información y comunicar rechazo.

Detrás de ese flujo existen permisos, estados, notificaciones, validaciones y reglas que posteriormente tendrán que reflejarse tanto en frontend como en backend.

Esta es una de las razones por las que los flujos resultan especialmente valiosos en la documentación funcional. No sustituyen especificaciones, historias de usuario o criterios de aceptación. Les proporcionan un contexto común.

Una regla útil es sencilla: todo aquello que pueda ser interpretado de manera distinta por dos integrantes del equipo merece ser definido.

Puedes ver este artículo aquí:

https://youtu.be/tL69F83KU3I

Diseñar el recorrido cambia las conversaciones

Cuando existe un flujo antes de diseñar las pantallas, las conversaciones del proyecto también cambian. El equipo deja de concentrarse únicamente en botones, colores o acomodos y comienza a discutir comportamiento.

¿Qué necesita conseguir el usuario? ¿Cuál debería ser el camino más directo? ¿Qué información necesita para tomar una decisión? ¿Cuándo interviene una regla de negocio? ¿Qué ocurre si abandona el proceso? ¿Qué excepciones necesitan recuperación? ¿Qué debería resolver automáticamente el sistema?

Estas preguntas son importantes porque una decisión cambiada sobre un diagrama cuesta mucho menos que una decisión descubierta cuando existen decenas de interfaces terminadas o funcionalidad ya desarrollada.

Un flujo también mejora la conversación entre disciplinas. Negocio puede validar que las reglas sean correctas; UX puede evaluar el recorrido; UI puede identificar los estados necesarios; desarrollo puede anticipar condiciones y dependencias; y QA puede comenzar a reconocer escenarios que posteriormente tendrán que probarse.

El objetivo no es producir documentación por producirla. Es construir un lenguaje compartido antes de que cada especialidad comience a interpretar el producto por su cuenta.

Documentar no significa burocratizar

Existe también el riesgo contrario: convertir cada recorrido en un diagrama gigantesco imposible de mantener.

Un flujo no necesita representar absolutamente cada clic ni cada interacción menor. Su nivel de detalle debería responder a una pregunta práctica: ¿qué necesita comprender el equipo para construir esta funcionalidad sin depender de interpretaciones?

Una acción sencilla puede necesitar un flujo pequeño. Procesos críticos como autenticación, checkout, pagos, reservas, permisos o aprobaciones probablemente necesiten diagramas independientes que después se relacionen.

Y, sobre todo, los flujos deben mantenerse vivos. Si cambia una regla de negocio, el flujo debería actualizarse. Si aparece una nueva excepción relevante, debe incorporarse. Una documentación desactualizada deja de reducir incertidumbre y comienza a generarla.

Revista Ideas antes del código infografía Flujos de usuario. El mapa que conecta decisiones y pantallas — Puedes descargar libremente esta infografía.

Antes de diseñar otra pantalla, define qué debe ocurrir

Los flujos de usuario permiten pensar una aplicación como comportamiento y no solamente como interfaz. Hacen visibles decisiones que de otra manera permanecerían ocultas hasta etapas más costosas del proyecto y ayudan a conectar las necesidades del usuario con las reglas del negocio y las condiciones que posteriormente deberá implementar tecnología.

Una interfaz atractiva puede hacer que un producto parezca terminado. Un flujo bien definido ayuda a comprobar si realmente está pensado.

Antes de diseñar la siguiente pantalla de tu producto, vale la pena preguntarlo: ¿tu equipo tiene realmente claras las decisiones, reglas y excepciones que conectan al usuario con el resultado que espera?

¿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.