Data storytelling is the practice of structuring analytical findings as a narrative that drives decisions, rather than as a display of what the data shows. The difference between data that informs decisions and data that is noted and ignored is almost always a communication problem, not an analytical one.
Data storytelling is the practice of structuring analytical findings as a narrative that drives a decision, rather than as a display of what the data shows. The difference between analytics that change decisions and analytics that are noted and forgotten is almost always a communication problem, not an analytical one. The analysis can be correct and the data can be accurate, but if the findings are presented as a data dump rather than a clear argument, the decision-maker cannot determine what to do with them.
The Structure of a Data Story
A data story has the same structure as any persuasive argument: situation, complication, resolution.
**Situation** — what the decision-maker already knows and accepts as true. Starting from shared ground reduces the cognitive burden on the audience and establishes that the analysis is connected to their actual context. "We have been growing acquisition at 15% quarterly" is a situation the VP of Marketing already knows.
**Complication** — what the data reveals that creates a problem or opportunity relative to the situation. This is the analytical finding that demands attention. "But our 90-day retention has declined 8 percentage points over the same period, meaning the customers we are acquiring are churning at a rate that will offset new acquisition by Q3." This is the point at which the audience's attention should be highest.
**Resolution** — what should be done in response. The resolution answers the question the complication creates. "We need to understand whether the retention decline is a product problem or an acquisition quality problem before we invest further in acquisition growth. Our recommendation is to run this analysis by [date] and bring a recommendation to the leadership team."
The structure is not always linear — in some contexts, starting with the resolution (the recommendation) and then presenting the evidence is more effective. But the three elements must be present.
What Most Data Presentations Get Wrong
**The data dump.** Presenting every metric that was analysed, every chart that was produced, and every data quality caveat that was found before arriving at the finding. The audience spends most of the presentation trying to understand what they are looking at; by the time the conclusion is reached, they are fatigued.
The correct approach: lead with the finding, then present the supporting evidence for the finding, and exclude any analysis that does not directly support or challenge the finding.
**Showing work instead of showing conclusions.** Data analysts are trained to be rigorous — to show their methodology, to acknowledge limitations, to hedge conclusions. These habits, valuable in the analytical process, are liabilities in an executive communication. An executive audience does not need to review the methodology; they need to understand the finding, assess whether it is credible, and decide what to do.
The correct approach: put the methodology in an appendix. Lead with the conclusion and the key evidence. If the audience wants to review the methodology, it is available — but it should not be in the default presentation.
**Not making a recommendation.** "Here is the data" is not useful. Data does not recommend itself. The analyst who has spent weeks on the analysis is uniquely positioned to form a view on what the data implies for decision-making. Declining to form that view and instead presenting "here are the options" passes the analytical burden back to the audience.
The correct approach: form a recommendation and state it clearly. "Based on this analysis, our recommendation is X." If the uncertainty is too high to recommend a specific action, recommend the action needed to reduce the uncertainty: "We are not confident enough in the conclusion to recommend X; we recommend running a 4-week test to determine whether the effect holds in a controlled setting."
The Chart Serves the Story, Not the Other Way Around
Chart selection in data storytelling is different from chart selection in exploratory analysis. In exploratory analysis, the goal is to reveal patterns; any chart type that makes the pattern visible is appropriate. In storytelling, the chart needs to support the specific conclusion being communicated as efficiently as possible.
For a conclusion about comparison (Region A outperforms Region B): a sorted bar chart with the gap annotated. The audience should be able to see the conclusion at a glance, without having to read axis labels and compute the difference.
For a conclusion about trend (revenue growth rate is accelerating): a line chart with the growth rate annotated on the trend line or in the chart subtitle. The conclusion ("growth is accelerating") should be the chart title, not a neutral label like "Revenue by Month."
For a conclusion about magnitude (this problem costs $X annually): a single large number with context (how it compares to revenue, to the cost of fixing it) is more effective than a chart. Some conclusions are best stated directly, not visualised.
Calibrating for the Audience
The same analysis needs different communication for different audiences:
**Executive audience** — the decision-maker who will act on the finding. Needs: the conclusion and recommendation in the first 60 seconds; the two or three pieces of evidence that establish credibility; the call to action. Does not need: methodology, data sources, confidence intervals, or analyses that did not produce findings.
**Technical peer review** — colleagues who will check the analysis for errors. Needs: full methodology, data sources, confidence levels, alternative interpretations considered and rejected. The analytical rigour that an executive presentation omits is essential here.
**Middle management implementation** — the people who will execute the recommended action. Needs: clear understanding of what is being asked of them, what the evidence is for why it matters, and what success looks like. Needs enough context to explain the change to their teams.
Each audience needs a different version. The mistake is delivering the technical review version to the executive audience, or the executive summary to the implementation team.
Our BI strategy and Tableau consulting practice helps analytics teams communicate findings more effectively — contact us to discuss data storytelling and communication frameworks for your team.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →