Cómo pasar de un proceso To Be a un user flow sin convertir cada nodo en una pantalla

En corto: Un proceso To Be describe cómo debería operar el negocio. Un user flow describe cómo una persona alcanza un objetivo mediante decisiones, información e interacción con el sistema.

No existe una equivalencia directa entre un nodo del proceso y una pantalla. Antes de diseñar es necesario separar acciones humanas, respuestas automáticas, reglas, datos y excepciones.

El recorrido práctico es:

Proceso To Be → clasificación de nodos → objetivos del usuario → reglas y excepciones → user flow → inventario de pantallas

Este método permite reducir pantallas innecesarias sin eliminar información ni simplificar artificialmente el proceso.

El problema: tratar el To Be como un mapa de pantallas

Un diagrama To Be ayuda a visualizar cómo debería funcionar un proceso: quién participa, qué actividades realiza, qué decisiones existen y qué sistemas intervienen.

El problema comienza cuando se utiliza directamente como base para diseñar la interfaz.

Si el proceso contiene los nodos “consultar información”, “validar documentos”, “corregir inconsistencias” y “confirmar datos”, puede asumirse que deben diseñarse cuatro pantallas. Sin embargo, esas actividades podrían formar parte de una sola tarea: comprobar si una solicitud cumple las condiciones para avanzar.

Cuando cada nodo se convierte en pantalla suelen aparecer:

• Recorridos excesivamente largos.
• Pasos que únicamente confirman acciones automáticas.
• Información fragmentada entre diferentes vistas.
• Pantallas que no permiten completar una tarea reconocible.
• Reglas de negocio descubiertas durante la alta fidelidad.
• Excepciones resueltas tarde o directamente ignoradas.

El To Be no está equivocado. Simplemente representa el proceso desde una altura diferente.

To Be y user flow: qué responde cada uno

El To Be puede incluir acciones que no necesitan mostrarse. El user flow, en cambio, se concentra en lo que la persona debe comprender, decidir y hacer.

Por eso no conviene comenzar dibujando pantallas. Primero debe traducirse la lógica del negocio a una lógica de interacción.

Método para transformar un To Be en un user flow

1. Delimitar el objetivo del flujo

Antes de analizar los nodos debe definirse qué intenta lograr la persona.

“Gestionar contratos” es demasiado amplio. Puede incluir asignación, validación, generación documental, firma, consulta y corrección.

Una formulación más útil sería:

“Validar la información de una solicitud y prepararla para firma.”

También deben establecerse:

• Disparador: qué condición inicia el flujo.
• Resultado: qué debe obtenerse al finalizar.
• Actor principal: quién realiza la tarea.
• Límite: qué actividades pertenecen a otros flujos.

Ejemplo:

• Disparador: se asignó una solicitud.
• Actor principal: ejecutivo responsable.
• Resultado: solicitud validada y enviada a firma.
• Fuera del flujo: seguimiento posterior de las firmas.

Este primer recorte evita diseñar una experiencia que intente resolver todo el proceso en un mismo recorrido.

2. Clasificar cada nodo antes de interpretarlo como interfaz

Cada nodo debe marcarse según su función.

Esta clasificación permite detectar qué nodos podrían requerir interfaz y cuáles deben convertirse en comportamiento automático.

Por ejemplo, “consultar información del cliente” podría ser una acción del sistema. La persona no necesita una pantalla para iniciar la consulta; necesita ver el resultado, conocer su vigencia y saber qué hacer si la consulta falla.

3. Reescribir las actividades desde el objetivo del usuario

Los nombres de los nodos suelen describir operaciones internas:

• Ejecutar validación.
• Consultar servicio.
• Generar documento.
• Actualizar estatus.

Para diseñar la interacción conviene reformularlos desde la tarea:

• Confirmar que la información es válida.
• Revisar el resultado de la consulta.
• Comprobar el documento antes de enviarlo.
• Saber en qué estado se encuentra la solicitud.

Este cambio permite identificar qué necesita comprender la persona, no solamente qué operación realiza el sistema.

4. Agrupar acciones que pertenecen a una misma tarea

