User Flow Diagram: How to Create One (+ 4 Examples)

A user flow diagram is a flowchart that maps every step a user takes to complete one task in your product, from entry point to end state. It shows the screens they see, the actions they perform, and the decision points that split their path. Teams use user flow diagrams to catch dead ends, confusing branches, and missing error states before anyone writes code.

Most guides show you static pictures of flows. This one gives you four working examples written in Mermaid flowchart syntax, so you can copy the code, paste it into your own docs or README, and edit the flow as text. You will also get the standard shapes, a six-step process for building your first diagram, and the mistakes that make flows useless.

Key takeaways

• A user flow maps one task from entry point to end state, including every decision and error branch
• It differs from a task flow (no branches), a wireflow (real screens), and a journey map (emotions across channels)
• Five shapes cover almost every flow: oval, rectangle, diamond, parallelogram, and arrow
• Start from the user's goal, map the happy path first, then add decision nodes and edge cases
• Text-based flows in Mermaid live in version control and stay current; image exports go stale

What is a user flow diagram?

A user flow diagram is a visual map of the path a user follows to finish a specific task: signing up, checking out, resetting a password. Each node is a screen or an action. Each arrow is a transition. Each diamond is a decision the user or the system makes, like "valid email?" or "payment authorized?".

The scope is deliberately narrow. One flow covers one goal for one type of user. A signup flow does not include billing. A checkout flow does not include browsing. That constraint is what makes the diagram useful, because you can trace a single journey without noise from every other feature.

User flows sit at the low-fidelity end of UX design work. They come before wireframes and prototypes, when changing a path costs nothing. A product manager, a designer, and an engineer can argue about a diamond on a whiteboard in five minutes. Arguing about the same logic after the feature ships costs a sprint.

Why do user flows matter?

Flows expose problems that lists of requirements hide. A spec might say "users can reset their password." The user flow diagram forces you to answer what happens when the email does not exist, when the reset link expires, and when the user clicks it twice. Those edge cases are where support tickets come from.

They also align teams cheaply. Engineers read the diagram and see conditional logic. Designers see screen count. Product managers see where users can bail out of the conversion funnel. Everyone is looking at the same picture, which beats three people holding three different mental models of the same feature.

The third payoff is measurement. Once a flow is drawn, every arrow is a potential drop-off point you can instrument. If 40% of users abandon between "enters payment details" and "order confirmed," the diagram tells you exactly which screens and decisions live in that gap.

User flow vs task flow vs wireflow vs journey map

These four diagram types get mixed up constantly, and picking the wrong one wastes effort. A task flow is simpler than a user flow. A wireflow is heavier. A journey map answers a different question entirely.

Use a task flow when there is exactly one way through, like a forced software update. Upgrade to a user flow the moment a decision appears. Move to a wireflow when the screens exist and you want to check that each one supports its next step. Reach for a journey map when the question is "how do customers feel across the whole lifecycle" rather than "what happens when they click this."

One more boundary worth drawing: a user flow tracks people moving through screens, not data moving through systems. If you need to show how information travels between processes and data stores, that is a data flow diagram, which uses different notation and serves engineers rather than UX designers.

Which flowchart shapes do user flows use?

User flows borrow their notation from standard flowcharts, which is why some teams call the same artifact a user flow chart. You only need five flowchart shapes for most flows, though the classic set includes seven. Consistency matters more than coverage: pick your set, label it once, and never improvise mid-diagram.

Two conventions make flows readable at a glance. First, every diamond needs a label on every exit arrow, usually Yes and No. An unlabeled branch forces the reader to guess. Second, the happy path should run in one dominant direction, top to bottom or left to right, with error branches hanging off the sides. When the main route zigzags, nobody can find it.

How do you create a user flow diagram?

You can build a solid first user flow diagram in under an hour. The process below works whether you draw in FigJam or write Mermaid in a text editor.

