Diseñar flujos no es tan difícil. Lo difícil es decidir dónde poner fricción.
Durante mucho tiempo pensé que diseñar buenos flujos era, sobre todo, un problema de orden. Qué paso va antes, cuál después, cuántas pantallas son demasiadas, dónde colocar el CTA.
Con los años me di cuenta de que ese no era el verdadero problema.
Las conversaciones complicadas no aparecían cuando hablábamos de layout o jerarquía visual. Aparecían siempre en los mismos puntos del flujo, con preguntas muy parecidas:
- ¿Aquí hace falta confirmación?
- ¿Esto debería poder deshacerse?
- ¿Un modal es demasiado agresivo?
- ¿Y si alguien se equivoca?
Y lo curioso es que casi nunca había una respuesta clara. No porque faltara experiencia, sino porque esas decisiones no estaban realmente diseñadas. Se resolvían por intuición, por costumbre o por “en este producto siempre lo hemos hecho así”.
El problema no es el flujo.
Un flujo no es solo una secuencia de pantallas. Es una sucesión de decisiones, y no todas pesan lo mismo.
- Cambiar el nombre de algo no es lo mismo que eliminarlo.
- Cambiar un estado no es lo mismo que lanzar una acción irreversible.
Y aun así, muchas veces los tratamos igual a nivel de experiencia.
El resultado suele ser un producto visualmente coherente, pero conceptualmente inconsistente. Hay fricción donde no hace falta y, lo que es peor, falta fricción donde sí debería haberla.
Donde la IA empezó a resultarme útil
En nuestro caso, la IA no forma parte del producto final. No toma decisiones por el usuario. No hay modelos en producción.
Pero sí empezamos a usarla como apoyo cuando diseñamos.
No para que “diseñe flujos”, sino para algo mucho más concreto: ayudarnos a pensar mejor sobre qué tipo de decisiones hay dentro de un flujo.
Algo tan simple como describir un caso en lenguaje natural:
“El usuario edita un elemento. Puede cambiar el nombre, cambiar el estado o eliminarlo.”
Cuando le pides a la IA que analice ese flujo y razone sobre cada acción, pasa algo interesante. Te devuelve una estructura que, en el fondo, ya intuías… pero que nunca habías formalizado del todo.
No te dice qué UI usar. Te habla de impacto, reversibilidad, riesgo.
Y ahí es donde empieza a aportar valor.
El framework que me ayudó a ordenar esto
Para no quedarnos en conversaciones abstractas, empezamos a usar un marco muy sencillo. Nada sofisticado. Solo cuatro preguntas que ahora me hago casi automáticamente cuando diseño un flujo.
1. ¿Qué impacto tiene esta decisión?
¿Afecta solo al usuario actual o a más personas? ¿Es algo local o tiene consecuencias aguas abajo?
2. ¿Es reversible?
¿Se puede deshacer fácilmente? ¿Existe un “undo” real o solo teórico?
3. ¿Qué pasa si el usuario se equivoca?
¿El error es molesto o grave? ¿Puede generar pérdida de datos, trabajo extra o problemas difíciles de corregir?
4. ¿Cuánta fricción está justificada?
Aquí no se trata de “menos fricción es mejor”, sino de si la fricción es proporcional al impacto de la decisión.
Cuando respondes a estas preguntas, muchas discusiones de UX se aclaran solas.
Ponerle nombre a las decisiones
A partir de ahí empezamos a hacer algo muy simple: ponerle nombre al tipo de decisión antes de pensar en la interfaz.
No “este botón es secundario”, sino: — esto es una decisión segura — esto es una decisión de impacto medio — esto es una decisión claramente peligrosa
A esas etiquetas empezamos a llamarlas decision tokens. No como algo técnico, sino como un lenguaje compartido, igual que los tokens en un design system.
Cuando alguien decía “esto es una decisión de alto impacto”, ya no hablábamos de gustos. Hablábamos de consecuencias.
Del token al patrón (sin empezar de cero cada vez)
Con el tiempo, cada tipo de decisión empezó a asociarse a ciertos patrones:
- Decisiones seguras → interacción directa, sin confirmación
- Decisiones de impacto medio → confirmación ligera, posibilidad de deshacer
- Decisiones críticas → confirmación explícita, copy claro, sin ambigüedad
No es una regla rígida. Es una guía. Pero evita que cada flujo sea una reinvención constante.
Y, sobre todo, hace que el producto tenga una lógica interna que el usuario percibe, aunque no sepa explicarla.
Cómo usamos la IA en este proceso
Describimos el flujo y las acciones, y le pedimos que razone sobre impacto, reversibilidad y riesgo. A veces estamos de acuerdo. A veces no.
Pero incluso cuando no lo estamos, la conversación mejora. Porque ya no parte del «me gusta / no me gusta», sino del «qué pasa si alguien se equivoca aquí».
La IA no decide. Nos ayuda a pensar con más claridad.
Lo que he aprendido de todo esto
Que diseñar flujos no va de eliminar fricción. Va de colocarla bien.
Y que muchos problemas de experiencia no vienen de una mala UI, sino de no haber diseñado explícitamente las decisiones que estamos poniendo delante del usuario.
Tener un framework sencillo, un lenguaje común y una ayuda externa que te obligue a razonar (aunque sea una IA) hace que el diseño deje de ser reactivo y se vuelva más consciente.
Al final, el flujo es solo la superficie. Lo que de verdad importa es qué decisiones estás pidiendo… y si el diseño está a la altura de su impacto.