Putting diagrams into presentations people can read

A diagram that works on a whiteboard or a wiki page often fails on a slide. The page gave it room; the slide gives it a fixed rectangle, a room full of people at different distances, and perhaps forty seconds of attention. The same diagram dropped into a written report has a different problem: nobody is there to explain it.

The fix is rarely a better drawing tool. It is deciding what the diagram must say in this setting and removing everything else. This article covers how to do that for slides and for reports.

Start with the sentence, not the shapes

Before you touch the diagram, write the one sentence you want the audience to take from it. For example:

• “Team-plan customers get a call within a day; that’s where setup speeds up.”
• “The new support team reports to operations, not sales.”
• “Onboarding has three handoffs, and two of them have no owner.”

That sentence decides what stays. A full process diagram might have twenty steps; the slide that supports the first sentence needs perhaps six, with the onboarding call clearly marked. Everything else is accurate but irrelevant to this moment.

Put the sentence on the slide as the title. “Team-plan customers get an onboarding call” tells the room what to look for. “Onboarding process” makes them work it out.

Cut the diagram down to the point

Working diagrams are built for completeness. Presentation diagrams are built for one point. Some practical cuts:

• Collapse detail into one box. Five steps of plan checking can become “Check their plan” on a slide, with the full version kept in the appendix or the source document.
• Keep the main path and the decision that matters. Drop exception branches unless an exception is the point.
• Show fewer levels. An org chart for an all-hands slide may need only the leadership team and the new group, not every reporting line.

A useful limit for a single slide is around eight to ten shapes. Past that, the room stops reading and starts waiting for you to explain.

Make it readable from the back

Slides are viewed at a distance and often on a screen smaller than you expected. A few rules keep a diagram legible:

• Labels at body-text size or larger. If you have to shrink the text to fit the boxes, you have too many boxes.
• Short labels. Three to five words per shape. “Book an onboarding call” rather than “An onboarding call is arranged by the account manager for team-plan customers”.
• Strong contrast. Dark text on light shapes, or the reverse. Pale grey arrows on a white background disappear on many projectors.
• One accent colour. Keep most shapes neutral and use a single colour for the step or group you’re talking about. The eye goes straight to it.
• Straight, short connectors. Long diagonal lines and crossings are hard to follow at a distance. Move shapes until the lines are simple.

Reveal a long process in stages

Some processes can’t be reduced to eight shapes without losing the story. In that case, don’t shrink. Spread the diagram across several slides:

1. Show the whole flow at low detail, as a simple overview.
2. Show each stage on its own slide, with the overview’s matching box highlighted in a small corner version.
3. Return to the overview at the end, with the problem area or the change marked.

This keeps every slide readable and gives the audience a map of where they are.

Diagrams in written reports

In a report, the reader has more time but no presenter. The diagram has to explain itself.

• Place it next to the text that discusses it, not in an appendix the reader may never open.
• Write a caption that states the finding, as you would a slide title: “Figure 2: Two of three onboarding handoffs have no named owner.”
• Refer to it in the text by number, so readers know when to look.
• Allow more detail than a slide, but still keep one level of detail per diagram. If the full process is long, show the overview in the body and the detailed map in an annex.

If the same diagram serves both a deck and a report, make two versions rather than one compromise. The slide version is simplified for distance and speed; the report version can carry the extra steps a careful reader wants.

Sometimes the diagram is one part of a wider visual summary, with figures, icons and short notes on the same page. Studying a few infographic examples is a useful way to see how text and graphics can share that space without competing.

Matching the diagram to the moment

Different diagram types suit different slide jobs. If you build decks often, a library of diagram and timeline slides saves redrawing the same layouts, since the shapes are already sized for a screen.

What you want the audience to understand	Diagram that usually works
How a process runs and where it splits	A simplified flowchart
Who is responsible at each step	A swimlane with three or four lanes
Who reports to whom	A partial org chart around the change
When things will happen	A timeline with phases and milestones only

For the building blocks of the first, how to make a flowchart walks through the method; for the third, org chart examples for small teams shows layouts that stay clear at slide size.

A quick check before you present

Look at the slide from across the room, or shrink it on your screen to the size of a postcard. Ask:

1. Can I read every label?
2. Does the title say what the diagram shows?
3. Is the one thing that matters visibly different from the rest?
4. Could someone who missed my explanation still get the point?

If any answer is no, cut another shape. The detailed diagram still exists for anyone who needs it. Keep it in the appendix or the source document, and let the slide do its one job. For the slides around it, an AI presentation maker is one way to build the rest of the deck.