Chart, Table, or Diagram: Choose the Form That Answers the Slide's Question

Most slides begin with the graphic. The numbers arrive, someone opens the insert menu, picks a bar chart, and only then works out what the slide is supposed to say.

Reverse the order. Write the question the slide has to answer, in one sentence, and choose the form afterward. Three questions cover most of what a business slide needs to do:

• Has something changed, and in which direction? Choose a chart.
• What exactly was the figure for this site, this month? Choose a table.
• Where does a job go after the front desk? Choose a diagram.

Each question asks the audience to do a different thing: notice a pattern, find an entry, follow a connection. Those are not three decorative treatments of one slide. They are three different jobs, and a form that suits one will fight the other two.

The form also cannot repair the information. A line chart makes a change visible; it does not make two incomparable measurements comparable. A table organizes entries; it does not give a heading a definition it never had. A diagram shows connections; it does not authorize an arrow the records never established. Presentation choice comes after the question, and both come after knowing what the records actually support.

The example running through this article is a constructed packet for an invented company — Meridian Instrument Repair, four service sites. Three pages, three questions. It is a working illustration. It has not been built, and nobody has tested it with an audience.

Name the operation the reader needs to perform

Someone will object that the turnaround figures on page one could simply be dropped into a table, and the table on page two could be sorted and charted. True, and both would still answer the original question, badly.

Page one exists to show whether turnaround is moving. Page two exists so an operations lead can look up how much work landed at each site in one month before deciding July staffing. Page three exists so a new hire can find out who receives a job next. The three pages do not even share a dataset: a six-month series of turnaround durations, a single month of job counts, and a process record. Restyling one of them three ways would produce three views of one question, not three answers.

So the first decision is not which form looks better. It is which operation the reader has to perform, and how much attention that operation costs. A chart asks the reader to compare positions against an axis. A table asks them to scan to a coordinate — the Ashby row, the field column — and read a number. A diagram asks them to hold a path in mind and check where it goes. Each is easy when it matches the task and laborious when it does not. Reading eighteen numbers off a slide to discover that March was the worst month is a chart doing a table's job in reverse.

Before shapes, colors, or animation, write down what the record supports. What is the measurement? What counts as one case? Over what period? From which population? Under which definition? A slide that skips those questions usually answers a slightly different one than its title claims.

Use a chart when the quantitative relationship is the point

Page one's question: How has turnaround time changed over the past six months?

The supporting record (invented, like everything else in the packet) is the median turnaround in business days for completed bench repairs at all four sites, January through June 2026.

Median rather than average is a deliberate choice: half the jobs closed faster than the figure and half slower, which describes the typical job. A single job waiting three weeks for a part can move an average without saying much about what most customers experienced.

The chart puts six ordered months on the horizontal axis, but it does not draw one continuous line through them. It draws two segments — January to February, then March to June — with the 1 March definition change annotated at the break on the axis. The question is about direction and pace: did turnaround fall, and how steadily? Within each segment, a line carries that reading at a glance. The break keeps the two stretches visible as two stretches rather than joining them into a single trend that no measurement supports.

The ONS service manual's guidance on choosing a chart type (checked 8 September 2026) selects a chart by the data's type and relationship and by the message the chart has to carry, preferring familiar forms where they fit. It is UK official design guidance, not US accessibility law, and it addresses chart selection rather than the wider comparison on this page.

Two boundaries belong on the slide itself, not in the presenter's memory.

First, the population is bench repairs. Field work is not in this series, so the chart cannot support "turnaround improved across the service." Second, the definition changed on 1 March. Before March, the clock started when a job reached the intake desk. From March onward it starts when a technician picks the job up. That means February's 13 and March's 11 are not measuring the same interval, and the apparent step down is partly bookkeeping. January and February are comparable to each other; March through June are comparable to each other. The axis should show the split, and the footnote should give the reason for it, because the reader who spots the break unaided and finds no explanation stops trusting the rest.

