A user flow represents the steps and decisions involved in reaching a goal within a product. It shows what the person does, how the system responds and where the route can branch. Teams use flows to reason about an experience before building it and to compare the proposed route with what people actually do.
The useful detail often appears beyond the successful path. An invitation expires, an account already exists or the person leaves halfway through and returns from a different device. Drawing those conditions makes it harder to mistake a sequence of attractive screens for a complete interaction.
Set the beginning and the outcome
Consider a fictional neighbourhood tool for lending equipment. “Borrow a drill” could begin with a search, a link from a neighbour or an unanswered request sent the previous day. It might end when a request is submitted, when the owner agrees or when the borrower has collection details. The flow needs an explicit boundary so that everyone knows which outcome it represents.
Start from the person’s goal and relevant entry conditions. Record what they already know, whether they are signed in and any permissions or information required. Avoid beginning at the screen the team happens to be redesigning if a preceding step materially affects the experience.
Nielsen Norman Group’s comparison of user journeys and user flows distinguishes a focused interaction from a broader experience. A journey map may cover the need, conversations, collection and return of the drill across channels. The flow can examine a particular part of that experience in more detail.
Make decisions and system states visible
Show meaningful branches: the equipment is available or unavailable, the owner accepts or declines, the borrower has provided the required information or has not. Include loading, confirmation and error states where they affect the next action or the person’s understanding.
The representation can be a simple diagram or a wireflow that connects small views of the screens. Choose the format that makes the decision clear. Elaborate notation is unnecessary if a few labelled steps explain the behaviour; a more complex interaction may need separate linked flows to remain readable.
Distinguish an observed flow from a proposed one. Task analysis can inform the account of current work, including steps outside the interface. A design flow then represents a proposal for how the product might support it. Labelling the difference prevents an assumption from acquiring the status of research evidence.
Test the route people take
Use realistic tasks in prototype testing to see how participants proceed. A detour may reveal a confusing label, an unmet need or a perfectly reasonable alternative route. Compare the behaviour with the goal before deciding that divergence from the diagram is a failure.
Once the product is live, behavioural analytics can help examine routes and drop-off at a larger scale. Check the instrumentation and the meaning of each event: opening a request form is not submitting a request, and returning later is not always abandonment. Recordings or follow-up research may be needed to explain the pattern.
Keep the flow connected to the product
Update the diagram when decisions change, and identify the version it describes. A flow that omits a new permission step or recovery route can mislead design, engineering and research in different ways.
For the lending example, success means more than a clean line from request to confirmation. The person needs to understand what has happened, what remains dependent on the owner and what they can do next. The flow earns its place when it helps the team see and resolve those dependencies before customers encounter them.