Wireflows: wireframes y flujos en un solo mapa
Un wireflow combina el flujo de usuario con wireframes de cada pantalla en un mismo diagrama. Qué es, cuándo usarlo, cómo dibujar sus flechas y cuándo no sirve.
¿Qué es y cómo se diferencia?
Confundir los tres artefactos es común. El NN/g lo explica así: los diagramas de flujo dejan fuera el contexto de la página, y los wireframes muestran el layout pero no describen bien la interacción. Un wireflow toma la lógica del diagrama y reemplaza sus símbolos por diseños de pantalla (NN/g: Wireflows).
En términos prácticos:
| Artefacto | Qué muestra | Qué no muestra |
|---|---|---|
| Wireframe | La estructura de una sola pantalla | Cómo se llega a ella ni qué pasa después |
| User flow | El recorrido entre pantallas y las decisiones | El diseño de cada pantalla |
| Wireflow | El recorrido con cada pantalla en su paso | Diseño visual final |
Slickplan lo resume diciendo que los wireflows combinan la estructura de los wireframes con el recorrido de los user flows, y que los wireframes muestran la interfaz estática mientras los user flows muestran la navegación sin layouts (Slickplan: Wireflow).
¿Cuándo usar un wireflow?
Donde el comportamiento importa tanto como el layout. El NN/g lo recomienda para aplicaciones con pocas páginas centrales que cambian su contenido o su diseño dinámicamente, como los filtros de un comercio electrónico o un checkout. CareerFoundry añade que sirve para comunicar una interfaz muy dinámica a clientes o colegas y que funciona especialmente bien en apps móviles, por el tamaño reducido de las pantallas (CareerFoundry: User flows vs. wireframes).
Slickplan lo sugiere para apps complejas donde importan los patrones de navegación, y para procesos de varios pasos como onboarding o pago.
¿Cómo se dibujan las flechas?
Las flechas son el punto donde un wireflow se vuelve claro o confuso. El NN/g propone que la flecha salga del componente clicable específico (el hotspot) y apunte a la pantalla resultante. El resultado no siempre es otra página: puede ser la misma pantalla con contenido cambiado, un popup, un cambio de color o un mensaje de error. Los hotspots importan más cuando una pantalla tiene varios objetivos accionables.
Slickplan propone una convención sencilla: flechas para las rutas de navegación entre pantallas, puntos de decisión para las ramificaciones (por ejemplo, un intento fallido de inicio de sesión) y anotaciones que expliquen la acción del usuario, la reacción del sistema y lo que la persona espera que ocurra.
¿Cuándo NO conviene?
- Cuando hay muchas páginas independientes y relativamente estáticas. El NN/g advierte que el wireflow pierde utilidad ahí.
- En sitios de escritorio estáticos. El NN/g advierte que las imágenes de wireframe pueden volverse demasiado grandes para mantener el proceso en contexto.
- Cuando intentas meter todos los escenarios en un solo mapa. Slickplan lo desaconseja y recomienda dividir el flujo en secciones más pequeñas, una por tarea, sin dejar de incluir los estados de error y las rutas alternativas.
- Cuando esperas un diseño final. Según Slickplan, las pantallas de un wireflow son diseños de poco detalle: solo muestran botones, campos y el layout general de la página.
¿Cómo se mantiene vivo?
Un wireflow envejece rápido. Cuando cambia una pantalla o aparece un paso nuevo, el mapa queda desactualizado y deja de ser una fuente confiable. Por eso conviene que viva junto al archivo de diseño, con el número de versión del flujo en el título y una nota de cambios breve cada vez que el recorrido se modifica. Así el equipo sabe qué versión está aprobada y cuál es un borrador.
También sirve para discutir. El mapa se revisa mejor en grupo, con el product manager, desarrollo y quien hace la investigación, porque cada uno detecta un camino que los demás no vieron.
Ejemplo ilustrativo
Ejemplo ilustrativo: un equipo diseña la compra de un boleto para un evento. El user flow tiene siete pasos. El wireflow reemplaza cada paso por su pantalla: selección de fecha, elección de asiento, datos del comprador, pago y confirmación. Las flechas salen del botón «Continuar» y del asiento seleccionado. En la pantalla de pago, una flecha lleva a un popup si la tarjeta falla, y otra vuelve al mismo paso con el error marcado. Cuando un desarrollador lee el mapa, sabe qué pasa en cada caso sin pedir una explicación en la reunión.
Antes de dibujar, define el design brief para saber qué problema resuelve el flujo. Si el flujo nace de entender a una persona, un mapa de experiencia puede mostrar el recorrido completo antes de bajar al detalle de las pantallas. Y en los pasos con formularios, la guía sobre diseño de formularios aplica directamente a las pantallas del wireflow.
Errores comunes
- Dibujar wireframes sin flechas, y llamarlo wireflow.
- Usar flechas que no indican el elemento que las dispara.
- Olvidar los estados de error y de carga, que son justo los que más cambian el recorrido.
- Presentar el wireflow como si fuera el diseño final.
- Hacer un mapa tan grande que nadie lo puede leer en una pantalla.
- Dejar fuera las decisiones: sin ramificaciones, el flujo parece lineal y no lo es.
Qué puedes hacer mañana
- Toma un flujo de tu producto con más de cinco pasos y dibuja su wireflow en una sola página.
- Marca con una flecha cada elemento que cambia de pantalla, y con una nota cada error posible.
- Muéstralo a alguien que no conozca el producto y pídele que diga qué pasa si toca el botón principal en el paso tres.