Seven flowchart mistakes that make processes harder to understand

A bad flowchart is worse than no flowchart. It looks authoritative, so people trust it, and it is wrong or ambiguous in exactly the places where the process is hardest: the exceptions, the handoffs, the moments where someone has to decide. Readers come away believing they understand a process they do not.

The mistakes are remarkably consistent. The seven below cover most of what goes wrong, and each one has a quick way to spot it and a concrete fix. Throughout, we will use the same example: a first draft of an expense claim process, drawn by someone in finance who knows it well, which is the root of most of its problems.

1. Decision branches with no labels

The expense draft has a diamond reading "Receipt attached?" with two lines leaving it, one going down to "Check amount" and one going right to "Return to claimant". The author knows which is Yes. A new member of the finance team might guess correctly. They should not have to guess at all.

How to spot it

Look at every diamond and count the lines leaving it. Every one should carry a word. Pay particular attention to diamonds with three or more exits, where a missing label is easier to overlook and harder to infer. Check the lines that loop back, too: a branch that returns to an earlier step is still a branch and still needs its answer written on it.

How to fix it

Label every branch, even the obvious ones. Yes and No, or Approved and Rejected, are better than inventive alternatives because readers recognise them instantly. Where a decision has several answers, make sure they are exhaustive and cannot overlap: "Under £50", "£50 to £500" and "Over £500" leave no gaps, whereas "Small", "Medium" and "Large" invite argument.

2. Questions nobody can answer

The second diamond in the expense draft reads "Reasonable?". Two managers would answer it differently for the same claim, which means the diagram has not described a process. It has described a judgement and hidden it inside a shape that implies a rule.

How to spot it

For each decision, ask what information the person at that point would use to answer it. If the answer is "their experience" or "it depends", the question is too vague. Words like OK, appropriate, reasonable and valid are warning signs. So is a diamond holding an action, such as "Review claim", which is a step pretending to be a question.

How to fix it

Rewrite the question around the actual test: "Within the expenses policy limits?" or "Over £500?". If there genuinely is a judgement call, draw it honestly as a step, "Manager reviews claim", followed by a decision about the outcome, "Approved?". The judgement is still there, but now the diagram admits who makes it.

This mistake matters more than it looks. A vague decision in a flowchart tends to become a vague decision in the real process, applied inconsistently by whoever happens to be on duty. Forcing the question into a testable form is often the first time anyone has written the rule down.

3. Paths that go nowhere

In the draft, "Return to claimant" has no line out of it. What happens next? Does the claimant resubmit, and if so, where does the resubmission enter? Does the claim expire after a month? The diagram is silent, which usually means the process is too.

How to spot it

Find every box with no outgoing line that is not a terminator. Each one is either a missing end or a missing connection. Then look the other way: any step with no incoming line cannot be reached at all, which is often a leftover from an earlier version.

How to fix it

Follow each path until it reaches an explicit end state. "Return to claimant" should either loop back to "Claim submitted" or end at a terminator such as "Claim withdrawn". If you cannot decide which, you have found a gap in the process itself, and that is the most useful thing the diagram will tell you. Write it down and take it to whoever owns the policy.

Loops can be dead ends in disguise. If "Return to claimant" loops back to submission with no limit, the diagram describes a claim that can bounce forever. That may be true, but it is worth deciding deliberately. A loop needs a way out: a counter, a deadline or a decision that eventually routes somewhere else, such as "Resubmitted within 30 days?".

4. Only drawing the happy path

Some drafts take the opposite approach to dead ends: they simply leave out every route that is not a success. The expense process goes from submitted to checked to approved to paid in four tidy boxes. It is easy to read and of little use, because nobody needs a diagram to understand the case where everything works.

How to spot it

Count the terminators. A process with only one end almost certainly has missing failure paths. Then ask the people who do the work what goes wrong most often, and look for it on the diagram.

How to fix it

Add the exceptions that change what happens next: rejections, missing information, failed payments, retries. Draw each to its own end, and keep them visually to the side of the main path so the normal case is still easy to trace. Leave out exceptions that do not change anyone's next action; a claimant who submits on a Sunday is not a separate branch.

5. Mixing levels of detail

The expense draft has a box reading "Approve" next to a box reading "Open the finance system, search by claimant ID, match receipt total to claim line, and flag mismatches in column F". One is a summary of a manager's decision; the other is a set of keystrokes. The diagram cannot decide what it is for.

How to spot it

Look for labels that are much longer than their neighbours, labels that mention screens, fields or buttons, and boxes that would take very different amounts of time. Ask whether each box could reasonably be one person's single piece of work.

How to fix it

Choose one altitude and rewrite every box at that height. The keystroke-level box becomes "Match receipt to claim". If the detail matters, put it in a separate diagram or a written procedure and reference it, rather than inflating one step until it dominates the chart.

The opposite slip happens too: a box so high-level it hides the process. "Finance processes claim" might cover six steps and two decisions. If the people reading the diagram need to know what happens inside that box, it needs opening up.

6. Flow that wanders and lines that tangle

The draft starts at the top left, runs down, then turns right because the page ran out, then comes back up to reach the approval step that was added later. Three lines cross in the middle. The process is not complicated; the drawing is.

How to spot it

Trace the main path. If your finger changes direction more than once, or if you cannot tell at a glance which way an arrow is going, the layout is working against the reader. Count crossings: one or two may be unavoidable, but a cluster of them means steps that interact are drawn far apart.

How to fix it

Pick a direction, top to bottom or left to right, and make every forward line follow it. Keep backward lines for genuine loops, so they stand out. Put the common case on a straight spine and move exceptions to the sides. Running an automatic layout is a good first pass; adjusting by hand afterwards usually produces the clearest result.

Late additions cause most of this. When a step is added after the first draft, it gets squeezed into whatever space is free, and the lines bend to reach it. After any significant edit, step back and look at the whole chart again rather than only at the part you changed. Re-laying it out from scratch takes a minute and often removes crossings that had built up over several revisions.

7. One diagram doing the work of three

The final version of the expense draft also covers corporate card reconciliation, mileage claims and the monthly payroll run, because they all involve expenses. It now has forty boxes, two start points and lines that leave the page. Nobody reads it end to end, which defeats the purpose.

How to spot it

More than one genuine start event is the clearest sign. So is a chart that cannot be read at one screen's zoom, or a section with its own owner, trigger and failure modes that only connects to the rest at one point. Off-page connectors are often a symptom: the author has noticed the diagram is too big and is working around it.

How to fix it

Split it. Each process gets its own diagram with its own name, and where one hands off to another, show that as a single step, "Add to payroll run", that points to the other diagram. If the real story is who does what across departments, consider a swimlane diagram instead, where handoffs become visible as lines crossing lanes.

A checklist before you share

Run through this on any flowchart before it goes into a document, a wiki or a meeting. Most checks take seconds, and the ones that take longer are usually finding a real gap in the process.

Some of this can be checked for you. In DiagramDock, the flowchart suggestions panel flags unlabelled decision branches and steps that cannot be reached from the start. It is advisory and never changes the diagram, so you decide what to fix. One-click Yes, No, Approved and Rejected labels make the first mistake quick to correct, and "Arrange diagram" will lay out a tangled chart top to bottom or left to right when you ask, with a single undo if you preferred it before.

The checks a tool cannot do are the important ones: whether a question is answerable, whether an exception matters, whether the boxes sit at one altitude. For those, hand the diagram to someone who was not in the room and listen to where they hesitate.