The one idea
A diagram is good at showing relationships. Text is good at showing reasoning.
If the hard part of what you are explaining is what connects to what, in what order, or where something sits — draw it. If the hard part is why, what it means, or what to do about it — write it.
Most confusing documents are relationships explained in prose. Most confusing diagrams are arguments drawn as boxes.
Draw it when the question is "what connects to what". Write it when the question is "why".
Match the shape of the diagram to the shape of the question: sequence, structure, time, or comparison. Then keep it under about seven boxes.
A diagram encodes relations spatially, letting the reader answer connectivity questions by inspection rather than by holding state in working memory.
Which kind to draw
| The question | The diagram | Reads as |
|---|---|---|
| What happens, in what order? | Flowchart | Steps and decisions, one direction |
| What talks to what? | System map | Components and their connections |
| What happened when? | Timeline | Events along a line |
| What changed? | Before / after | Two states, side by side |
| Where does this sit? | Hierarchy | Levels of containment |
| How do these compare? | Table | Rows and columns |
Choosing wrong is the most common failure. A flowchart drawn for a comparison becomes a maze; a timeline drawn for a decision process leaves nowhere to put the branch.
Pick the diagram from the question, not from what you know how to draw.
The rules for a readable diagram
Five rules. They are unglamorous and they carry almost all of the readability.
One direction of flow. Left to right, or top to bottom. Pick one and never reverse it. An arrow going backwards is the single fastest way to lose a reader — they stop reading the diagram and start decoding it.
Consistent shapes, each meaning one thing. Rectangle for a step, diamond for a decision, cylinder for storage. What the shapes are matters less than that each one always means the same thing. Two rectangles meaning different things is worse than no shapes at all.
Label the arrows. An unlabelled arrow says "these are related", which the reader already assumed. A labelled arrow says how: "sends invoice", "if rejected", "reads from". Arrow labels carry more meaning per pixel than anything else in a diagram, and they are the thing most often left out.
About seven boxes, maximum. Beyond that, comprehension falls off sharply. If you have twelve, you have two diagrams: an overview, and a detail view of one box. That split almost always improves both.
A title that states the question it answers. "How an expense claim gets approved" beats "Expense Process". The reader knows immediately whether this is the diagram they need.
An onboarding document explains in prose which system a new joiner is added to, by whom, and in what order. Nine paragraphs. Everyone asks HR anyway.
Replaced with six boxes, arrows labelled with who does it, one direction, left to right. Questions to HR drop, because the answer is now visible rather than reconstructable.
Revising a process for an exam. Writing it as prose is re-reading. Drawing it as a flowchart forces you to decide the exact order and the exact branch conditions, and you discover the two places you did not actually know.
Drawing is a comprehension test disguised as a summary, which is why it is a better revision method than highlighting.
Drawing one that works
1 of 6Write the question the diagram answers, in one sentence.
"Which team approves an expense claim, and in what order?" This becomes the title, and it decides everything else. Without it you will draw everything you know, which is how diagrams get to twenty boxes.
Try this
Turn this into a diagram specification — boxes, arrows and labels — without drawing anything.
"A customer submits a support ticket. It goes to the support team. If it's a billing question they pass it to accounts, otherwise support handles it. Either way, once it's resolved the customer gets an email. If the customer replies, the ticket reopens and goes back to support."
Your challenge
Level 3 · IndependentTake something you explain repeatedly in words — a process at work, how a system you use fits together, how a decision gets made — and draw it.
You have succeeded when: it has a title stating the question it answers; every arrow is labelled; it has seven boxes or fewer; the flow goes one way; and a person who does not know the process can describe it back to you correctly with no explanation from you.
That last criterion is the whole test. Everything else is how you pass it.
What people usually get wrong
- Too many boxes. Past about seven the reader stops following and starts scanning. Split into an overview and a detail.
- Unlabelled arrows. They tell the reader that things are connected, which they had already worked out. The label is the information.
- Multiple directions of flow. Arrows going left, right, up and down turn a diagram into a puzzle.
- Shapes that mean nothing consistent. If a rectangle is a step here and a system there, the shapes are decoration.
- Drawing the diagram you know how to draw. A flowchart for a comparison is the classic case. Match the diagram to the question.
- Colour carrying meaning alone. Some readers cannot distinguish the colours, and printed or projected it may vanish. Add a label or a shape difference.
- No text alternative. A diagram carrying information needs a described equivalent, or it excludes anyone using a screen reader.
How someone experienced does it
Experienced people draw the diagram to find out whether they understand something, not to explain something they already understand. Prose lets you write "and then it goes to the relevant team", which sounds fine and hides that you do not know which team. A diagram forces you to draw an arrow to a specific box, and you cannot fudge it.
They also draw the overview first and refuse to add detail to it. The temptation is always to include the exception, the edge case, the special path for one client. Each addition costs every future reader a little clarity to serve a case that arises rarely. Put the exception in a second diagram, or in a sentence underneath.
And they keep diagrams in a format that can be edited by someone else. A diagram that only exists as an exported image in a slide deck stops being updated within a month, and then it is worse than nothing — because people trust it and it is wrong.
When not to use this
Do not draw a diagram when:
- The relationship is simple. Two things connected is a sentence. A diagram for it is ceremony.
- The hard part is the reasoning. Why a decision was made, what a rule means, what the trade-offs are. Boxes cannot argue.
- The information is a list. Lists are lists. Arranging them in a circle with arrows adds nothing.
- It will be out of date next week. An unmaintained diagram is confidently wrong, which is worse than absent.
Prove it
Take a process you have explained in writing and redraw it. Show both to someone who does not know it, in either order, and ask them the same question about it.
Time both answers. The gap is the value of the diagram — and if there is no gap, you have learned that this particular thing was better as prose, which is worth knowing too.
Keep learning this
Paste this into any AI assistant. It turns the assistant into a tutor that tests you instead of just answering you.
Act as an experienced practitioner who is good at teaching. I have just learned making clear diagrams and choosing when to use one. Assume I am intelligent but relatively new to this — treat me as intermediate level. Work through this in order, and wait for my reply at each step: 1. Ask me 5 questions that test whether I actually understood making clear diagrams and choosing when to use one. Do not reveal the answers yet. 2. After I answer, tell me which parts I got right, which I got wrong, and which I only half-understand. Explain only what I misunderstood — do not re-teach what I already know. 3. Give me one practical challenge based on something I could genuinely encounter at work or in daily life. Do not solve it for me. 4. Evaluate my solution the way an experienced person would judge it, including what a professional would have done differently. 5. Tell me what to learn next, and why that comes next. 6. Give me trustworthy sources for deeper study — prefer official documentation, primary research or standards bodies over blogs and videos. Rules for you: no buzzwords. No motivational filler. Say "I'm not certain" when you are not certain, and tell me which parts of your answer I should verify myself. Clearly separate facts from your recommendations and your opinions.
Become independent at this
Use this when you want a path from where you are to actually good, with checkpoints you can test yourself against.
I want to become independently capable at explaining ideas with diagrams — not permanently dependent on AI, tutorials or step-by-step guides. Design a progression for me with five stages: Beginner, Guided practice, Independent practice, Real-world application, Professional level. For each stage tell me: - what I must know - what I must be able to do without help - the mistakes people make at this stage - one practical challenge - one real project that would prove I reached this stage - one way I can test myself honestly Then tell me the signals that I am ready to move to the next stage, and the signals that I have skipped ahead too early. Keep the theory to the minimum I actually need. Focus on ability I can transfer to situations you and I have not discussed.