1. Define the user and the goal. One flow, one persona, one outcome. "New visitor completes signup" is a flow. "Users interact with the app" is not. Write the goal as the diagram's title so scope creep is visible.
2. Fix the entry point. Where does this journey actually start? A Google search, a pricing page CTA, an invite email, a push notification. Entry point changes the first screen and often the whole shape of the flow.
3. Map the happy path first. Draw the shortest successful route from entry to goal as a straight spine. Do not add branches yet. If the happy path alone needs more than roughly a dozen steps, the task is probably too big for one diagram.
4. Add decision nodes. Now walk the spine and ask at each step: what can the user choose here, and what can the system reject? Each answer becomes a diamond. Signed in or guest? Valid card or declined? Every real product has more diamonds than first drafts admit.
5. Chase the edge cases. Expired tokens, empty states, back-button presses, duplicate submissions. You do not need every theoretical failure, but any state a real user can reach needs an exit. A branch that ends nowhere is a bug you are choosing to ship.
6. Walk it with someone else. Read the flow aloud to an engineer or a support person. They will find the missing branch in minutes, because they have seen the tickets. Revise, then put the diagram somewhere the whole team can find it.

The last step is the one most teams skip, and it is why so many flows die as screenshots in an old Slack thread. A flow earns its keep when it stays visible and current.

4 user flow diagram examples in Mermaid

Every user flow diagram example below is real, editable Mermaid code, not a screenshot. The code renders as a live diagram right here on this page, and it will do the same in any docs platform with Mermaid support. Copy any block and adapt it.

Example 1: Signup flow

The signup flow is the classic starter example because it has one goal, two decisions, and an asynchronous step that trips people up: email verification.

flowchart TD
    A([User lands on homepage]) --> B[Clicks Sign up]
    B --> C[/Enters email and password/]
    C --> D{Valid input?}
    D -- No --> E[Show inline error]
    E --> C
    D -- Yes --> F[Send verification email]
    F --> G{Email verified?}
    G -- No --> H[Resend prompt after 24h]
    H --> G
    G -- Yes --> I([First-run dashboard])

The walkthrough: invalid input loops back to the form instead of dead-ending, and the unverified state has a recovery branch. Most signup specs forget that second loop. The diagram makes its absence impossible to miss, because G would only have one exit.

Example 2: Checkout flow

Checkout adds a fork near the start (guest vs signed in) and a high-stakes decision at the end (payment authorization). Note how the declined path preserves the cart.

flowchart TD
    A([Product page]) --> B[Adds item to cart]
    B --> C{Signed in?}
    C -- Yes --> D[/Enters shipping details/]
    C -- No --> E[Chooses guest checkout or sign in]
    E --> D
    D --> F[/Enters payment details/]
    F --> G{Payment authorized?}
    G -- No --> H[Shows decline message, keeps cart]
    H --> F
    G -- Yes --> I[Order confirmation screen]
    I --> J([Confirmation email sent])

Two details here earn their place. The guest option exists because forcing account creation before purchase is a well-known conversion killer. And the decline branch returns to payment entry with the cart intact, which is the difference between a retry and an abandoned sale.

Example 3: Password reset flow

Password reset looks trivial and is not. It involves a security decision (never reveal whether an account exists) and a time-limited token.

flowchart TD
    A([Login page]) --> B[Clicks Forgot password]
    B --> C[/Enters account email/]
    C --> D{Account exists?}
    D -- Yes --> E[Sends reset link]
    D -- No --> F[Sends nothing]
    E --> G[Shows generic confirmation]
    F --> G
    G --> H{Link clicked within 1 hour?}
    H -- No --> I[Token expired page]
    I --> B
    H -- Yes --> J[/Sets new password/]
    J --> K([Redirected to login])

The interesting shape is D: both branches lead to the same generic confirmation screen. That is intentional. Showing "no account found" lets attackers probe which emails are registered. The diagram encodes a security policy that a text spec would bury in a footnote.

Example 4: Onboarding flow

Onboarding flows have the most branches because users arrive in different states. This one splits invited teammates from workspace creators, then funnels both toward one activation event. For more patterns to steal, see these user onboarding examples.

flowchart TD
    A([First login]) --> B{Invited by teammate?}
    B -- Yes --> C[Joins existing workspace]
    B -- No --> D[/Names new workspace/]
    D --> E[Picks a starter template]
    C --> F[Product tour prompt]
    E --> F
    F --> G{Takes the tour?}
    G -- Yes --> H[3-step guided tour]
    G -- No --> I[Skips to dashboard]
    H --> J{Completes first key action?}
    I --> J
    J -- Yes --> K([Activated user])
    J -- No --> L[Nudge email on day 2]
    L --> J