Varias acciones pueden resolverse dentro de un mismo espacio de interacción cuando:

• Comparten el mismo objetivo.
• Utilizan la misma información.
• Ocurren en el mismo momento.
• Dependen de una sola decisión.
• No requieren abandonar el contexto.

Por ejemplo:

• Revisar datos del cliente.
• Comprobar documentos.
• Identificar inconsistencias.
• Corregir información.
• Confirmar que la solicitud está completa.

Estas acciones podrían integrarse en un espacio de validación con diferentes secciones o componentes. No necesariamente requieren cinco pantallas.

La agrupación no significa colocar todo en una sola vista. Significa mantener juntas las acciones que forman parte de una misma unidad de trabajo.

¿Cuándo existe un cambio de contexto?

Un cambio de contexto ocurre cuando cambia alguno de estos elementos:

• El objetivo de la persona.
• El objeto sobre el que trabaja.
• El actor responsable.
• La información necesaria.
• El nivel de riesgo de la decisión.
• El momento del proceso.

Pasar de validar información a preparar firmantes puede justificar otro espacio porque cambia la tarea, la información y el tipo de decisión.

5. Convertir reglas de negocio en comportamiento

Una regla no debe quedar escondida en una nota del diagrama. Debe transformarse en comportamiento verificable.

Por ejemplo:

“La solicitud sólo puede enviarse si todos los documentos obligatorios están vigentes.”

Esta regla obliga a definir:

• Cómo se identifica un documento obligatorio.
• Cómo se comunica su vigencia.
• Qué acción permanece bloqueada.
• Qué mensaje explica el bloqueo.
• Cómo puede corregirse.
• Qué ocurre después de completar el requisito.

Si estos puntos no están resueltos, el flujo todavía no está listo para alta fidelidad.

Una forma práctica de redactar reglas es:

“Si [condición], entonces [comportamiento]; de lo contrario, [excepción o recuperación].”

Ejemplo:

Si todos los documentos obligatorios están vigentes, se habilita “Generar contrato”; de lo contrario, se muestran los pendientes y la acción permanece bloqueada.

6. Decidir qué necesita pantalla, componente, mensaje o automatización

No todo nodo necesita una pantalla. La manifestación depende de lo que la persona debe comprender o hacer.

Una regla práctica es:

Si un nodo no cambia lo que la persona debe comprender, decidir o hacer, probablemente no necesita una pantalla independiente.

Por ejemplo, “guardar información” puede ejecutarse automáticamente. Lo que sí necesita interfaz es la confirmación de que los cambios se guardaron o la recuperación si el guardado falla.

7. Dibujar el user flow antes del inventario de pantallas

El user flow debe mostrar:

• Inicio.
• Actor principal.
• Tareas.
• Decisiones.
• Respuestas del sistema.
• Estados.
• Rutas de excepción.
• Recuperaciones.
• Resultado final.

No es necesario agregar detalle visual. En este momento importa comprobar que el recorrido es completo y coherente.

Una estructura básica podría ser:

Solicitud asignada → revisar información → ¿existen inconsistencias? → corregir o solicitar corrección → validar requisitos → ¿cumple condiciones? → generar documento → revisar firmantes → enviar a firma.

Las acciones automáticas pueden representarse dentro del flujo sin convertirlas en pantallas:

Validar requisitos → sistema genera documento → mostrar previsualización.

8. Derivar el inventario de pantallas

El inventario se crea después del user flow. Cada pantalla debe tener un propósito claro.

Si una pantalla no puede describirse mediante un propósito y una decisión, probablemente es un paso técnico presentado como interacción.

Ejemplo aplicado: formalización, validación y firma

Un proceso To Be hipotético contiene ocho nodos:

1. Recibir solicitud.
2. Asignar responsable.
3. Consultar datos.
4. Revisar documentos.
5. Corregir inconsistencias.
6. Validar información.
7. Generar contrato.
8. Enviar a firma.

Una interpretación literal produciría ocho pantallas.

Después de clasificar los nodos se obtiene lo siguiente:

