Your healthcare scheduling app lets patients book appointments in a few taps, and the funnel looks healthy until the insurance step. There, a large share of patients leave and phone the front desk instead. The screen looks fine in design review. The problem is what happens when a patient’s plan is not on the list, and nobody ever drew that branch.
A user flow is a diagram of every step a person takes to complete one task in your product, including the decisions, system responses, errors and ways out. Mapping it shows where people can get stuck before you design screens or write code, and it gives product, design and engineering one shared picture of the task. Drop-off often hides in branches the team never mapped, like the missing insurance plan above.
This guide covers what a flow should include, the notation to use, how to map one step by step, where signup, checkout and onboarding flows usually break, and how to use data and testing to decide what to fix.
What a User Flow Covers, and What It Does Not
A user flow sits between two other artifacts. Your information architecture says where things live. A customer journey map covers the whole relationship over days or months, across channels. A flow zooms in on one task inside the product, from the moment someone starts it to the moment it is done.
That narrow scope is what makes flows useful. If patients cannot find the booking page, you have a navigation problem. If they find it but cannot finish booking, you have a flow problem. Keeping the two apart stops teams from redesigning menus when the real issue is a confusing form.
Flows come in a few levels of detail:
| Type | What it shows | Best used for |
| Task flow | One linear path, no branches | Simple tasks such as changing a password |
| User flow | One task with decisions, alternatives and errors | Signup, checkout, booking, onboarding |
| Wireflow | Wireframes connected by flow arrows | Mobile and multi-step screens where layout affects the path |
User Flow Notation
Use a small set of shapes and apply them the same way every time. Most teams borrow from classic flowcharts:
- Oval: start and end points.
- Rectangle: a screen, page or user action.
- Diamond: a decision, made by the user or the system.
- Arrow: direction of movement, labeled where it leaves a decision.
- Note or callout: system behavior, business rules and open questions.
Label every arrow that leaves a diamond with its condition, such as “Plan accepted,” “Plan not listed” or “Card declined.” Unlabeled branches leave reviewers guessing, and guesses become bugs. If people outside the design team will read the diagram, add a small legend in the corner.
Pair each user action with the system response. “Enters date of birth” followed by “System checks eligibility” is more useful than either alone, because friction often comes from the response: a slow check, an unclear message or a screen that does not confirm success.
How to Map a User Flow Step by Step
1. Pick one task and define done
Choose a single task and one business outcome it supports, such as “Book a first appointment” supporting “more new-patient bookings online.” Then define completion in concrete terms. “User reaches the dashboard” is vague. “Appointment is confirmed and the patient has received a confirmation” is a real end state you can measure.
Write the task, the user type and the end state at the top of the diagram. A flow that tries to cover three tasks at once becomes unreadable.
2. List every entry point
People rarely start a task from your home screen. List the real starting points: an ad, a reminder email, a search result, a push notification, a link from a partner site or a deep link from another screen in the app. Each one brings different context. A patient arriving from a reminder email already has an account. One arriving from a search ad may not know whether you accept their insurance.
3. Draw the main path first
Sketch the most common route from entry to completion on paper or a whiteboard. Keep it rough, because boxes and arrows are faster to argue about than polished screens. Count the steps. If the main path is long, ask which steps could move after completion, merge or disappear.
4. Add decisions and alternative paths
Now mark each point where the path splits. Is the user signed in? Is the insurance plan accepted? Is the chosen time still free? Does this account need admin approval? Each answer becomes a labeled branch that must lead somewhere useful.
5. Map errors and recovery
For every step, ask what can go wrong and what the person sees next. Expired codes, failed validation, declined payments, lost connections and time-outs all need a way forward. A useful rule: no branch should end in a dead end unless the user chose to leave.
Accessibility belongs here too. Errors should be stated in text next to the field they refer to, not signaled by color alone, and every step should work with a keyboard. The Web Content Accessibility Guidelines set out the requirements for error identification and input help.
6. Add the states engineering needs
Before handoff, add loading, empty, success and error states for each screen in the flow. A good test: could an engineer estimate the work from the diagram without asking “what happens if this call fails?” If not, add the missing state. Once the flow is complete, it is ready to become wireframes and then a clickable prototype.
Where Signup, Checkout and Onboarding Flows Break
Most products lose people in the same few places. These are the branches to check first.
Signup flows
Verification is the classic dead end. Someone requests a code, switches to their inbox, gets distracted, returns ten minutes later and finds the code has expired with no obvious next step. Your flow should show a resend option, a clear expiry message, a way to correct a mistyped email and a return to the form with earlier answers kept.
Ask only for what you need to create the account. Company size, role and phone number can often wait until after the user has seen value, or be inferred later. Work with engineering on error wording too: security practice favors messages that do not reveal whether an email address already has an account, and that changes how you design the “forgot password” and “already registered” branches.
Checkout flows
Forcing account creation before payment is a decision point that turns away buyers. Show a guest path next to sign-in, and offer to save details after the order is confirmed.
Map payment failure carefully. When a card is declined, the flow should keep the cart, explain the problem in plain words and let the buyer try another method without re-entering shipping details. People who reach that step have already decided to buy, so recovering them is some of the cheapest revenue you can win back. Our guide to conversion rate optimization for ecommerce covers the wider checkout picture.
Onboarding flows
An onboarding flow should end at the first valuable action, the point where the product proves itself. In a scheduling tool that might be the first booked appointment. In an analytics product, it is seeing your own data in a chart.
Map the shortest route to that moment and move everything else later. Profile photos, notification settings and team invites can wait. Add a skip branch for experienced users and a guided branch for new ones. For the design side of those first sessions, see our guide to SaaS onboarding UX design.
If your product has more than one of these flows losing people and you are not sure which to tackle first, an M7 UX audit starts with a user flow review alongside analytics and user testing, then gives you prioritized fixes with wireframes for the recommended changes.
Finding and Fixing Drop-Off
A mapped flow is a hypothesis. Data and testing tell you which branches matter.
Instrument the flow
Give each step in the diagram a matching analytics event, using the same names in both places. When the funnel report and the diagram line up, anyone can see which box is losing people. Track error events as well as page views, because “card declined” and “code expired” rarely show up in a standard funnel.
Watch people attempt the task
Analytics tell you where people leave. Watching them tells you why. Build a clickable prototype or use the live product, and give participants realistic tasks, including unhappy ones: “Book an appointment with a plan that is not on the list” or “Pay with a card that gets declined.” Small rounds of five or so participants per user type are usually enough to surface the biggest problems, in line with long-standing Nielsen Norman Group guidance. A consistent usability testing process makes rounds comparable over time.
Prioritize by impact and effort
Score each issue on how many people it blocks, how close it sits to revenue and how much work the fix takes. Clear error text, a resend button or a kept form value are often small changes with large effects. Rebuilding payment logic or eligibility checks may be worth it, but needs a business case and a place on the roadmap.
Run a handoff checklist
Before any flow goes to engineering, confirm:
- One task, one user type and one measurable end state are written at the top.
- Every entry point is listed.
- Every decision branch is labeled and leads somewhere.
- Every error has a recovery path.
- Loading, empty, success and error states are shown.
- Accessibility notes cover labels, error text and keyboard use.
- Analytics events are named to match the diagram.
Map the Path Before You Build It
The insurance branch from the opening would have taken a few minutes to draw. Found in production, it cost bookings and front-desk time every day until someone noticed. Mapping the flow before the build is how you catch that kind of miss while it is still cheap to fix.
At M7, our designers map and test user flows before screens are designed, and our engineers review them early to flag technical limits before they turn into rework. If you are planning a new product or rebuilding a key task such as signup or checkout, plan your next flow with the M7 team.
Frequently Asked Questions
When should you create a user flow?
Create one after initial research and before wireframes, when you know enough about users to map real behavior and changes are still cheap. Update it whenever testing or analytics reveal a path you did not expect. A flow that is never updated drifts away from the product.
What is the difference between a user flow and a wireframe?
A user flow shows the sequence of steps and decisions in a task. A wireframe shows the layout of one screen in that sequence. Most teams map the flow first, then wireframe the screens it calls for.
Which tools are good for user flows?
Figma suits teams that already design there, because flows, wireframes and prototypes live in one file. Whiteboard tools such as FigJam or Miro work well for early workshops. Pick something non-designers can comment on and engineers can link to from tickets.
Can you map a user flow for a product that does not exist yet?
Yes. Base it on research into how people complete the task today, whether in another tool, on paper or by phone. Then test the flow with a prototype before writing code.
