User flow diagram: where the user journey breaks
A user flow diagram is needed not to show the happy path from entry to payment, but to capture drop-off points: places where the user closes the app and does not return.
On the diagram, they are visible only when you draw not just successful transitions but also all alternative branches — usually those are exactly what is missing.
The first place is unhandled screen states. A screen designed for a filled list shows emptiness with no explanation when the server response is empty, an infinite loading indicator on a network error, and a form that silently fails to submit when the session has expired.
Each state must be drawn explicitly: loading, empty, error, offline, no permissions. Otherwise the user decides the app is broken and leaves.
The second is a navigation break. Following an external link does not restore the required screen stack, the Back button returns to the wrong place the user came from, and a pop-up window covers the return point. On the diagram this is a broken arrow on an intermediate screen, and in the app it is a dead end.
The third is loss of context on return. Catalog filters, scroll position, entered but unsent data: if all this resets after returning from a detail screen, the path has to be taken again, and on the second round some users no longer stay.
A separate group is repeated actions: double-tapping the confirmation button, resubmitting on a poor network. Here the path breaks not because of the interface, but because of the absence of duplicate protection and a clear message that the operation is already in progress.
We examine how such drop-off points are found and closed before release, not based on complaints in reviews.
What a well-developed screen and transition scheme gives
A single screen and transition scheme is not a picture for a report, but a working contract between product, design, and development.
While use cases live in chat threads and people's heads, each participant keeps their own version, and discrepancies surface during the build, when a fix costs the most.
The scheme (user flow diagram) captures entry points, forks, and dead ends before the code is written, and lives in a single file in Figma — the whole team sees edits immediately. What this gives in measurable terms:
- The number of steps to the goal is reduced by 1–3: extra confirmation screens, duplicate entry points, and intermediate states are removed at the scheme stage.
- The share of completed actions grows: abandoned sessions at forks are visible before release, not after install reports.
- Time for coordinating edits drops severalfold: one version of the scenario is discussed, not three contradictory mockups.
- Use cases are covered in full: every screen state — loading, empty list, error — has a described transition.
- Acceptance runs along ready-made routes: the reviewer walks the scenario according to the scheme and immediately names any discrepancy with the implementation.
- A new engineer gets up to speed faster: the scheme answers questions that would otherwise be asked one by one in chat.
The result is that the team spends time on implementation, not on figuring out how the product should work.
Comparison of approaches: diagram, prototype, screen map
Three artifacts solve different tasks and often go together rather than instead of each other. The scenario diagram answers the question of which behavior branches exist; the screen map shows what the app consists of; the clickable prototype shows how it feels in the hand. What is needed right now depends on which unclear question you are closing.
The cost of an error grows at each step: a discrepancy in branches in the transition scheme is fixed in minutes, while the same omission found in the build entails reworking navigation, screens, and state logic. That is why we capture logic with a diagram and test disputed places with a prototype.
| Option | When it fits | Limitations of the approach |
|---|---|---|
| Scenario scheme (diagram) | Multiple roles, branching, recovery after failure, order statuses and integrations | Does not show screen layout and transition cost; only readable with a walkthrough |
| Screen map | An app with dozens of screens, a navigation audit and duplicate search are needed | Does not describe transition conditions and state logic |
| Clickable prototype | Testing the key path with people: first launch, payment, disputed gestures | More expensive to maintain, quickly becomes outdated, rare branches cannot be tested in it |
In practice, this is not a choice of one option but a combination: the diagram remains the source of truth for logic and survives dozens of edits, the screen map serves as a registry for design and acceptance, and the prototype covers two or three critical paths.
We keep platform guidelines — Material Design and Human Interface Guidelines — as a frame, but make decisions based on your scenarios.
How we design the user journey: work stages
User journey design happens before the first line of code: the diagram (user flow diagram) captures where a person enters the app, what they see on each screen, and at what moment they close it.
Without it, decisions are made by taste, and the gap between the idea and the implementation surfaces during acceptance, when a rework costs the most.
- Review of the current journey. We collect analytics data, session recordings, and support requests: we find the screens users leave from and the steps where they go back.
- State map. We describe each screen, transition and return conditions, as well as empty and error states and offline behavior.
- Journey scheme. We bring everything into a diagram: entry points, alternative branches, dead ends, forks after authorization and checkout.
- Transition validation. We run real scenarios — first launch, re-entry, access recovery, action cancellation — and fix the scheme where the logic breaks.
- Scheme approval. We review the diagram with product, design, development, and support; we resolve comments with edits in the scheme, not arguments at release.
- Documentation handoff. We deliver an editable diagram, a transition table, and a list of analytics events tied to journey steps.
The diagram stays alive: new scenarios first go into the scheme and only then into code — the journey does not sprawl, and fresh screens do not turn into dead ends.
What the team receives: schemes, rules, documentation
At the output, the team receives a fixed set of artifacts, not verbal agreements in chat. Each lies in the project repository and is versioned together with the code: you can see which version of the scheme was in use at release time and what exactly changed in it.
- Navigation scheme — a single diagram of user flows with transitions, alternative branches, returns, and exits to external apps. It immediately shows whether a screen is left without an incoming transition.
- Scenario descriptions — step-by-step sequences of actions with branching points, transition conditions, and the expected interface response at each node.
- Screen state rules — for each screen, loading, empty list, network error, no permissions, offline, and session loss are listed. This removes most disputes during acceptance.
- Role and access matrix — which set of screens and actions each role sees, including edge cases such as changing roles without restarting the app.
- External entry map — deep links, pushes, and widgets: which screen each of them leads to when the app is running and when it is closed.
- Edit policy — who initiates a scheme change, who approves it, how the version is marked, and how a discrepancy between already written code and the updated scheme is recorded separately.
- Development documentation — screen specifications, required and optional fields, server exchange formats, and a list of states used to build automated checks.
Case study: we cut registration drop-off almost in half
A grocery delivery service came with this task: installs are growing, but fewer than a quarter of users reach their first order.
We analyzed the journey using analytics events and session recordings: the scenario took nine screens, and before a person saw the catalog, they were asked to confirm their phone, enter an address manually, choose a payment method, and allow notifications.
Every extra step before value cut the flow — about a third of those who started dropped off at phone confirmation.
Where users were lost
The redesigned scenario was called “First order”: registration became part of checkout rather than an entry barrier. The shifts by journey segments are in the table.
| Journey segment | Before | After |
|---|---|---|
| Start → phone confirmation | 71% | 88% |
| Confirmation → delivery address | 54% | 82% |
| Address → first order | 39% | 63% |
| Entire journey to order | 22% | 41% |
What we changed in the journey
Phone confirmation was moved after product selection, the address was prefilled from geolocation with manual editing, payment came after cart assembly, and the notification request was moved to the delivery waiting screen.
We added a progress indicator and state saving: if the app was closed or a call interrupted, the user returns to the same step instead of starting over. We separately fixed the failure with cart loss on restart — it accounted for a noticeable share of support requests.
Result of the first cycle: registration drop-off was cut almost in half, the share reaching the first order grew from 22 to 41%, and the share of returning users also grew.
We lock in the same journey map and set of metrics before work starts — so the result is measured, not debated.
How a screen map differs from a prototype and a mockup
A screen map (user flow diagram) captures only movement logic: which screens exist, what the user does on each, and where the route branches — whether they are authorized or not, whether there is an item in the cart.
Appearance, colors, and spacing are not part of it, and this is intentional: the map can be rewritten entirely without touching the rest of the documentation.
A prototype is a clickable wireframe on which the scenario is tested in motion: confirming the order of steps, the number of actions to the target screen, and the points where the user hits a dead end.
Typography and brand graphics are deliberately not fixed here, otherwise a dispute about the meaning of the scenario is replaced by a dispute about a button.
A mockup is the visual layer: grid, typography, element states — default, pressed, empty, error, loading. It does not describe the route: from a mockup you cannot tell whether the user will go back after a failed payment. It is assembled only after the map and prototype have stopped changing.
The boundaries of the artifacts are derived from one question — what the document fundamentally does not capture: the map is silent about appearance, the prototype about style, the mockup about the route.
Hence the creation order: first the screen map, then the prototype, then the mockup. The reverse order forces you to redraw the most expensive layer — the visual one — for every scenario change.
Common technical doubts before starting work
Before starting, the same doubts almost always come up: whether the scheme will have to be redrawn for a released app, how much time it will take from our team, and whether the detail will be enough to hand the work over further. Below are answers that determine the scope of work and the boundaries of responsibility.
A path scheme is not a one-off document but a working transition map: when screen logic changes, the branch is updated, and this is recorded in the source file, not in chat.
The app is already released — should we draw the scheme from scratch?
No. We reconstruct the current user flow diagram from product behavior: screen navigation, support requests, completed scenarios. You can see which branches actually work and which became unreachable after previous improvements.
How much time will be required from our team?
One subject matter expert and two or three short meetings: to confirm state logic, branch priority, and back-step return rules. After that, we rely on documentation and support without distracting developers.
Will the level of detail be enough for development to proceed without guesswork?
Every node gets states: empty screen, loading, error, no network or permissions. We check that the scheme unambiguously shows where the user lands after a payment decline and how they return to the main route.
What will the team that takes over the project after us receive?
The diagram source file, a transition table, and state descriptions. The new team restores context in days instead of weeks of interviews, and discrepancies with the scheme are visible at the estimation stage, not at release.
Let's discuss the task and come back with an estimate and plan
To base the timeline estimate on facts rather than assumptions, we start with the current state of the scenarios: which screens already exist, where the user leaves, and which steps duplicate each other.
It is enough to describe the task in free form — we will ask the substantive clarifying questions. The more complete the input data, the fewer assumptions in the diagram and the more realistic the work plan.
What is worth sending along with the task description:
- A list of key scenarios in priority order: entry and registration, checkout, repeat request, access recovery.
- A map of screens and transitions: what is already implemented, what exists only in mockups, where logic diverges between platforms.
- Exit points: at which step users abandon the scenario and by which events this is visible in analytics.
- Roles and states: guest, authorized, subscriber, blocked, offline mode.
- External dependencies: authorization, payments, notifications, integrations with internal systems.
- Markup of target actions: what we consider the result of a step and which events need to be tracked.
- References and constraints: examples that fit or absolutely do not fit, requirements for behavior on low-end devices.
Based on this data, we assemble a user scenario diagram, coordinate it with you, and only after that fix the scope of work. Then you receive a stage-by-stage timeline estimate, an action sequence, and a list of decisions that need to be made before the project starts. Describe the task — we will come back with an estimate and a plan.