By the end of the lesson, you can break a user goal down into steps, decision points, and system states. You understand that a flow is not a sequence of screens, and that without designing the edge cases, even the main path cannot be considered finished.
Why do we need a flow next to the sitemap?
The sitemap shows what exists. The user flow shows how the user moves through it toward a specific goal. Many flows exist on the same sitemap (search, registration, cancellation), and each contains different decision points and exceptions. The flow is needed because it shows where information or a step is missing, before we draw a screen.
What does a user flow depict?
A user flow is the depiction of the steps, decisions, and states leading to achieving a task. The happy path is the most frequent or primary successful task path. Start with the user goal, not with the opening screen. For example: "booking a suitable appointment". Then describe what information they must find, what condition they must select, what the system checks, and how they know it succeeded. If several paths lead to the goal, identify which is the main path, and why.
The notation of a flow
Most diagrams consist of simple symbols (these are also available in FigJam):
Shape
Meaning
Rounded rectangle
Start or end
Rectangle
Step or screen
Diamond
Decision point (question, yes/no)
Arrow
Direction of progress, the condition on the arrow
Three related concepts not to be confused: the user journey (chapter 2) describes the experience with feelings; the user flow the steps and decisions; the wireflow is the flow supplemented with small wireframes (chapter 6).
Decision points and information needs
A decision point is a step where the user or the system chooses from several paths. At every decision point, ask: what information is needed for a good choice, where does it come from, and what happens if it is missing? The step "choose an appointment" is not detailed enough if it does not indicate the free capacity, location, price, duration, or cancellation condition. The flow helps to see if data that would be needed earlier has ended up on a later screen.
Pay special attention to going back and to modification. The user does not always progress linearly: they compare, change their mind, look for data, or abandon the process halfway. A good flow does not punish this, but preserves what is reasonable to preserve, and clearly signals what changes.
Edge cases
An edge case is an error, lack, or alternative situation that changes the continuation of the normal task path. An edge case is not the same as a rare case. If a place runs out, the connection breaks, or the data is wrong, the real situation of the main task changes. In the flow, mark at least the high-impact branches:
no results;
not authorized;
invalid data;
a resource that is no longer available (the places have run out);
an interrupted action (leaving, loss of connection);
successful closing.
Not every exception needs a completely separate series of screens. Some are field-level feedback, others an alternative path or an opportunity to ask for help. What matters is that the user understands what happened, what was kept, and what they can do now. These needs build on the states of chapter 3.
How to make a flow? Steps
Mark the goal and the starting point. What is the user's goal, where do they start from?
Describe the main path step by step.
Look for the decision points. Where do they have to choose, check, enter something?
Give each decision point information (what they know, what they need to know).
Add the exceptional branches according to risk.
Check the end: does the user know whether it succeeded or not?
Flowchart: registering in Mai program
flowchart TD
A(["Goal: register for an event tonight"]) --> B["Choose an event from the list"]
B --> C{"Any places left?"}
C -->|No| D["Recommend similar events"]
D --> B
C -->|Yes| E["Review price and conditions"]
E --> F{"Is registration required?"}
F -->|No| H(["Save details, done"])
F -->|Yes| G["Enter data and submit"]
G --> I{"Did the system accept it?"}
I -->|No| J["Error and a way to fix it"]
J --> G
I -->|Yes| K(["Confirmation and next steps"])
The diagram shows two exceptional branches (no places left, wrong data) and two successful ends (no registration, successful registration). You can notice that even an exceptional branch has an outcome: it is not a dead end.
Worked example: the critical branches of Mai program
The main flow: browsing events → choosing an event → checking the conditions → entering data → submitting the registration → confirmation. The critical branches: the chosen event filled up in the meantime; the user does not accept the cancellation condition; the processing of the registration is delayed; the confirmation email does not arrive. For each, design the information and the next step. This way, in the prototype's test not only the ideal path, but also trust and recoverability can be examined.
Common misconceptions
Claim
Clarification
"The flow is the order of screens."
A flow is a series of steps, decisions, and states belonging to a goal; one step does not always have a separate screen.
"An edge case is rare, it can wait."
The exception changes the real situation of the main task; often that is where the user's trust is lost.
"Every exception needs a new screen."
It can also be field-level feedback, an alternative path, or help.
In brief
A user flow is a diagram of the steps, decisions, and states leading to a goal, starting from the user's goal.
At a decision point always ask: what information is needed, where does it come from, what if it is missing?
Edge cases are part of the main task; mark the high-impact branches.
The user journey is experience, the user flow is step and decision, the sitemap is structure.
Review questions
What are the starting and success states of your main task?
For which decision point is important information still missing?
What happens if the user changes their mind before the last step?
Which exception would have the greatest consequence?
User flows and edge cases
Objectives
By the end of the lesson, you can break a user goal down into steps, decision points, and system states. You understand that a flow is not a sequence of screens, and that without designing the edge cases, even the main path cannot be considered finished.
Why do we need a flow next to the sitemap?
The sitemap shows what exists. The user flow shows how the user moves through it toward a specific goal. Many flows exist on the same sitemap (search, registration, cancellation), and each contains different decision points and exceptions. The flow is needed because it shows where information or a step is missing, before we draw a screen.
What does a user flow depict?
A user flow is the depiction of the steps, decisions, and states leading to achieving a task. The happy path is the most frequent or primary successful task path. Start with the user goal, not with the opening screen. For example: "booking a suitable appointment". Then describe what information they must find, what condition they must select, what the system checks, and how they know it succeeded. If several paths lead to the goal, identify which is the main path, and why.
The notation of a flow
Most diagrams consist of simple symbols (these are also available in FigJam):
Three related concepts not to be confused: the user journey (chapter 2) describes the experience with feelings; the user flow the steps and decisions; the wireflow is the flow supplemented with small wireframes (chapter 6).
Decision points and information needs
A decision point is a step where the user or the system chooses from several paths. At every decision point, ask: what information is needed for a good choice, where does it come from, and what happens if it is missing? The step "choose an appointment" is not detailed enough if it does not indicate the free capacity, location, price, duration, or cancellation condition. The flow helps to see if data that would be needed earlier has ended up on a later screen.
Pay special attention to going back and to modification. The user does not always progress linearly: they compare, change their mind, look for data, or abandon the process halfway. A good flow does not punish this, but preserves what is reasonable to preserve, and clearly signals what changes.
Edge cases
An edge case is an error, lack, or alternative situation that changes the continuation of the normal task path. An edge case is not the same as a rare case. If a place runs out, the connection breaks, or the data is wrong, the real situation of the main task changes. In the flow, mark at least the high-impact branches:
Not every exception needs a completely separate series of screens. Some are field-level feedback, others an alternative path or an opportunity to ask for help. What matters is that the user understands what happened, what was kept, and what they can do now. These needs build on the states of chapter 3.
How to make a flow? Steps
Flowchart: registering in Mai program
flowchart TD A(["Goal: register for an event tonight"]) --> B["Choose an event from the list"] B --> C{"Any places left?"} C -->|No| D["Recommend similar events"] D --> B C -->|Yes| E["Review price and conditions"] E --> F{"Is registration required?"} F -->|No| H(["Save details, done"]) F -->|Yes| G["Enter data and submit"] G --> I{"Did the system accept it?"} I -->|No| J["Error and a way to fix it"] J --> G I -->|Yes| K(["Confirmation and next steps"])The diagram shows two exceptional branches (no places left, wrong data) and two successful ends (no registration, successful registration). You can notice that even an exceptional branch has an outcome: it is not a dead end.
Worked example: the critical branches of Mai program
The main flow: browsing events → choosing an event → checking the conditions → entering data → submitting the registration → confirmation. The critical branches: the chosen event filled up in the meantime; the user does not accept the cancellation condition; the processing of the registration is delayed; the confirmation email does not arrive. For each, design the information and the next step. This way, in the prototype's test not only the ideal path, but also trust and recoverability can be examined.
Common misconceptions
In brief
Review questions