Imagine a slide whose headline says “The system passed the test.” The engineer knows what that means. The executive in the room still needs to know which test, under what conditions, and whether passing it supports the decision on the table.
When those details are missing, the audience has to guess what the result means. Keep the technical detail that matters; give people enough context to judge it.
A result needs its conditions
Before you present a technical result, check that the slide gives the audience six things:
- Claim: What are you asking the audience to consider?
- Test: What was measured, inspected, or compared?
- Conditions: Under what setup or constraints was it tested?
- Result: What was observed, with the relevant unit or definition?
- Limit: What does this test leave open?
- Decision: What can the audience reasonably decide or do with this evidence?
You don’t need six headings on the slide. Put the details where the audience can find them: a short note under the chart, a caption, or a backup slide for method detail.
Use a slide structure that makes the evidence visible
Use this synthetic template as a starting point. The brackets are prompts, not test results:
[Claim this test can evaluate]
Test: [what was tested and how]
Conditions: [relevant setup, sample, environment, or constraints]
Observed result: [verified value and unit, or a precise qualitative observation]
Comparison: [baseline or threshold, if relevant and defined]
Limit: [what this test does not establish]
Decision this informs: [the next decision proportionate to this evidence]
If you cannot fill in one of these fields, that is useful to know before the meeting. Check the source, narrow the claim, or say what remains open.
Illustrative template only; it contains no test data.
A Challenger-era readiness review, filled in
The Challenger accident deserves more than a neat presentation lesson. The Rogers Commission’s review of NASA’s Flight Readiness Reviews documents a specific example of technical evidence changing as it moved through a decision process. The template below is a reconstruction from the Commission’s report, not NASA’s original briefing slide.
After STS 51-C, when the O-rings were 53°F at launch, inspectors found erosion and blow-by. Thiokol prepared an 18-page analysis for the next flight readiness review. It said low temperature increased the probability of blow-by and that the next flight could show the same behavior. At the Level I review for the mission then designated STS 51-E (later changed to STS 51-D), the analysis was reduced to a one-page chart that omitted the temperature concern and described the risk as acceptable because exposure was limited and the seal was redundant. The Commission noted that the primary seal had been classified as a single-point failure, which conflicted with the redundancy rationale. The Commission’s report describes the review and its findings.
Reconstruction from the Commission report; not the original NASA slide.
Map the documented case to the template:
- Claim under review: The risk was acceptable because exposure was limited and the seal was redundant.
- Evidence available: STS 51-C had shown O-ring erosion and blow-by; Thiokol’s analysis said low temperature increased the probability of blow-by and the next flight might show the same behavior.
- Conditions: The February 21, 1985 review concerned the mission then designated STS 51-E, later changed to STS 51-D, and drew on the earlier STS 51-C flight. It was not the final launch review for STS 51-L, the later Challenger mission.
- What changed in the summary: The 18-page analysis became a one-page chart that left out the temperature concern. The Commission also identified a conflict between the redundancy rationale and the classification of the primary seal as a single-point failure.
- Limit: The report documents a failure in how evidence was summarized and handled. It does not establish that this one summary caused the 1986 Challenger accident; the Commission described broader design, communication, and decision failures.
- Decision at stake: Whether to accept the unresolved seal risk and proceed with the next flight.
This example shows why a technical slide needs the evidence that changes the decision: the condition that matters, the observed failure mode, and the limit of the conclusion. A concise summary is useful only if it preserves those things.
Keep the recommendation within the result
The result is what the test found. The recommendation is what you think the team should do. Show the link between them, and name the gap.
If the test supports another test, recommend that. If you want to move from a controlled test to deployment, show why the test conditions match the intended use and have the right technical owner check that connection. A clean chart can’t do that work for you.
Make the technical slide reviewable
Ask someone outside the project team to read the slide. Can they tell you:
- What was tested?
- Under which conditions?
- What was observed?
- What remains uncertain?
- What decision does this evidence support—and what decision would go too far?
If they can only repeat the headline, add the missing context or narrow the conclusion. Keep the decision-relevant details on the main slide; move method detail that only a specialist needs to a backup slide.
For a related proposal check, see What I Would Flag First on a Polished Proposal Slide.
Illustrative template only. Bracketed fields are prompts, not test results.