Lesson 2 of 3

Data Storytelling

In Lesson 1 you built a report that updates itself. It is correct, reproducible, and ignored. Priya ships hers every Monday to Dev, the regional manager. Dev opens twenty reports that morning and gives each about thirty seconds. He skims Priya's first paragraph, which describes how the data was pulled, glances at a table, and moves on. He never reaches the finding at the bottom, the one that needed a decision this week.

A correct report that nobody acts on has failed. This lesson is the other half of the job: structuring what you found so a busy reader gets it, and acts on it, in thirty seconds.

By the end of this lesson you will be able to:

  • Explain why a report must lead with the answer instead of building up to it
  • Structure a data story as the inverted pyramid: Answer, then Evidence, then Detail
  • Write a one-paragraph executive summary: the finding, the number, and the recommended action
  • Pick and title the single chart that carries your headline

Prerequisites: you can run R and load a package with library(), you have built a basic ggplot (data, then aes(), then a geom) in The Grammar of Graphics, you know the dplyr verbs from The dplyr Verbs, and you have a reproducible report from Lesson 1. Every new term is defined as it appears.

The widget below is the report we are building toward. Toggle between Source (.qmd) and Rendered, and notice it opens with the answer, not the setup.

The problem

Your reader is busier than you think

Here is the trap. You spent hours on the analysis, so you write it up the way you lived it: where the data came from, how you cleaned it, what you explored, and finally, at the end, what you found. That order is honest. It is also exactly backwards for the person reading it.

Dev does not want the journey, he wants the destination, fast, because he has nineteen more reports and a 9 a.m. meeting. If your single most important finding sits in the last paragraph, you are betting a whole week of work on him reading to the end. He will not.

Key Insight
The order you DID the analysis (data, then exploration, then conclusion) is the worst order to REPORT it. The reader, not the analysis, decides the order. Put what they need to act on first; everything else exists to support it.

So the question for the rest of this lesson is simple: what is the one thing Dev must know, and how do we get it in front of him in the first ten seconds?