Choose Evidence That Answers the Claim on the Slide
Choose Evidence That Answers the Claim on the Slide
There is a specific moment in a deck review when someone points at the screenshot and says, "but this shows it." The screenshot does show something. Whether it shows the thing the headline says is a different question, and it is usually the one nobody in the room asked.
The habit worth building is not skepticism about evidence. It is precision about claims. A slide almost always contains two sentences: the one you wrote, and the one the object beside it actually supports. Your job is to find out whether they match, and if they don't, to move one of them.
Write the claim without its supporting graphic
Before you judge the evidence, delete it. Take the screenshot out, take the quote out, take the chart out, and write the slide's assertion as a plain sentence on its own. Then read it back.
"The product helps teams" is not a claim yet. It is a category with several claims hiding inside it:
- A feature exists.
- Someone liked it.
- A task got completed.
- An outcome improved.
Each of these needs a different kind of record to stand up. A feature existing needs a build and a date. Someone liking it needs that someone, on the record. A task being completed needs a trace of the task. An outcome improving needs a measurement, a period, and something to compare against. When a slide says "helps teams" and shows a screenshot, the writer has skipped the step of deciding which of these four the slide is about — and the evidence that follows tends to be chosen by feel rather than by fit.
So name the parts. Who is the actor? What did they do, or what result changed? Under what conditions? A claim that can survive this treatment is one you can test. A claim that dissolves when you write it plainly was never doing any work; the graphic was.
One caution here, because it runs against the instinct of a deck review. A capability slide is a legitimate slide. If the honest state of affairs is "here is what the product does today," then a build screenshot with a date is not a weak version of an outcome slide — it is the correct evidence for the claim the slide is making. The failure is not modesty. The failure is when a capability record gets dressed up to look like an outcome, when a chart is layered onto a demo view or a percent sign is attached to a number that was never measured. Decide the claim first, and you will know which slide you are actually building.
Ask what this particular object records
Proof-like objects fall into a few broad kinds, and the kind matters more than the appearance. Nearly all the confusion on a slide comes from mixing these up:
A product view — a screenshot, a demo, a staged interface — records a state the product can be put into. It can establish that a screen exists and what is on it. It cannot establish that anyone used it, how often, or what happened afterward. That is not a flaw in screenshots; it is simply what they are for.
A person's account — an interview note, a testimonial, a quoted line — records a reported experience. It can establish that this person said this. It cannot establish a measured change in anything.
A measurement — a count, a rate, a duration — records observed behavior in a defined population over a defined period. It can establish a number within its definition. It cannot establish that its definition is the one your headline implies.
The next step is to inspect the actual source, not its visual form. A screenshot of a dashboard is not a measurement if the dashboard was populated with sample data. A chart sitting inside an interface view does not become usage data because it is a chart. The question is not what the object looks like on a slide; it is what produced it and what it recorded.
A useful illustration of the same principle comes from outside the technical world. The US Federal Trade Commission's guidance for small-business advertising draws a line between claims that require objective substantiation and endorsements — a customer's account supports a different kind of sentence than a test result does, and the guidance treats them as answering different questions rather than as strong and weak versions of one another. That guidance applies to advertising within its own scope; it does not decide what substantiates a particular claim, and it says nothing about what a private presentation requires. As an illustration, though, it is clean: a personal endorsement and an objective measurement are not interchangeable, because they were never answering the same question in the first place.
Keep the conditions that change the meaning
A number or a quote separated from its conditions is not wrong so much as unreadable. The reader cannot tell what it would mean, or what would happen to it under scrutiny. So keep the conditions attached, in the same place, at the same size:
- Which product version or build
- Which population
- Which period
- Which task or scenario
- What level of support or setup was provided
- How the record was collected
Some of these can be short. "Build 0.4, March" is four words and does more work than a paragraph of praise. The point is not to bury the slide in methodology. The point is that a claim and its conditions travel together, and the moment you separate them, the claim silently grows.
It also helps to say plainly whose assertion you are looking at. A supplier's statement about its own product is an assertion. So is a dated release note — but a release note is inspectable: a reader can open it, read the date, and check the language. The distinction that matters is not "vendor claims are bad." It is whether the reader can check the thing for themselves.
And keep the scope proportional. A customer report does not have to become a laboratory study to be useful. "One coordinator said the new assignments were easier to follow" is honest and serviceable. "Coordinators find the assignments easier to follow," built from that single report, is the same sentence with its condition filed off. The evidence didn't change; the claim did.
Narrow the headline before decorating the gap
When the claim is larger than the record, the urge is to add material: more logos, more footnotes, more visual polish, a methodology note in eight-point type. None of that supplies an event that was never observed. Design can make an inference clearer. It cannot make the inference larger.
So the repair is almost always a rewrite, and there are three honest versions of it.
Name the state. If a feature appears only in a prototype, say prototype. The word costs you almost nothing on the slide and buys you the reader's trust for everything else.
Preserve the attribution. If a result was reported rather than measured, keep the reporting verb: "a customer reported," not "customers see." The verb is the evidence.
Remove the slide, or state the gap. If no smaller honest claim serves the slide's purpose, then the slide has a hole in it, and the useful move is to name the hole — "timing evidence to be collected" is a real line in a real deck — rather than paper over it.
A note on footnotes, since they are the most common disguise. A small methodological footnote that honestly qualifies a number is good practice. A footnote that quietly retracts what the headline states plainly is a different thing: if the small print changes the claim, then the small print is the claim, and it belongs at the same size.
Working through one example
To see the whole sequence in motion, take an invented product. Nothing here is a real company, customer, or dataset; the case is constructed to show the method.
Suppose a team is building a task-assignment tool. Call it Marlowe, and imagine they have three records.
Record A is a product view dated 14 March, from build 0.4. It shows a task assigned to a named person, with a due date and a handoff control on screen.
Record B is an interview note from 2 April. One coordinator said assignments were easier to follow than the email process they used before.
Record C is an event record covering April. Of 780 tasks created, 412 reached the handoff state, defined in the product's own logs as "task marked ready for review."
The team's proposed headline is "Teams finish work faster." Run each record against it.
Record A shows that a task can be assigned. It says nothing about duration. It cannot support "faster" at all.
Record B is one person's reported experience of comprehension — assignments were easier to follow. "Easier to follow" is about understanding, not completion time. Even if the coordinator had said the word "faster," it would be a report, from one person, not a measurement.
Record C is a count of tasks reaching a defined state in a period. It is a real measurement, and it still does not support "faster." Speed needs a duration per task and something to compare it against, and neither is in the record. There is a second problem hiding behind the first: "finish" is ambiguous. Handoff here means "ready for review," not done. So the count cannot support "finish" either, unless "finish" is quietly redefined as reaching handoff — which would be a different, weaker claim.
Rewritten to match what the records actually establish, the three claims look like this:
Marlowe can assign a task to a named person with a due date. Record: dated build view, 14 March, build 0.4. Condition: prototype build; shows capability, not use.
One coordinator reported that assignments were easier to follow than the previous method. Record: interview note, 2 April, one participant. Condition: reported experience from a single source; not a measured change.
Of 780 tasks created in April, 412 reached the handoff state (marked ready for review). Record: internal event log, April. Condition: no per-task duration recorded and no comparison period; handoff means ready for review, not done.
Each of these is smaller than the original headline, and each is a sentence someone could defend in the room. That is the trade: you give up the size of the claim and keep the ability to answer a question about it.
If the team genuinely needs "faster," here is what is still missing. A duration per task, measured the same way in two periods or two comparable groups. A defined start and a defined finish, both actually recorded. Enough tasks that the difference is not just noise. None of the three records supplies any of that, and no amount of layout will.
Where to land
The method holds on the last slide the same way it held on the first. End with a smaller claim, the record behind it, and the condition a reader needs beside it — the way you would want it presented to you.
Of 780 tasks created in April, 412 reached the handoff state. Record: internal event log, April. Condition: handoff means "marked ready for review." No duration or comparison was recorded, so this says how many tasks reached a state — not how fast.
That is a modest line. It is also one that survives contact with a skeptical reader, which is the only kind of line worth putting on a slide. And it points at the honest next step: if speed is the claim you want to make, go collect the timing — then come back and write the headline to fit it.
The question that started all this was never "is this good evidence?" It was "what does the sentence claim, and what records it?" Ask it of every proof-like object in the deck, and the ones that look impressive but answer nothing will start to show themselves — along with the plain, true slides that were there all along.
Frequently asked questions
How can I tell if a slide's evidence actually supports its headline?
Remove the graphic and write the slide's assertion as a plain sentence on its own. Then read it back. A claim like "the product helps teams" hides several possible claims: a feature exists, someone liked it, a task got completed, or an outcome improved. Each needs a different kind of record. If the sentence dissolves when written plainly, the graphic was doing the work.
What are the main kinds of proof-like objects, and what can each establish?
A product view (screenshot, demo, staged interface) records a state the product can be put into; it can establish that a screen exists and what is on it, but not that anyone used it, how often, or what happened afterward. A person's account (interview note, testimonial, quoted line) records a reported experience; it can establish that this person said this, but not a measured change. A measurement (count, rate, duration) records observed behavior in a defined population over a defined period; it can establish a number within its definition, but not that its definition is the one your headline implies.
What conditions should stay attached to a number or quote on a slide?
Which product version or build, which population, which period, which task or scenario, what level of support or setup was provided, and how the record was collected. A claim and its conditions travel together. If you separate them, the claim silently grows. For example, "Build 0.4, March" is four words and does more work than a paragraph of praise.
If the claim is larger than the record, what are the honest repairs?
Three honest versions: name the state (e.g., say "prototype" if the feature appears only in a prototype); preserve the attribution (e.g., "a customer reported," not "customers see"); or remove the slide, or state the gap (e.g., "timing evidence to be collected"). Adding material—more logos, footnotes, polish—does not supply an event that was never observed. Design can make an inference clearer; it cannot make the inference larger.
In the Marlowe example, why couldn't any of the three records support "Teams finish work faster"?
Record A (a dated product view) shows a task can be assigned; it says nothing about duration, so it cannot support "faster" at all. Record B is one person's reported experience of comprehension—"easier to follow" is about understanding, not completion time. Record C is a count of tasks reaching a defined state in a period; it is a real measurement, but it still does not support "faster" because speed needs a duration per task and something to compare it against. Also, "finish" is ambiguous: handoff here means "ready for review," not done. To claim "faster," the team would need a duration per task, measured the same way in two periods or comparable groups, with a defined start and finish, and enough tasks to avoid noise.