There is a third boundary that no chart style can fix: jobs still open at the end of a month are excluded from that month's median. A month that ends with several long-running jobs unfinished will look faster than it was. That is a property of the measurement, and a different color palette does not change it.

Finally, resist turning labels into magnitudes. If someone proposes adding bars for Bench, Field, and Calibration on this chart, ask what the heights would measure. The categories are names, not quantities. Inventing a number to justify a bar produces a picture that answers nothing.

Use a table when the reader needs the entries

Page two's question: How many jobs did each site handle in June, by repair category?

The operations lead needs exact counts, site by site, to assign hours in July. Approximate shapes drawn from a chart will not do.

The dashes matter. Bellhaven has no calibration bench, so its calibration cell is blank because the category does not apply there, not because nobody counted. The column total of 223 sums the defined cells only. A reader who treats the blank as zero will conclude that Bellhaven's calibration work collapsed; the correct reading is that Bellhaven has none. Where a blank means zero, write 0. Where it means "not applicable," say so in the caption or a footnote.

The column set is also a decision. This table has what the staffing question needs: site, category, totals. It does not need average parts cost per job, technician identifiers, or the forty-one rows of the source export. Reproducing the export would make the table harder to read than the chart it replaced.

That is the real trade-off. A compact table supports lookup: any cell can be found at the intersection of a row and a column. A crowded one hides patterns that a chart would expose immediately. In this data, field work runs about 25% of jobs at Ashby, 24% at Dunmore, 45% at Bellhaven, and 52% at Corran. Bellhaven and Corran lean toward field work. A stacked bar would have shown that in a second. The table makes you compute it.

Both facts are true, and the question decides. If the slide's job were "which sites are field-heavy," a chart would serve better. Since the job is "give me the numbers for the staffing meeting," the table wins, and the presenter can say the Bellhaven-Corran pattern out loud in one sentence. That sentence costs less than rebuilding the page.

The GOV.UK Design System's table component guidance (checked 18 September 2026) treats rows and columns as the mechanism for comparison, with captions and headers establishing what the entries mean. That is guidance for a web component. It does not establish that the same structure and meaning survive a paste into a slide file or a PDF export, so keep the caption and the headers on the page rather than trusting the container to carry them.

Use a diagram when the connection is the evidence

Page three's question: Who receives a job after triage?

The supporting record is the packet's process description, revision 4. Triage assigns every incoming job to one of two routes. A bench job goes to the bench scheduler, then to a bench technician, then to a quality-control inspector, then to the customer liaison. A field job goes to field dispatch, then to a field technician, then straight to the customer liaison, which closes it out on site.

A text sketch of the two routes — which is also the basis of the page's reading route — looks like this:

Triage desk
  ├─ Bench route ──▶ Bench scheduler ──▶ bench technician ──▶ QC inspector ──▶ Customer liaison
  └─ Field route ──▶ Field dispatch  ──▶ field technician  ───────────────────▶ Customer liaison

Now look at the arrows, because they are where diagrams go wrong. In this sketch, the arrow from triage to the bench scheduler means "assigns a route to." The arrow from the scheduler to the technician means "assigns work to." The arrow from the technician to QC means "passes the completed job to." The final arrow means "releases the repaired job to." Four different relationships, drawn identically. If the page does not label them or supply a legend, readers will assume one meaning and apply it to all four. The QC step will look like it assigns work to the customer liaison.

That is the discipline a diagram demands: define what each link represents — sequence, dependency, assignment, handoff, or another relationship the record actually documents. It is also the reason not to draw a link because a meeting felt it belonged. If someone says quality control "should be part of the field route too," the diagram cannot show that until the process record says it. And arrowheads do not license causation. A link from parts delays to longer turnaround is a causal claim, and it needs more than adjacency in a spreadsheet — co-occurrence is not cause.

Diagrams are also not automatically the right answer for anything involving people doing steps. Suppose the question were "who is accountable for each step?" A table with steps as rows and roles as columns answers that, because accountability is an attribute of a step rather than a path between steps. The diagram answers "where does the job go next." Both could sit in one deck, on different pages, answering genuinely different questions.

