Business Process Expert·7 min read
The explosion point
Every BPMN diagram has an explosion point - the moment when adding one more element makes the entire diagram unreadable. For most people, this happens around 15-20 tasks. The happy path was clean. Then exceptions were added. Then edge cases. Now the diagram is, as one practitioner described it, a spiderweb from a horror movie.
The diagram is not the problem. The approach is. Here are five techniques that prevent the explosion.
"I review hundreds of student diagrams per year. The readable ones share one trait: they flow left to right with no exceptions crossing back over the happy path. The moment a flow goes backward, the diagram becomes a maze."
Technique 1: Collapsed sub-processes
If a group of tasks represents one logical step, collapse them into a sub-process. The parent diagram stays clean. The detail is one click away.
Rule of thumb: if the parent diagram has more than 15 elements, something should be a sub-process.
Before: 8 tasks for "Verify Customer" cluttering the main diagram.
After: One collapsed sub-process labeled "Verify Customer" with a [+] marker. Clean.
Technique 2: Happy path first, exception layers
Model the happy path as the main horizontal flow. Exceptions branch downward. This creates a visual hierarchy: the reader's eye follows the main flow, and dips into exceptions only when needed.
Never let exception flows cross back over the happy path. If they need to rejoin, bring them back underneath.
Technique 3: One decision per gateway
A gateway with 5 outgoing paths is unreadable. Split it into chained gateways: first check A (2 paths), then on one path check B (2 paths). Each gateway answers one question.
Technique 4: Consistent flow direction
Left to right. Always. No zigzags, no flows going backward (use link intermediate events for that). No vertical main flows unless the entire diagram is vertical. Consistency lets the reader predict where to look next.
Technique 5: Name everything
Every task: verb-noun ("Review application"). Every gateway condition: labeled on the outgoing flow. Every lane: role name. Every sub-process: what it does. A well-named diagram is readable even if the reader does not know BPMN.
A diagram where a reader must ask "what does this box mean?" is a diagram that failed its purpose.
The real test
Show the diagram to someone who was not in the room when it was created. If they can follow the main flow without explanation, it passes. If they need a guide, it is too complex. Simplify until it speaks for itself.
Related guides
Keep learning
Frequently asked questions
How many tasks should a BPMN diagram have?▼
15-20 at the top level. If you have more, some steps should be collapsed sub-processes. The goal is readability - if it does not fit on one screen, simplify.
What makes a BPMN diagram hard to read?▼
Crossing flows, inconsistent direction, unnamed elements, too many elements on one level, and exception paths that zigzag across the happy path.
Should I use auto-layout?▼
For drafts, yes. For final diagrams, manual adjustment usually produces better results because you can optimize the visual hierarchy - happy path prominent, exceptions secondary.