Wireflows: Wireframes and Flows on One Map
A wireflow combines a user flow with wireframes of each screen in one diagram. What it is, when to use it, how to draw its arrows, and when it does not help.
What is it, and how is it different?
Confusing the three artifacts is common. NN/g explains the gap: flowcharts leave out the context of the page, and wireframes show the layout but do not describe the interaction well. A wireflow takes the logic of the diagram and replaces its symbols with screen designs (NN/g: Wireflows).
In practical terms:
| Artifact | What it shows | What it does not show |
|---|---|---|
| Wireframe | The structure of a single screen | How the person gets there or what happens next |
| User flow | The path between screens and the decisions | The design of each screen |
| Wireflow | The path, with each screen at its step | The final visual design |
Slickplan puts it this way: wireflows combine the structure of wireframes with the journey of user flows. Wireframes show the static interface, while user flows show navigation without layouts (Slickplan: Wireflow).
When should you use a wireflow?
When behavior matters as much as layout. NN/g recommends it for apps with few core pages whose content or layout changes dynamically, such as the filters of an e-commerce site or a checkout. CareerFoundry adds that it helps communicate a highly dynamic interface to clients or colleagues and works especially well for mobile apps, because of their small screens (CareerFoundry: User flows vs. wireframes).
Slickplan suggests it for complex apps where navigation patterns matter, and for multi-step processes such as onboarding or checkout.
How do you draw the arrows?
Arrows are where a wireflow becomes clear or confusing. NN/g proposes that the arrow leave the specific clickable component (the hotspot) and point to the resulting screen. The result is not always another page: it can be the same screen with changed content, a popup, a color change, or an error message. Hotspots matter most when a screen has several actionable targets.
Slickplan suggests a simple convention: arrows for navigation paths between screens, decision points for branches (for example, a failed login attempt), and annotations that explain the user’s action, the system’s reaction, and what the person expects to happen.
When should you NOT use one?
- When there are many discrete, relatively static pages. NN/g notes that wireflows are less useful there.
- On static desktop sites. NN/g cautions that wireframe images can become too large to keep the process in context.
- When you try to fit every scenario into one map. Slickplan advises against it and recommends splitting the flow into smaller, task-specific sections, while still including error states and alternative paths.
- When you expect a final design. According to Slickplan, wireflow screens are low-detail layouts: they show only buttons, input fields, and the general page layout.
How do you keep it alive?
A wireflow goes stale quickly. When a screen changes or a new step appears, the map falls out of date and stops being a reliable source. So keep it next to the design file, put the flow’s version number in the title, and add a short change note every time the path changes. That way the team knows which version is approved and which is a draft.
It also works as a discussion tool. The map is best reviewed as a group, with the product manager, developers, and whoever runs the research, because each person spots a path the others missed.
Illustrative example
Illustrative example: a team designs the purchase of a ticket for an event. The user flow has seven steps. The wireflow replaces each step with its screen: date selection, seat choice, buyer details, payment, and confirmation. The arrows leave the “Continue” button and the selected seat. On the payment screen, one arrow leads to a popup if the card fails, and another returns to the same step with the error marked. When a developer reads the map, they know what happens in each case without asking for an explanation in the meeting.
Before you draw, define the design brief so you know what problem the flow solves. If the flow comes from understanding a person, an experience map can show the whole journey before you go down to screen detail. And for steps with forms, the guidance on form design applies directly to the screens in the wireflow.
Common mistakes
- Drawing wireframes with no arrows and calling it a wireflow.
- Using arrows that do not indicate the element that triggers them.
- Forgetting the error and loading states, which are exactly the ones that change the path most.
- Presenting the wireflow as if it were the final design.
- Making the map so large that nobody can read it on one screen.
- Leaving out decisions: without branches, the flow looks linear when it is not.
What you can do tomorrow
- Take a flow in your product with more than five steps and draw its wireflow on a single page.
- Mark every element that changes the screen with an arrow, and every possible error with a note.
- Show it to someone who does not know the product and ask what happens if they tap the main button at step three.