• Recibir solicitud: acción automática.
• Asignar responsable: acción humana que puede resolverse desde una lista.
• Consultar datos: acción automática cuyo resultado debe mostrarse.
• Revisar documentos: parte de la tarea de validación.
• Corregir inconsistencias: componente o estado dentro de validación.
• Validar información: decisión principal del espacio de validación.
• Generar contrato: automatización con estados de procesamiento y error.
• Enviar a firma: tarea que requiere revisar documento, firmantes y condiciones.

El flujo puede materializarse en tres pantallas:

1. Lista y asignación

Permite encontrar solicitudes pendientes, consultar su estado y asignar responsable.

2. Espacio de validación

Reúne datos, documentos, alertas, inconsistencias y condiciones para continuar.

3. Preparación de firma

Muestra el documento generado, los firmantes, las condiciones pendientes y la acción de envío.

El resultado no consiste simplemente en “reducir ocho pantallas a tres”. La mejora real es que cada pantalla representa una tarea reconocible y cada operación automática se comunica mediante estados claros.

Rutas de excepción que no deben olvidarse

La ruta principal no es suficiente. Como mínimo, el flujo debería resolver:

• Datos inconsistentes.
• Documentos faltantes o vencidos.
• Consulta externa no disponible.
• Error durante la generación del documento.
• Firmante sin facultades o información incompleta.
• Solicitud devuelta para corrección.

Cada excepción debe responder:

1. ¿Qué ocurrió?
2. ¿Qué consecuencias tiene?
3. ¿Quién debe actuar?
4. ¿Cómo puede recuperarse?
5. ¿A qué estado regresa el proceso?

Una excepción sin recuperación es solamente un callejón sin salida mejor documentado.

Ejercicio práctico: ocho nodos, tres entregables

Seleccionar un proceso To Be de ocho a doce nodos. Si no se cuenta con uno, puede utilizarse el ejemplo de formalización anterior.

Entregable 1. User flow

Clasificar los nodos y dibujar:

• Ruta principal.
• Dos decisiones.
• Dos excepciones.
• Respuestas automáticas.
• Resultado final.

Entregable 2. Inventario de pantallas

Registrar para cada pantalla:

• Nombre.
• Propósito.
• Actor.
• Información necesaria.
• Decisión principal.
• Acción principal.
• Estados y excepciones.

Entregable 3. Tres reglas pendientes

Identificar tres preguntas que deben resolver Negocio, Producto o Tecnología.

Ejemplos:

• ¿Qué documentos son obligatorios para habilitar la generación?
• ¿Quién puede modificar un firmante después de validar la solicitud?
• ¿Qué ocurre si el documento se genera, pero el envío a firma falla?

Estas reglas pendientes forman parte del resultado. Ocultarlas para que el flujo parezca terminado sólo traslada la incertidumbre a los wireframes o al desarrollo.

Lista de comprobación

Antes de pasar a alta fidelidad, conviene revisar:

• ¿El flujo comienza y termina con condiciones claras?
• ¿Cada nodo está clasificado?
• ¿Las acciones automáticas dejaron de convertirse en pantallas?
• ¿Cada pantalla representa una tarea reconocible?
• ¿Las reglas se transformaron en comportamientos?
• ¿Los estados muestran qué ocurre y qué sigue?
• ¿Las excepciones permiten recuperarse?
• ¿Las reglas pendientes están documentadas?
• ¿Negocio validó el proceso y UX validó la interacción de alto nivel?

Conclusión

Pasar de un To Be a un user flow no consiste en redibujar el mismo proceso con otros símbolos. Consiste en traducir la operación del negocio a una experiencia comprensible y ejecutable.

El recorrido es:

Clasificar nodos → agrupar por objetivo → resolver reglas → definir excepciones → construir el flujo → derivar pantallas

La secuencia no busca producir más documentación. Busca evitar que decisiones de negocio, interacción y arquitectura se descubran cuando la interfaz ya está en alta fidelidad o en desarrollo.

El user flow está suficientemente resuelto cuando cada pantalla tiene un propósito, cada decisión tiene información para tomarse y cada excepción permite continuar.