When is the right time to do your user flows?

User flows are often treated as a design artefact. A designer starts working through a feature, creates a flow to understand how the screens connect, and then moves on to wireframes.

I think this is too late.

The right time to start creating user flows is once the team understands the problem and what users need to achieve, but before detailed interface design begins.

At this stage, the flow can help uncover what needs to happen, which decisions still need to be made, and how different parts of the product or service interact. It becomes a way of working out the solution, rather than simply documenting decisions that have already been made.

Once wireframes exist, conversations naturally start moving towards the interface. People discuss where the button should go, what information should appear on the page and whether another screen is required. These are all useful conversations, but they can distract from a more fundamental question:

Do we actually understand how this is supposed to work?

Start with the problem, not the screens

There is obviously some work that needs to happen before creating a user flow. You need to understand the problem you are trying to solve, who the users are and what they are trying to achieve.

This might come from user research, existing service information, business requirements, workshops or analysis of the current process. The exact approach will depend on the project.

Once you understand the problem well enough to start discussing how the future experience could work, I think that is the right time to start mapping the flow.

Not once the wireframes are complete.

Not once development has started.

And definitely not when somebody asks for a diagram to explain the finished design.

The flow should be part of working out the solution.

Why before wireframes?

Wireframes are very good at making something feel real.

As soon as a team can see a screen, people can react to it. They can comment on the wording, suggest another field, discuss whether something should be a radio button or a dropdown and argue about where the Continue button belongs.

The danger is that the existence of a wireframe can create the impression that the underlying product decisions have already been made.

Take a simple example where a user needs to submit an application.

It would be quite easy to start designing:

Application form → Review → Submit → Confirmation

From there you could quickly produce four perfectly reasonable wireframes.

But there are still a lot of questions that might need answering.

Can the user save the application and return later? What happens if information is missing? Are some questions dependent on previous answers? Can the user change the application after submitting it? Does somebody need to review the application? Can it be rejected? What happens if it is returned for more information? Does the user need a particular permission or account status before they can submit?

These aren’t really wireframe questions. They are product logic questions.

If you answer them while creating the flow, the wireframes become easier to design because the designer already understands the different situations that need to be represented.

If you don’t answer them, they don’t disappear. They simply turn up later.

User flows create better conversations

One of the biggest benefits of doing user flows early is that they give different disciplines something to discuss before everybody disappears into their specialist artefacts.

A UX designer may be thinking about how easy the experience is for the user. A Business Analyst may be thinking about business rules and exceptions. A Product Owner may be considering scope and priorities. A developer may already be thinking about how different systems need to communicate. A Solution Architect might be considering dependencies, integrations and technical constraints.

All of those viewpoints are useful.

The problem comes when those conversations happen separately.

The designer creates wireframes based on one understanding of the process. The BA writes requirements based on another. The developer interprets the behaviour differently again. Eventually the differences are discovered and everybody has to work backwards to decide what the product was supposed to do in the first place.

An early user flow gives the team a shared model to challenge.

The UX designer can ask whether a particular outcome creates a confusing experience. The BA can identify a missing business rule. The developer can point out that an apparently simple action actually depends on another service. Product can decide whether an exception needs to be supported in the first release.

The flow isn’t replacing any of those disciplines. It is giving them somewhere to have the conversation together.

The flow doesn’t need to be finished

I think one reason teams leave user flows too late is the assumption that they need enough information to produce a complete flow before they start.

You don’t.

The first version can be wrong.

In fact, if you create a user flow early enough, it probably should be wrong because there are still things the team doesn’t know.

That is useful.

An unanswered question on a flow is considerably more valuable during discovery than an unanswered question found halfway through development.

The team might start with:

User submits request → Request is approved

Then somebody asks who approves it.

Now there is another step.

Someone else asks what happens if it is rejected.

Another outcome appears.

Then somebody asks whether all requests require approval or only those above a certain value.

Now there is a decision.

The flow becomes more complicated as the team understands the product better. That isn’t a failure of the flow. That is the flow doing its job.

Don’t wait for every requirement either

There is also a danger of going too far in the opposite direction and deciding that the flow can’t be created until every requirement and business rule has been documented.

Again, I think that misses the point.

Creating the flow can be part of discovering those requirements.

If you already know every possible action, decision, outcome, permission and business rule before you start mapping, then the flow is mostly documentation.

There is value in documentation, but there is much more value in using the flow as an analysis tool.

Map what you know. Identify what you don’t know. Resolve the important questions and update the flow.

That process can happen several times before anybody starts drawing detailed screens.

What should happen next?

Once the main product logic is understood, wireframing becomes a much more informed activity.

The designer isn’t simply asking what screen comes after the current screen. They understand why the user is moving there, what has happened in the system and what state the product is now in.

This also makes it easier to identify which screens actually need to exist.

Sometimes several outcomes can be represented using different states of the same interface. Sometimes an action doesn’t require another screen at all. Sometimes what initially looked like one screen turns out to require several different experiences because the user’s permissions or the state of the product changes what they can do.

The flow informs the wireframes rather than being reverse engineered from them afterwards.

The flow can provide traceability through delivery

The usefulness of the user flow doesn’t need to end when wireframing starts. As the interface is designed, references to the relevant wireframes can be added back into the flow. This creates a connection between the product logic and the screens that have been designed to support it, rather than leaving the flow and the wireframes as two separate artefacts that need to be interpreted alongside each other.

That traceability can then continue into development. The team can use the flow to understand which actions, outcomes and states are being implemented, while still being able to refer directly to the corresponding interface designs. When something changes in a wireframe or in the underlying logic, it is much easier to see what else may be affected.

The same applies when the product reaches testing. Test scenarios can be traced back through the different paths and outcomes represented in the flow, helping ensure that testing covers more than the happy path. Validation failures, permissions, alternate outcomes and different states that were identified earlier can all become part of the test coverage.

This means the user flow can have a much longer lifecycle than simply helping the design team understand what to wireframe. It can start during discovery and analysis, develop alongside the interface design, support development and eventually help inform testing.

In that sense the flow becomes a shared reference point across the delivery lifecycle:

Understand the problem → Map the flow → Resolve the logic → Link the wireframes → Develop → Test

Flows should continue to change

Doing your user flows before wireframes doesn’t mean you finish the flow and then never touch it again.

As wireframes are designed, new questions will appear. User testing may uncover situations you hadn’t considered. Technical discussions may introduce constraints. Business rules may change.

The flow should change with them.

The important thing is the order in which you start.

I would generally expect the process to look something like:

Understand the problem → Map the flow → Resolve the important logic → Create wireframes → Test and refine both

There will obviously be overlap between those activities. UX and product development is rarely a perfectly linear process, nor should it be.

But if detailed interface design is well underway before anyone has mapped how the product actually behaves, I think the team has skipped an important conversation.

Use the flow to find the questions

For me, the most valuable user flows aren’t necessarily the ones that look the cleanest.

They are the ones that make somebody stop and ask:

What happens here?

What if this fails?

Who is allowed to do this?

What other outcomes are possible?

What changes after this action?

If those conversations happen before the wireframes are created, changes are relatively easy. You are changing your understanding of the product rather than redesigning a set of screens that everybody has already started treating as the solution.

That is why I think user flows should sit much earlier in the process.

They aren’t simply a way of documenting the journey through an interface.

They are a way for UX, BA, Product, Development and other parts of the delivery team to work out how the product needs to behave before everybody starts designing and building their individual parts of it.