Diseño de user flows complejos: metodologías (toma de requerimientos)

Los user flows complejos casi nunca fallan en la fase de diseño. Fallan antes, cuando los requerimientos se toman a medias y nadie lo nota hasta que el flujo llega a desarrollo. Esta es la metodología que usamos en el estudio para evitarlo.

Respuesta rápida: cómo se diseñan user flows complejos

Para diseñar user flows complejos hay que tomar requerimientos antes de dibujar una sola pantalla. Lo hacemos en cinco pasos: definir el objetivo del flujo, entrevistar a quienes lo usan y lo sostienen, inventariar reglas y excepciones, convertir todo en escenarios de uso y validar el mapa del flujo con negocio y desarrollo antes de pasar a la interfaz.

La razón es simple. Un flujo complejo tiene varios actores, decisiones condicionales y caminos alternativos, y cada uno esconde un requerimiento que alguien conoce y nadie ha escrito. Si lo descubres mientras diseñas pantallas, tienes que rehacer. Si lo descubres durante la toma de requerimientos, solo tienes que anotarlo.

Nuestra opinión es clara: el diagrama del flujo es un entregable de investigación, no un entregable visual. Lo construyes con evidencia, lo discutes con el equipo y solo cuando todos lo entienden empiezas con la interfaz. En 2026, con herramientas de IA que generan pantallas en minutos, esta disciplina importa más que nunca: generar pantallas es fácil, acertar con el flujo no.

Qué define los user flow complejos

Un flujo es complejo cuando se cumple al menos una de estas condiciones:

• Intervienen varios roles con permisos y objetivos distintos.
• Hay decisiones condicionales que cambian el camino según los datos de la persona.
• Existen estados intermedios, como pendiente, rechazado o en revisión.
• El proceso se interrumpe y se retoma días después.
• Hay dependencias con sistemas externos que pueden fallar.

Cuantas más condiciones se juntan, más caro es descubrir un requerimiento tarde. Lo explicamos en qué pasa cuando el flujo no está diseñado: el usuario lo nota antes que nadie, y casi siempre en los caminos que nadie dibujó.

Si quieres entender la mentalidad de partida, te recomendamos leer sobre diseñar para la complejidad. La idea central es no esconder la complejidad, sino organizarla.

Metodología de toma de requerimientos en cinco pasos

1. Define el objetivo del flujo en una frase

Antes de reunir nada, escribe qué consigue la persona y qué consigue el negocio cuando el flujo funciona bien. Si no cabe en una frase, tienes dos flujos mezclados.

Una herramienta útil aquí es jobs-to-be-done y personas. Te obliga a describir el progreso que busca la persona y no la funcionalidad que tú imaginas.

2. Entrevista a quien usa el flujo y a quien lo sostiene

Hay dos grupos que conviene escuchar: las personas que usan el flujo y las personas internas que lo mantienen, como soporte u operaciones. Las segundas conocen las excepciones que las primeras ya dieron por normales.

Para esto, las entrevistas en profundidad funcionan mejor que cualquier formulario. Pregunta por la última vez que hicieron el proceso, no por cómo lo harían en un mundo ideal.

3. Define reglas, actores y excepciones

Construye una tabla con cuatro columnas: reglas de negocio, roles, estados posibles y errores previsibles. Por cada paso del flujo, hazte la pregunta «¿qué pasa si…?» hasta quedarte sin respuestas.

4. Convierte los hallazgos en escenarios de uso

Escribe un camino principal, tres caminos alternativos y los errores más probables. Nuestra guía para hacer escenarios de uso explica cómo hacerlo sin que se convierta en un documento que nadie lee.

5. Valida el mapa del flujo antes de diseñar pantallas

Dibuja el diagrama completo y revísalo en una sesión con negocio y desarrollo. Si alguien dice «esto no funciona así», todavía estás a tiempo de corregirlo en minutos.

Qué preguntar a cada fuente

Esta tabla resume lo que le pedimos a cada perfil durante la toma de requerimientos.

Fuente	Qué aporta	Pregunta clave
Persona usuaria	Contexto real de uso	¿Cuándo fue la última vez que lo hiciste y qué salió mal?
Persona de negocio	Reglas y objetivos	¿Qué condición hace que este paso sea obligatorio?
Equipo técnico	Restricciones y dependencias	¿Qué datos llegan, cuándo y qué pasa si fallan?
Soporte u operaciones	Excepciones frecuentes	¿Qué consultas recibes más sobre este proceso?

Lo que nos enseñó un proyecto reciente

En uno de los últimos proyectos que lideramos, un flujo de solicitud parecía tener tres roles. En la tercera entrevista apareció un cuarto: una persona que revisaba excepciones y que nadie había mencionado en el arranque. Ese rol cambiaba dos decisiones clave del flujo.

Como lo descubrimos durante la toma de requerimientos, lo resolvimos en el diagrama en una tarde. Si hubiera aparecido con las pantallas ya diseñadas, habríamos rehecho semanas de trabajo.

Desde entonces cerramos cada entrevista con la misma pregunta: «¿Quién más interviene en esto?». Es la pregunta que más requerimientos escondidos nos ha destapado.

Lo que más nos preguntan sobre user flows complejos

¿Cuántas entrevistas necesito para tomar requerimientos? Las que hagan falta hasta que las respuestas dejen de aportar roles o excepciones nuevas. En flujos con varios actores, solemos necesitar entre cinco y ocho conversaciones.

¿Qué herramienta uso para diagramar el flujo? La que tu equipo ya use y pueda comentar. Lo importante es que negocio y desarrollo lo lean sin necesitar que lo expliques.

¿Cuándo paso de requerimientos a diseño de pantallas? Cuando el diagrama cubra el camino principal, los alternativos y los errores, y el equipo lo haya validado. Antes de eso, cualquier pantalla es una apuesta.

¿Sirve la IA para tomar requerimientos? Ayuda a ordenar notas, detectar huecos y proponer excepciones que no habías pensado. No sustituye hablar con las personas que viven el proceso.

Para cerrar

Si vas a diseñar user flows complejos, arranca por el inventario de reglas y excepciones, y valida el diagrama antes de abrir tu herramienta de diseño. Si quieres que revisemos tu caso actual, no dudes en contactarnos.

Foto por Kelly Sikkema en Unsplash