How to Present Data to Non-Technical Stakeholders

An analysis only has value if the people who make decisions understand it. Many good analyses fail at the last step: the presentation is organised the way the analyst worked, full of method and caveats, while the audience wanted to know what is happening and what to do. Presenting to non-technical stakeholders is a translation job, from analysis into decisions, and it follows a few learnable principles.

1. Start from their decision, not your analysis

Before building a single slide, write down who will be in the room, what decision they face, and what they already believe. Guidance on plain writing begins in the same place: content should be written for its specific audience (plainlanguage.gov: guidelines). Microsoft's dashboard advice makes the same point for reports: consider the audience and which metrics help them decide (Microsoft Learn: dashboard design tips). A sales director deciding where to cut costs needs a different presentation from the same data than a marketing manager planning a campaign.

2. Lead with the answer

Put the conclusion first, then the evidence, then the detail. If the meeting is cut to five minutes, the audience should still leave with the answer. A simple structure:

1. The answer in one sentence: what you found.
2. Why it matters: the size of the effect in terms they care about, such as money, customers or time.
3. What you recommend.
4. The evidence: two or three charts, no more.
5. Caveats and next steps.

Method belongs at the end or in an appendix, available for the questions it will answer.

3. Make numbers easy to grasp

• Round. Say "about 1.5 million", not "1,457,746". Keep the precise figure for the appendix.
• Use one format consistently. Numerals, commas in thousands, the % sign for percentages and the same number of decimal places in a sequence, as style guides such as GOV.UK's recommend (GOV.UK: style guide).
• Give comparisons. "Up 12%" means little alone; "up 12%, the biggest rise in two years" means something.
• Translate into familiar terms. "One customer in four" is easier to hold than "25.7%".
• Avoid statistical vocabulary such as p-values, confidence intervals or R-squared on the main slides; express the idea in plain words instead.

4. One chart, one message

Each chart should make one point, stated in its title: "The North region fell below target in March", not "Revenue by region by month". Highlight the part that matters, the bar or line the message is about, and grey out the rest. Remove what does not support the message: extra series, gridlines, legends that could be direct labels. If you need to make three points, use three simple charts rather than one complex one. Data visualisation best practices covers chart choice and common distortions.

5. Explain uncertainty without jargon

Non-technical audiences can handle uncertainty well if it is expressed plainly:

• "We are fairly confident sales will fall between 180 and 220 units; 200 is the most likely."
• "This difference could be chance; a four-week test would tell us."
• "These figures exclude online orders without a customer account, about one order in eight."

What they cannot handle is uncertainty hidden until someone asks, or a caveat so long that the message disappears. State the main limitation once, clearly, and move on.

6. A before-and-after example

Before: "RFM segmentation using quintile scoring on recency and frequency produced five segments; the champions segment (R ≥ 4, F ≥ 4) comprises 25.7% of customers and 67.8% of monetary value, while the at-risk segment exhibits median recency of 135 days."

After: "A quarter of our customers bring in two thirds of our revenue. About one customer in six used to buy regularly but has typically not ordered for over four months. We recommend testing a personal win-back offer with half of that group next month, to find out how many we can bring back."

The facts are the same. The second version says what matters, in words a manager uses, and ends with a decision.

7. Prepare for questions

• Anticipate the obvious ones: "How does this compare with last year?", "Is the data reliable?", "What would it cost?"
• Keep backup slides with detail and method, so you can answer without derailing the story.
• Say "I don't know, I'll find out" rather than guessing. A confident wrong answer damages trust more than an honest gap.
• Listen for the real concern behind a question; a challenge to your data is often a concern about the recommendation's consequences.

8. Follow up in writing

Send a short written summary after the meeting: the answer, the recommendation, the decision taken, and next steps with owners. It becomes the record, and it reaches people who were not in the room. How to write a data analysis report that gets read covers the written form, and how to tell a story with data covers structuring a longer narrative.

Common mistakes

• Presenting the process instead of the result.
• Too many charts and too many numbers per chart.
• Unexplained acronyms and technical terms.
• No clear recommendation, leaving the audience to guess what to do.
• Hiding uncertainty, or drowning the message in caveats.

Data storytelling techniques are part of the data visualisation module of the Data Analytics course.

Sources

• Federal plain language guidelines (plainlanguage.gov) — plainlanguage.gov
• A to Z style guide (GOV.UK) — GOV.UK
• Tips for designing a great Power BI dashboard (Microsoft Learn) — Microsoft Learn