Flow Mapping
Mapping the actual branching structure of how a product or process works today — every path, fork, dead end, and loop — so you can see the complexity that has quietly accumulated.
Nobody designed the seventeen paths through your product. They accumulated. A flow map is how you finally see them.
What it is
A diagnostic of the current-state topology: every path, every fork, every place the thing has quietly become more complicated than anyone intended.
Flow mapping exposes the actual branching structure of how a product or process works right now. You trace every path a person can take: each step, each decision point, each fork, and you follow every branch through to where it ends. The output is a map of the topology — the shape of the thing — showing not a story about the experience but the mechanical structure underneath it: how many ways in, how many paths through, where they split, where they rejoin, where they stop.
What it reveals is almost always complexity nobody intended. Products and processes are not designed once and left alone; they accrete. A branch is added for an edge case, a workaround becomes a permanent path, a special flow is built for one segment and never removed. Over years, this accumulation produces a structure nobody has ever seen whole, and which nobody would have designed on purpose: a twelve-step path that should be three, a branch that leads nowhere, a loop that quietly traps people, seven different ways to accomplish the same thing. The flow map is how that sprawl becomes visible, because you cannot fix a tangle you have never actually looked at.
This is a diagnostic of the CURRENT state, and that scope matters. Flow mapping is not about designing the ideal future structure — that is the design work that comes after, and it is a different activity. It is about seeing, honestly and completely, what exists today, including the parts that exist only because of history and accident. And crucially, the real flow is almost never the documented flow: the map must capture the workarounds people actually use, the undocumented branches, the paths that were never written down. The documented version is a story the organization tells itself. The real flow is what people do.
The branching topology
Trace the paths. The tangle is the finding.
Click any node, any pathology, or any loop to see what it is and why it matters. The paths in teal are the documented flow. The amber elements are what the documentation does not show — the dead end, the loop, the unintended branch, the redundant route.
When to deploy it
When you need to see the structure honestly, before changing it.
Use Flow Mapping when
- →A product or process has grown complicated over time and nobody can actually describe how it works end to end.
- →You suspect complexity has accreted — many paths, special cases, workarounds — but cannot yet point to where.
- →You are about to redesign or simplify something and need an honest picture of what exists before you change it.
- →People are getting stuck, abandoning, or complaining that something is confusing, and you need to find the structural cause.
- →You are onboarding into an unfamiliar system and need to understand its actual shape.
Do not lean on it when
- ×You want to understand how the experience FEELS over time — that is journey mapping. A flow map shows structure, not emotion.
- ×You want to understand the operational layers behind a service (frontstage, backstage, support) — that is service blueprinting.
- ×The thing is genuinely simple; mapping a three-step linear process produces a three-step linear diagram and no insight.
- ×You intend to map only the documented flow. A flow map of the official version mostly reproduces the organization's own story back to it, missing exactly the accreted mess you were looking for.
The honest limit: a flow map shows you the structure, not why it got that way, and not what to do about it. It is a diagnostic, and a powerful one, but the sprawl it exposes still has to be understood (each branch usually had a reason) and then redesigned, which is separate work. Its most common failure is mapping the flow as documented rather than as lived, which produces a tidy diagram that hides exactly the accreted mess you were looking for.
How it works
Six moves, from bounding the flow to reading its shape as a whole.
Define the boundaries of the flow.
Decide what you are mapping and where it starts and ends: a specific product flow, a process from trigger to outcome. An unbounded flow map sprawls without producing insight. Choose a defined flow with a clear start and end, and then trace it exhaustively — including every branch. A narrow flow mapped completely is far more valuable than a broad one mapped superficially.
Trace every path, not just the happy path.
Start at the entry point and follow each route through, taking every fork. The happy path is the one everyone already knows; the value is in the branches, the edge cases, the exceptions, and the alternate routes. The sprawl hides in the things that were not supposed to be there but are.
Find the undocumented reality.
This is the crucial step and the one that separates a real flow map from a diagram. Talk to the people who actually use or operate the thing, and where possible watch them do it, to find the workarounds, the shortcuts, the paths that appear on no documentation. The real flow is what people do, not what the spec says. People routinely describe the official process while doing something different, often without noticing.
Mark every decision point and fork.
Where does the path split, and on what condition? Decision points are where complexity multiplies, and mapping them precisely is what turns a vague sense of "it's complicated" into a specific, countable structure. Naming the condition at each fork is as important as drawing the fork.
Flag the pathologies explicitly.
Identify the dead ends, the loops, the redundant paths to the same outcome, and the branches that exist only for historical reasons. Naming them explicitly — DEAD END, LOOP, UNINTENDED BRANCH, REDUNDANT PATH — is what makes the map actionable. A tangle that has been named is undeniable in a way that a vague sense of complexity is not.
Read the shape, then hand off to redesign.
Step back and read the topology as a whole: how many paths, how deep, how tangled, where the sprawl clusters. Count the decision points, count the paths to each outcome, count the steps on the longest route. This diagnosis is the deliverable. Designing the simpler future structure is the next, separate piece of work — informed by, but not the same as, this map.
Best practices
What good looks like — and the mistakes that quietly undermine it.
When it goes well
- ✓Every path is traced, not just the happy path. The branches and edge cases are where the finding lives.
- ✓The map captures the UNDOCUMENTED reality — the workarounds, shortcuts, and paths people actually take — not just the official version.
- ✓Decision points and forks are marked precisely, turning "it feels complicated" into a specific, countable structure.
- ✓The pathologies (dead ends, loops, redundant paths, accreted branches) are explicitly flagged, which makes the map actionable rather than merely descriptive.
- ✓The map is read as a whole: the SHAPE of the thing is itself the diagnosis.
- ✓The team resists fixing it while mapping. The diagnostic comes first, honestly; the redesign is separate work.
The mistakes, and how to avoid them
Mapping the documented flow instead of the real one.
The most common and most damaging failure: you produce a tidy diagram of the official version and miss exactly the accreted mess you were looking for. The documented flow is a starting hypothesis, not the map. Go find the workarounds.
Only mapping the happy path.
The happy path is the part everyone already understands. The sprawl hides in the branches, the exceptions, and the alternate routes. If your map has one path through the flow, you have mapped the spec, not the system.
Drifting into redesign while mapping.
The temptation to fix the flow as you draw it corrupts the diagnostic. Map what IS, honestly and completely; design the future structure afterwards, as separate work. Conflating the two produces a map of what you wish existed rather than what does.
Mapping something already simple.
A flow map of a genuinely linear three-step process produces a three-step diagram and no insight. Reserve it for things suspected of tangled complexity — products or processes that have grown over time, that people complain about as confusing, or that nobody can fully describe.
Treating the map as the answer.
The map is a diagnosis, not a prescription. Each branch usually had a reason; understanding why the sprawl accreted is part of deciding what to do about it. The map exposes the tangle. Understanding and redesigning it is the work that follows.
Logistics
Get the people who actually use and operate the thing. Watch them. Make the map big enough to be seen whole.
Get the people who actually use and operate the thing
The undocumented reality lives with the people doing the work: the frontline staff who invented the workaround, the users who found the shortcut, the support team who knows where people get stuck. Their knowledge is the difference between a real flow map and a pretty diagram. No single documentation source contains the full real flow.
Watch, do not just ask
People routinely describe the official process while actually doing something different — often without realizing it. Where you can, observe the flow being used rather than relying on descriptions. This is the same official-version-versus-reality gap that contextual observation exists to close, and it applies here with particular force.
Bound it, then go deep
Choose a defined flow with a clear start and end, and then trace it exhaustively — every branch, every fork. A narrow flow mapped completely is far more valuable than a broad one mapped superficially. Resist the temptation to expand the scope; resist equally the temptation to stop at the documented paths.
Make the map big and visible
Flow maps get large, and their value comes from being seen whole. Give the map room — on a wall or a large digital canvas — so the shape (which is the finding) is legible at a glance. Common formats include whiteboards and digital canvases such as Miro, Mural, Figma, or Lucidchart, named as common examples, not endorsements. The tool is irrelevant; the completeness is everything.
Count things
Quantify the sprawl: how many paths, how many decision points, how many steps on the longest route, how many distinct ways to reach the same outcome. Numbers make an accreted mess undeniable in a way that a drawing alone sometimes does not. "Seven different ways to complete this task" is harder to dismiss than a diagram showing seven lines.
How AI is evolving this method
AI will draw your flow diagram in seconds. It will draw the flow you described, which is exactly the one that is not real.
Toggle between modes to see where AI contributes real drafting speed — and where it is structurally blind at exactly the moment this method most needs sight.
In-depth example
A fifteen-year-old insurance claims process, mapped two ways.
The same process, with the same documentation available in both cases. The difference is whether the team traced the REAL flow — by watching claims handlers work and following actual claims through the system — or generated a diagram from the documentation alone.
Shared scenario
An insurance company's claims process has grown complicated over fifteen years. Customers complain it is confusing, staff have their own ways of getting things done, and nobody in the organization can describe end to end how a claim actually moves through the system. Before redesigning it, the team maps the current-state flow.
Both versions map the same process. Only the method differs.
First: bound the flow and commit to tracing all of it
The team defined the boundaries — from claim submitted to claim resolved — and made the critical commitment: trace EVERY path, not just the one in the process documentation. The documented flow had a handful of steps and two decision points. What they found when they followed real claims through the real system was something else entirely.
Found: multiple undocumented branches
By sitting with claims handlers and watching them work, the team found branches added for edge cases years earlier and never removed. Each had been a reasonable response to a specific situation. Together, they had turned a simple process into a tangle with far more paths than anyone knew existed. None appeared in any documentation because they had grown informally, step by step, each accreting quietly onto the existing structure.
Found: a workaround in daily use that bypassed an official step
Handlers had invented a workaround years earlier because one official step did not work reliably for a certain claim type. The workaround spread by word of mouth and was now used constantly — by handlers who did not even know there was an official step for that case, only that “this is how you do it.” It appeared on no documentation anywhere, because a workaround that bypasses an official process is, almost by definition, not in the official process document.
Found: a loop — certain claims circling between two teams
Certain claim types circled between two teams indefinitely, each team believing ownership lay with the other. Claims in the loop were not rejected and not resolved — they were pending, bouncing, consuming handling time from both teams, and generating a category of customer complaints nobody had been able to trace to a specific cause. The loop was the cause. It was not in any documentation; it had emerged from an ambiguity in the handover rules.
Found: a dead end — a claim type that could enter and simply stall
One claim type could enter a branch from which there was no forward route: no next step, no owner, no way to make progress. Claims that entered it stalled. This explained a category of customer complaints about claims that had simply stopped moving — complaints that support staff could not resolve because they did not know the branch existed, only that the claim appeared to be “stuck.” The dead end was invisible until traced.
The shape itself was the finding
Drawn out whole, the map was startling: what the organization believed was a clean five-step process was in fact a tangle with multiple paths, branches, a loop, a dead end, and a widely-used workaround. The team could count the sprawl, point at the specific dead end causing the stalled-claim complaints, name the loop, and show the redundant routes. None of that could be argued with, because it was simply what was there.
Crucially, they resisted fixing it while mapping. The diagnosis came first, honestly and completely. The redesign was separate work — and far better informed for having an accurate picture of what actually existed, workarounds and all.
Used in these frameworks
Where Flow Mapping shows up — at the understand-and-define moments where the current state must be seen honestly.
Flow mapping is a current-state diagnostic, so it maps to the discover-and-define moments in each framework — the points where understanding the actual structure of something today is the precondition for changing it well.
Related methods
Flow Mapping in context — and the distinctions that make each method irreplaceable.
Sources & further reading
The work behind this method.
Mapping Experiences
James Kalbach (2016)
The definitive guide to the diagrams that map experiences, journeys, and flows, and how to choose between them. Covers journey maps, service blueprints, experience maps, and process diagrams with particular clarity on what each reveals and what each misses — essential background for understanding when to reach for a flow map versus any of the adjacent methods.
This Is Service Design Doing
Marc Stickdorn, Markus Hormess, Adam Lawrence, and Jakob Schneider (2018)
For mapping how services actually operate in practice, including the process-mapping and service-blueprinting methods that complement and intersect with flow mapping. The sections on research in context — watching people work — are directly relevant to the method's most important discipline: finding the undocumented reality.
Learning to See
Mike Rother and John Shook (1999)
The lean classic on mapping the current-state flow of a process before improving it. The central argument — that you must see what is actually there, including every step, every wait, and every path, before you can design the future state — is the same discipline flow mapping applies to products and service processes. The current-state / future-state framing is directly portable.