Research and policy teams produce a lot of good evidence that few people read. A 120-page report, a dataset on a portal and a deck of 40 charts all contain findings, but none of them tells a busy reader what changed, why it matters and what to do about it. Data storytelling is the craft of doing exactly that: picking one finding, explaining it in plain language and showing it with a chart that makes the point at a glance.
This guide sets out the best practices that matter most for research teams, think tanks and policy institutions: from choosing the finding, to the chart, to the notes that keep a story honest, to the habits that make storytelling part of how a team works rather than a one-off before each launch.
What is data storytelling?
Data storytelling is communicating a finding from data by combining three things: the data itself, a narrative that explains what it means, and visuals that make the pattern easy to see. The framing of data, narrative and visuals is set out by Brent Dykes in Effective Data Storytelling (2019), and it is a useful test for any piece of work:
- Data without narrative is a chart that leaves readers to work out the point for themselves. Most will not.
- Narrative without data is an opinion piece. It may persuade, but it can’t be checked.
- Data and narrative without visuals is a report. Accurate, but slow to read and easy to skim past.
A data story is not the same as a dashboard. A dashboard lets readers explore many numbers and find their own answers. A data story makes one argument from the evidence and walks the reader through it. Research teams usually need both: the story for the launch, the briefing and the press, and the dashboard or open data portals and public dashboards for the people who want to dig further.
1. Tell one finding per story
The most common mistake is trying to tell every finding at once. Pick the single finding that matters most to this audience, and build the story around it. If there are three important findings, that is three stories, each of which can be shared on its own.
A useful test is to write the finding as one sentence a non-specialist could repeat. A sentence of the form “X grew fastest where Y was in place” is a finding; “An analysis of trends in X across states” is only a topic. If you can’t write that sentence yet, the analysis isn’t finished, and no chart will fix it.
2. Start with the audience, not the data
The same finding needs a different story for a minister’s office, a district official, a journalist and a fellow researcher. Before drafting, write down:
- Who is reading, in as specific terms as you can.
- What they already know, so you neither lecture nor lose them.
- What decision or action they control, so the story ends somewhere useful.
- Where they will see it: a printed brief, a phone screen, a slide in a meeting or a social post.
A policymaker usually needs the finding, what it means for their area and the one action it points to, in under a minute. A researcher needs the method and the caveats. Write the version for the reader you have, and link to the rest.
3. Choose the chart that fits the comparison
Every chart answers a type of comparison. Choose the comparison first, then the chart:
- Change over time: a line chart. Use bars only for a few distinct periods.
- Ranking or comparing categories: a horizontal bar chart, sorted, so long category names stay readable.
- Parts of a whole: a stacked bar or a simple table. A pie chart works only for two or three parts.
- Relationship between two measures: a scatter plot, with the important points labelled.
- Differences across places: a map, but only when location is the point. A sorted bar chart often shows the same ranking more clearly.
- A single headline number: the number itself, large, with its comparison (“up from X% three years earlier”).
Then remove everything that doesn’t carry information: heavy gridlines, 3D effects, decorative icons, legends that could be direct labels. Edward Tufte called this maximising the data-ink ratio in The Visual Display of Quantitative Information (1983), and it still holds. For a fuller checklist, see our data visualisation tips.
4. Put the takeaway in the title and the annotations
A chart title should state the finding, not describe the axes. A title such as “Registrations grew threefold in this example” tells the reader what to see. A label such as “Registrations, 2021–2024” makes them work it out, and many will take away something different.
Annotations do the same job inside the chart:
- Label the point that matters directly on the chart: the policy change, the outlier, the year the trend turned.
- Label lines and bars directly instead of using a separate legend, so readers don’t look back and forth.
- Use colour to direct attention. One highlight colour for the series that carries the finding, grey for the context.
- Keep the subtitle for the measure and the unit: “Monthly registrations, all vehicle types.”
Test it on a colleague who hasn’t seen the work: show them the chart for five seconds and ask what it says. If their answer doesn’t match your title, change the chart, not the colleague.
5. Show the method and the uncertainty
Research audiences trust a story that is open about its limits. Every published chart should carry, close to it:
- The source, with the dataset name, publisher and date accessed.
- The method in one or two lines: what was measured, how it was calculated, and any adjustments, such as inflation-adjusted values or a changed definition.
- The uncertainty, shown and explained. Confidence intervals as shaded bands or error bars, projections drawn with a dashed line, and estimates labelled as estimates.
Words carry uncertainty too. Use the same terms consistently, and define them. The IPCC, for example, uses a fixed scale in its assessment reports, in which “likely” means a 66–100% probability and “very likely” 90–100%. A team doesn’t need to adopt that scale, but it should agree on what its own words mean, so “likely” in one brief means the same as “likely” in the next.
Never smooth away a result that complicates the story. If one state doesn’t fit the pattern, say so and say what might explain it. That paragraph is often the one an informed reader trusts most.
6. Publish the data behind the story
A data story from a research team should let readers check it. Put a download link beside each chart, in a format people can open (CSV for tables, with a short readme), along with:
- The source and the date of each dataset.
- Any cleaning or changes you made, in plain language.
- The licence, so others know how they may reuse it and how to credit you. Open licences such as CC BY are common for research data.
- A contact for questions or corrections.
Publishing the data takes more care at the start: tidying files, writing readmes and checking that nothing sensitive is included. It pays back in citations, reuse by journalists and fewer emails asking for the numbers. When the data is large or updated often, a public dashboard or data portal is the better home, with the story linking to it.
7. Structure the story: context, finding, meaning, action
Most good data stories follow the same short structure:
- Context: why this matters now, in one or two sentences.
- Finding: the one thing the data shows, with the main chart.
- Meaning: what explains it, and what it implies for the reader, with one or two supporting charts if needed.
- Action: what the reader could do, decide or look at next.
Layer the detail. The headline and first chart carry the whole story for someone who reads nothing else. Each section below adds depth for the reader who wants it: the breakdown by region, the method, the caveats, the full data. A reader should be able to stop at any point and still leave with the right message.
8. Design for where it will be read
Much research is now read on phones, in messaging apps and social feeds, not in a printed report. Before publishing, check every chart at phone width:
- Fewer categories. Ten bars on a desktop become an unreadable smear on a phone. Show the top five and link to the rest.
- Large text for labels and annotations, never smaller than the body text.
- Colours that work for everyone. Avoid relying on red and green alone, since a common form of colour blindness makes them hard to tell apart, and check contrast against the background.
- Text alternatives. Alt text or a one-line summary under each chart, so the finding reaches people using screen readers and people whose images haven’t loaded.
For the specific case of presenting evidence to officials, our guide to visualising research data for policymakers goes further.
How do you build a data storytelling culture in a research team?
You build a data storytelling culture by making the story part of the research process from the start, not a task handed to communications after the report is written. In practice that comes down to a few habits:
- Write the one-sentence finding at the analysis stage. Ask every project to state its main finding in a sentence before the report is drafted. It sharpens the analysis as well as the communication.
- Pair researchers with a designer or editor early. A short session while the charts are still drafts saves weeks of rework at the end.
- Keep a shared chart style guide: fonts, colours, the highlight colour, how sources and notes are written, and templates in whatever tool the team uses.
- Review stories the way you review methods. A colleague checks that the title matches the data, that the uncertainty is shown and that the chart doesn’t mislead.
- Publish the data by default, with a readme, and make it someone’s job to keep it current.
- Look at what worked. Which stories were cited, shared or picked up by the press, and which charts readers spent time on. Learn from them.
None of this needs a large team. A single researcher with a style guide, a reviewer and the habit of writing the finding first will produce clearer work than a team with expensive tools and no habits.
Common mistakes in data storytelling
The mistakes that most often undermine a research team’s data story are:
- A truncated axis on a bar chart, which makes small differences look large. Bar charts start at zero; line charts may not, but say so.
- Cherry-picked time ranges that start or end at a convenient point.
- Dual axes that let any two lines appear to move together.
- Per-capita and absolute numbers mixed up, so large states always look like outliers.
- Too many findings on one page, so none of them lands.
- Charts without sources, which journalists and officials can’t use.
Where websites and dashboards fit
A data story lives somewhere: on the research team’s website, inside a report page, or alongside a public dashboard. The best set-ups let each story link to the live data behind it and let the dashboard link back to the stories that explain it.
See our work on websites for think tanks and research and data visualisation services.
Tailwebs built the dashboards for CEEW’s Green Finance Centre (GFC): the EV dashboard and Renewables India with the CEA. The EV dashboard, for example, shows a sales-penetration forecast to 2030 and RTO-level data on a map.
The short version
- One finding per story, written as a sentence anyone could repeat.
- Write for a named audience and end with what they can do.
- Pick the chart for the comparison, then strip out everything else.
- Put the takeaway in the title and label what matters on the chart.
- Show the source, the method and the uncertainty beside every chart.
- Publish the data, with a readme and a licence.
- Make storytelling a habit of the research process, not a launch-week task.