One more requirement, and it is a requirement rather than a claim about how any particular file behaves: the page needs a caption stating what the arrows mean and a text equivalent that reads the routes in order, bench route then field route, using the same role names. Whether that survives a given export depends on the tool and how the file is built, so it has to be checked in the actual artifact rather than assumed from a notes pane.

Some of the chart and table advice above rests on the two sources named with their check dates. This diagram section does not. No primary design reference for diagram selection was inspected for this piece, and the workflow used here is invented. A real version of page three would need a verified record of the actual process before anyone drew it.

The page that didn't survive

A colleague proposes a pie chart on the diagram page: triage 15%, diagnosis 25%, repair 45%, quality control 15%. It looks tidy, and it invents every number in it.

The process record says who receives a job. It does not say how long each stage takes or how much effort it consumes. Percentages of "where the workflow spends its effort" have no measurement behind them. And even with real stage durations, a workflow with two branches is not a set of parts adding up to a whole, which is what a pie depicts. If the question were genuinely about where time goes, the fix is to measure hours per stage — and then a bar chart of median hours would answer it.

Pie charts are not disqualified everywhere. Four sites' share of 2,298 June jobs is a legitimate whole — Ashby about 29%, Corran about 26%, Bellhaven about 23%, Dunmore about 22% — but that answers a different question from the one page two asks, and it still would not let the operations lead look up a site's count.

The form follows the operation, and the note follows the form

Choose a chart when the reader has to see a pattern across measurements, a table when the reader has to find a value, and a diagram when the reader has to follow a connection — then add the detail that makes the choice honest. The chart earns its two segments because six ordered months, divided at the definition change, make a direction readable at a glance within each stretch. The footnote names the unit and the population and gives the reason for the break, but on the definition change it discloses the limit rather than neutralising it: the first two points measure a different clock than the last four. Mark that on the axis and the reader sees two comparable runs instead of one trend that isn't there.

Frequently asked questions

How should I choose between a chart, a table, and a diagram?

Write the question the slide has to answer in one sentence first, then choose the form. Use a chart when the reader must notice a change or direction, a table when they need an exact figure or entry, and a diagram when they must follow a connection or path. Those are different reader operations, and a form that suits one will fight the others.

Why does the example turnaround chart use two segments instead of one continuous line?

Because the definition changed on 1 March. Before March the clock started when a job reached the intake desk; from March onward it starts when a technician picks the job up. January and February are comparable to each other, and March through June are comparable to each other. The axis shows the break and the footnote gives the reason, so the apparent step down is not read as one supported trend.

What should a blank or dash in the table mean?

A dash is not zero. In the example, Bellhaven has no calibration bench, so its calibration cell is blank because the category does not apply there, not because nobody counted. The column total sums defined cells only. Where a blank means zero, write 0; where it means not applicable, say so in the caption or a footnote.

What limits apply to the example and the cited guidance?

The packet is constructed for an invented company and has not been built or tested with an audience. The chart covers bench repairs only, excludes field work, and excludes jobs still open at month end. The diagram section has no primary design reference inspected, and its workflow is invented. The ONS chart guidance is UK official design guidance, not US accessibility law; the GOV.UK table component guidance is for a web component and does not establish that the same structure survives a slide or PDF export.

Can the workflow page use a pie chart of stage percentages?

The proposed pie chart invents every number. The process record says who receives a job, not how long each stage takes or how much effort it consumes. A workflow with two branches is also not a set of parts adding up to a whole. A pie could legitimately show four sites' share of 2,298 June jobs, but that answers a different question and still would not let an operations lead look up a site's count.

Further reading

• Keep a Complex Chart’s Argument When You Add an Accessible Reading Route — Read when the chart's caption must survive as text: it shows how an accurate summary can drop the exception the slide was built to make.
• What Goes in a Pitch Deck Appendix—and What Must Stay in the Main Deck? — For deciding whether the definition-change note belongs on the slide or in an appendix, read this before shrinking the chart to make room.