How to make a flowchart that people actually follow
Published . By the DiagramDesk team.
A practical seven-step method for drawing a flowchart, from picking the boundaries to testing it on three real cases and dating it.
Most bad flowcharts are not badly drawn. They are badly scoped: they start in the wrong place, try to cover four processes at once, or describe what is supposed to happen instead of what does. Getting those decisions right first makes the drawing part easy.
1. Decide where it starts and stops
Before any shape goes down, write two sentences: what triggers this process, and what has to be true for it to be finished.
“Starts when a customer submits a return request. Ends when the refund is confirmed or the request is rejected.” That single line does more for the diagram than any shape choice. It tells you what belongs in the chart and, more usefully, what does not.
If you cannot write those two sentences, you are looking at more than one process.
2. List the steps before you draw them
Write the steps as a plain list, in order, in whatever tool you write lists in. Ten to twenty is usual for a one-page chart. If you are past thirty, split it.
Doing this first stops you from committing to a layout before you know how much has to fit on the page, which is the usual reason a chart ends up cramped in one corner.
3. Find the decisions
Go through your list and mark every point where the path could go more than one way. These become diamonds. Each one needs a question with a small set of answers, and every answer needs somewhere to go.
Watch for the steps that look like actions but are really questions. “Verify the address” sounds like a process box, but if a failed verification changes what happens next, it is a decision.
4. Draw the main path first
Lay out the route a case takes when nothing goes wrong, in a straight line down or across the page. Get that reading cleanly before you add anything else.
This is worth being disciplined about. A chart whose happy path runs straight down the middle is readable even when it has a dozen branches hanging off it. A chart drawn branch-first is a tangle from the start.
5. Add the branches
Now hang the exceptions off the main path. Label every branch. Where a branch rejoins the main flow, bring it back into the line rather than duplicating the steps.
Rework loops — arrows that go backwards — are worth drawing honestly even though they make the picture messier. An arrow going back up the page is the diagram telling you something true about the process.
6. Test it on three real cases
This is the step people skip and it is the one that finds the problems. Take three real examples, ideally including one that went wrong, and walk each through the chart.
You are looking for: a case that reaches a dead end, a decision with no branch for what actually happened, and a step everybody does that is not on the chart at all.
7. Give it a title and a date
A chart with no date gets trusted long after it stopped being true. Put the process name and the month somewhere on the canvas.
How much detail?
One page. That is the whole rule.
If it will not fit on one page at a readable size, you either have several processes, or you have gone a level too deep. The fix is a predefined process box pointing at a second diagram, not a smaller font.
A useful test: could somebody who has never done this task follow the chart and get it right? If yes, it is detailed enough. If they would need to ask one question, add that. If they would need to ask ten, you are trying to replace training with a diagram.
Common traps
Drawing the official process instead of the real one. The value is usually in the gap between them. Draw what happens, then draw what is supposed to happen, and put the two side by side.
Everything in one chart. Sign-up and cancellation are two diagrams. Putting them together makes both unreadable.
No owner on any step. If who does a step matters, use a swimlane diagram instead and put each step in its owner’s lane.
Draw one now
Free, no account, and nothing you draw is uploaded.