What is a user flow in UX?

What a user flow looks like

Most flows are built from a handful of shapes. A start point shows where the person enters, perhaps from a search result or a push notification. Rectangles represent screens or actions. Diamonds represent decisions, such as "Is the user logged in?". Arrows connect them, and an end point marks success or exit.

The value is not in the drawing style. It is that you can see the whole path at once, including the branches nobody likes to think about.

Task flow, user flow and journey map

These are close cousins and are often confused. A task flow follows one task for a generic user, such as resetting a password. A user flow usually adds context, like different entry points or user types. A user journey map is wider and more emotional: it covers the stages of a person's whole experience, including feelings and moments outside the product.

In practice, teams do not argue much about the label. Use whichever level of detail answers the question you have.

How to draw one

• Pick a single goal, such as "book an appointment" or "upgrade my plan".
• Decide who is doing it and where they start.
• List the steps they need, from the person's point of view, not the system's.
• Add the decisions and the branches: what if the payment fails, what if the date is full?
• Mark the happy path first, then the unhappy paths.
• Check for dead ends. Every screen should let someone move forward, go back or recover.
• Show it to a developer and a non-designer and see if they understand it without you talking.

A whiteboard, sticky notes or a diagramming tool will all work.

Why flows catch problems early

Drawing a flow forces you to ask awkward questions before pixels exist. What happens when someone abandons halfway and returns tomorrow? Do they need to log in? Where does the confirmation email lead? Gaps that hide in a stack of screens become obvious when they are laid out as arrows.

Flows also help teams count effort. If a core task takes nine steps, that is a conversation to have before design, not after.

Common mistakes

The first is drawing only the happy path, which makes everything look smooth and hides the errors. The second is describing the system's logic instead of the person's actions, so the diagram becomes a backend chart. The third is making a flow so large that nobody reads it. Split big journeys into smaller flows and link them. And keep it in step with the product, because an outdated diagram is worse than none.