Designers often reach for the wrong tool. A team trying to understand why users churn documents a user flow and gets a technically correct answer to the wrong question. A team shipping a checkout redesign produces a journey map and ends up with a beautiful artefact nobody references.
What a User Flow Is
A user flow is a step-by-step diagram of the path a person takes through a product to complete a specific task. It maps screens, decisions, and transitions. The unit of analysis is the product: what does the interface do at each step, and what can the user do in response?
Scope is tight by design. “User adds an item to cart and checks out” is a valid flow. “User’s relationship with e-commerce” is not specific enough to be useful. That constraint is a feature. It forces the team to be precise about what they’re actually building.
Typical elements: an entry point, screens or states, decision branches for the happy path and error cases, and exit points. Figma, Lucidchart, or a whiteboard all work. The tool matters less than the discipline.
What a Journey Map Is
A journey map visualises a person’s experience across a broader stretch of time. It captures actions, but also thoughts, emotions, pain points, and the mix of channels and touchpoints involved.
Journey maps aren’t anchored to the product. They span the full context: a search, a phone call, an inbox, and a product interface might all appear in the same map. The unit of analysis is the human experience, not the interface layer.
That wider canvas comes with a trade-off. Journey maps are less precise and harder to act on directly. They answer “where does the experience break down?” more reliably than “what should appear at step four?”
The Key Difference
A user flow tells you how your product works. A journey map tells you whether your product fits into someone’s life.
Both are valid. They answer different questions. Using the wrong one doesn’t waste just time; it can send a team in entirely the wrong direction.
When to Reach for Each
Use a user flow when you’re designing or auditing a specific task path. Situations where they work well:
- Mapping a new feature before wireframing starts (see wireframing vs prototyping for what comes next in that sequence)
- Auditing an existing flow for drop-offs, redundant screens, or dead ends
- Aligning a product and engineering team on what happens at each screen, especially around error states
- Running a design sprint where the team needs to agree on scope before building anything
If your team can’t agree on what a user flow should look like, that disagreement is useful. It surfaces misaligned assumptions before a single line of code is written.
Use a journey map when the problem is broader than any single feature:
- You’re launching a new service and want to understand how people currently solve the problem without you
- Post-launch data shows a drop-off but it’s unclear whether the issue lives inside the product or before it
- You’re in discovery, before committing to a design direction (see UX research methods for the toolkit that feeds a good map)
- The product spans multiple touchpoints and something is falling through the gaps between them
Journey maps are most useful before screens exist. They reframe the question from “how do we improve the interface?” to “where does the actual problem live?” Sometimes the answer is the interface. Often it isn’t.
How to Build a User Flow
- Define the task precisely. “User resets their password” is a task. “User manages account settings” is too broad to flow properly.
- Identify the entry point. Where does the user start? A homepage, an email link, a push notification? Each creates a different starting assumption.
- Map the happy path first: the ideal route from entry to task completion, no friction, no errors.
- Add the error branches. What happens when the user enters the wrong password, misses a required field, or the session times out?
- Use a consistent notation throughout: rectangles for screens, diamonds for decision points, rounded nodes for start and end.
- Hand the completed flow to someone who wasn’t in the room when you drew it. If they misread a branch, the flow is ambiguous, not the reader.
How to Build a Journey Map
- Fix the scope before anything else. One persona, one scenario. “A first-time buyer completing a purchase” is workable. Mapping all users in a single diagram collapses into noise.
- Define the time horizon. Does the map cover a five-minute task or a three-month onboarding arc? Both are legitimate; just pick one and stay in it.
- List the stages chronologically and keep them high-level: Awareness, Consideration, Purchase, Onboarding, Return.
- For each stage, document what the user is doing, what they’re thinking, and how they’re feeling. Base this on interview data, not team assumptions. Techniques like card sorting and tree testing can validate the mental model assumptions embedded in your stage labels.
- Mark pain points prominently so they stand out in review. They’re the reason you built the map.
- Add opportunities alongside each pain point. A journey map without actionable opportunities is a record of problems, not a design tool.
Where Both Tools Break Down
A user flow built around how a product was intended to work, rather than how it actually works, is a fiction. A journey map built from team assumptions instead of user interviews is equally fictional. Both are still useful as hypothesis documents, but label them as such until research confirms the picture.
The artefacts don’t create clarity on their own. What creates clarity is the conversation that happens when the team reviews them together out loud.
How Strynal approaches user flows and journey maps
At Strynal, these two tools serve different phases of a project. Journey maps come in during discovery, when we’re figuring out what problem is actually worth solving. User flows come in when we’re making UI/UX design decisions, scoping features, and preparing handoff to engineering.
The most useful thing either artefact does is make assumptions visible. Journey maps prompt people in the room to say “that’s not quite right,” which often changes the design direction entirely. User flows expose error-state assumptions that engineering hasn’t planned for.
Build them lean enough to update as you learn, and they’ll stay useful throughout a project rather than going stale after the first sprint. If you’re unsure which tool fits your current stage, get in touch and we’ll tell you honestly where to start.