The design choice worth copying: both the tour path and the skip path converge on the same activation check at J. Onboarding success is defined by the key action, not by tour completion. Teams that measure tour completion instead of activation optimize the wrong node.

What mistakes ruin user flows?

The failure modes are predictable, and most of them come from trying to make one diagram do too much.

• Mapping the whole product in one flow. A diagram with forty nodes and six goals is a maze, not a map. Split it. One flow per task, linked to each other where they hand off.
• Only drawing the happy path. If every diamond has one exit, you have drawn a task flow and called it a user flow. The errors and edge cases are the entire point.
• Unlabeled decision branches. A diamond with two bare arrows makes readers guess which side is Yes. Label every exit, every time.
• Mixing altitudes. "Clicks the blue button in the top nav" next to "completes KYC verification" confuses everyone. Keep steps at a consistent level of detail, and push big sub-processes into their own flow.
• Shipping it as a static image. A PNG in a slide deck is accurate for about two sprints. When the flow changes and the picture does not, the diagram becomes actively misleading. Text-based formats that live next to your docs survive; exported images rot.

That last mistake is the quiet one. Nobody notices a stale diagram until a new hire builds their mental model from it.

Which user flow tool should you use?

The right tool depends on where the diagram will live and who needs to edit it. There are two camps: visual canvas tools and text-based diagramming.

Canvas tools win for live collaboration. Dragging shapes in FigJam during a workshop is faster than typing syntax while five people watch. If your flow needs to sit beside real mockups, Figma is the natural home.

Mermaid wins everywhere after the workshop. The flow is plain text, so it diffs in pull requests, updates in the same commit as the feature, and renders anywhere Markdown does. Every example in this post is Mermaid, which is why you can copy them instead of squinting at screenshots. If you have never used the syntax, ten minutes with the flowchart basics covers everything a user flow needs.

Where do user flows belong in your documentation?

A user flow diagram that lives in a designer's private file helps one person. The same diagram in your team's docs helps support agents trace a stuck user, helps new engineers learn the product's logic, and helps writers keep help articles aligned with what the product actually does.

The practical pattern is one docs page per major flow: signup, onboarding, checkout, account recovery. Pair each user flow with its technical siblings where they exist, like a sequence diagram showing the API calls behind the checkout, or a C4 model view of the systems involved. UX and engineering views of the same feature belong one click apart.

The blocker has always been maintenance, and this is where text-based flows change the economics. Docsio generates a documentation site from your URL, and Mermaid flowcharts render natively on every page, exactly like the four examples above. You edit the flow as text, through the AI agent or by hand, and the published diagram updates with the page. No export step, no stale PNGs.

If your flows are currently trapped in screenshots, moving them into living docs is a one-afternoon job with a compounding payoff.

FAQ

Is a user flow the same as a flowchart?

No, but they are related. A flowchart is the general notation for mapping any process, from algorithms to factory lines. A user flow is a flowchart applied to one specific subject: a person moving through a product to complete a task. Every user flow is a flowchart; most flowcharts are not user flows.

What are the 7 standard symbols of a flowchart?

The classic set is the oval for start and end points, the rectangle for process steps, the diamond for decisions, the parallelogram for input and output, arrows for direction, the circle for on-page connectors, and the double-edged rectangle for predefined sub-processes. Most user flows need only the first five.

Where can you make user flow diagrams?

Canvas tools like FigJam, Miro, Lucidchart, and Whimsical work well for collaborative drawing sessions. For diagrams that live in documentation, Mermaid is the better fit because flows stay editable as plain text. Docsio renders Mermaid flowcharts natively in generated docs sites, so published diagrams update whenever the text changes.

What is a good user flow example?

A password reset flow is the best learning example. It is short, universally familiar, and still forces you through the hard parts: a decision node, a loop for expired tokens, and a security rule that hides whether an account exists. If your diagram handles those three, you understand the technique.