Data storytelling combines three elements that are usually kept apart:

• Data — the evidence, correctly analysed
• Narrative — the meaning, in a structure a human can follow
• Visuals — the clarity, so the pattern is seen rather than described

Get all three right and you produce something rare: an analysis that changes what someone does. Get any one of them wrong and the work stalls — accurate data with no narrative is ignored, a compelling story with weak data is dangerous, and good analysis presented badly simply goes unread.

Storytelling Is Not Decoration

A common misunderstanding is that "storytelling" means dressing up numbers with colour and stock photography. It is the opposite. A story is a structure for meaning: it establishes what was expected, reveals what actually happened, and explains the consequence. Decoration adds nothing to that. Structure adds everything.

The Difference Between Reporting and Persuading

Reporting answers "what happened?" Data storytelling answers "what should we do about it, and why now?"

Both are legitimate, but only one drives a decision. If your monthly report ends with "the numbers are attached" rather than a recommendation, you are reporting. That is not a criticism of the analysis — it is a description of where the value leaks out.

We Have More Data and Less Attention

Every business now generates more telemetry than any person can read: web analytics, support tickets, transaction logs, survey responses, sensor feeds. As volume rises, attention per data point falls. The bottleneck has moved from producing analysis to being understood.

That shift changes what is valuable. A brilliant analysis nobody reads has an effective value of zero. A simpler analysis that changes a decision has an enormous one. Data storytelling is how you convert the first into the second.

The Gap Between Insight and Action

Most analytics teams can point to work that was correct, well-timed, and ignored. The reason is rarely that the finding was wrong. It is that the finding arrived without a decision attached — buried in a document, framed in the analyst's language, presented to someone who had thirty seconds and no context.

Storytelling closes that gap deliberately. It treats being understood as part of the analysis, not an optional extra afterwards.

Decisions Are Made by People, Not Systems

Even in heavily automated organisations, the consequential choices — entering a market, cutting a product line, changing a price — rest with people who are tired, busy, and juggling competing claims. A story respects that reality. It gives them one clear message, the evidence for it, and an obvious next step.

Pillar One: Data — The Evidence

The foundation is analysis you can defend. That means clean data, an appropriate method, and an honest treatment of uncertainty. If you cannot say how a number was produced, it cannot carry a decision.

Crucially, data quality here means relevance as well as accuracy. A perfectly computed metric that nobody can act on is precise and useless.

Pillar Two: Narrative — The Meaning

Narrative is the spine. A workable structure for analytical stories is the same one any story uses:

1. Context — what we expected

2. Conflict — what actually happened, and how it differs

3. Resolution — what we should do, and what it costs

That is it. Three beats. It works for a one-slide briefing and for a forty-page review, because it matches how people process cause and consequence.

Pillar Three: Visuals — The Clarity

Charts are not decoration; they are compression. A well-chosen chart lets a reader absorb in two seconds what would take two minutes to read.

The rule that matters most is simple: the chart should make the message visible at a glance. If your point is "growth accelerated in April", the chart must make acceleration obvious — not require the reader to find it. If the reader has to do the analysis, you have not visualised anything.

The Report Nobody Reads

A familiar pattern: a weekly performance report with eleven tabs, every metric the business tracks, correctly calculated. It is sent on Monday. Nobody opens it. When someone finally asks why a number moved, the answer is in tab seven — discovered three weeks later.

The analysis was never wrong. It was never usable. There was no message, so there was nothing to act on.

The One-Slide Decision

Now the same data, told properly: a single chart showing the metric that moved most, one sentence of context, and a recommendation with a cost attached. The reader makes the call in the meeting.

Same data, same analyst, same week. The only difference is structure.

The principle underneath both examples: a finding becomes valuable the moment it is understood by the person who can act on it — and not one minute before.

1. Start with the decision, not the data.

Ask: what decision is this for, and who makes it? Everything else follows from that answer. If you cannot name the decision, you do not yet have a story — you have an exploration, which is a different (and legitimate) activity.

2. Find the signal.

In most datasets, one or two movements matter and the rest is noise. Rank your metrics by how much they moved and by how much they matter, and work at the intersection of the two.

3. Build the three-beat narrative.

Context, conflict, resolution. Write it in sentences before you touch a chart. If it does not hold together as a paragraph, it will not hold together as a presentation.

4. Choose the chart that matches the message.

Change over time is a line. Comparison across categories is a bar. Composition is a stacked bar or a treemap. Distribution is a histogram or a box plot. Relationship is a scatter. Match deliberately rather than reaching for whatever default your tool offers.

5. Land the ask.

State the recommendation, the cost, and the alternative. An analysis without an ask leaves the decision where it started.

The mechanics are straightforward. Suppose six months of sign-up data, with a plan change shipped at the end of March. The chart below carries the story in its annotation, not its line:

import matplotlib.pyplot as plt

months = ["Jan", "Feb", "Mar", "Apr", "May", "Jun"]
signups = [420, 445, 430, 610, 648, 702]

fig, ax = plt.subplots(figsize=(8, 4.5))
ax.plot(months, signups, marker="o", linewidth=2, color="#1f77b4")
ax.set_title("New sign-ups by month")
ax.set_ylabel("New sign-ups")

# The story lives in the annotation, not in the line itself
change = signups[-1] - signups[2]
ax.annotate(
    f"Plan change shipped\n+{change} since March",
    xy=("Apr", 610),
    xytext=("Jan", 690),
    arrowprops={"arrowstyle": "->", "color": "black"},
)

ax.grid(alpha=0.3)
plt.tight_layout()
plt.savefig("signups_story.png", dpi=150)

The annotated version says "this happened, and here is why". The same data without the annotation is just a line going up — true, but not yet a story.

Next, turn the numbers into the one sentence a reader will remember:

def headline(baseline: float, current: float, unit: str = "") -> str:
    """Turn two numbers into the single sentence a reader retains."""
    if baseline == 0:
        return f"Now at {current:,.0f}{unit}"
    pct = (current - baseline) / baseline * 100
    direction = "up" if pct >= 0 else "down"
    return (
        f"{direction} {abs(pct):.0f}% to {current:,.0f}{unit} "
        f"(from {baseline:,.0f}{unit})"
    )


print(headline(430, 702, " sign-ups"))
# -> up 63% to 702 sign-ups (from 430 sign-ups)

And when you are staring at twenty metrics and do not know where the story is, let the movement find it for you:

def biggest_move(metrics: dict) -> tuple:
    """Rank metrics by how much they moved — usually where the story is."""
    scored = {
        name: abs(current - baseline) / baseline * 100 if baseline else 0.0
        for name, (baseline, current) in metrics.items()
    }
    return max(scored.items(), key=lambda item: item[1])


data = {
    "sign-ups": (430, 702),
    "support tickets": (980, 1050),
    "churn": (42, 29),
}

name, pct = biggest_move(data)
print(f"{name} moved {pct:.0f}%")

That is the technical half. The judgement half — deciding which movement matters, and what it means for the business — is where the real skill sits, and it is learned by doing it in front of people who will push back.

A finding is not a fixed object. The same result needs a different story depending on who is in the room, and getting that wrong wastes work that was otherwise sound.

A board asking "should we fund this?" wants the decision, the cost and the risk — one chart, three sentences. Detail is a distraction at that level; they need the shape of the answer, not its derivation.

A technical team asking "is this real?" wants the method, the sample size, the caveats and the sensitivity analysis. Compressing the story the same way reads as evasion, and you lose their trust rather than their attention.

Same numbers, same analyst, two genuinely different pieces of work. The common mistake is writing one story and sending it to both — which is how solid analysis ends up pleasing nobody and changing nothing.

• Leading with methodology. Nobody has ever been persuaded by a paragraph about data cleaning. Put the method in an appendix.
• Too many messages. Two messages means none. Pick the one that matters and let the rest be supporting detail.
• The wrong chart type. A pie chart with nine slices communicates confusion, not composition.
• No "so what". If the reader has to work out the implication, most won't.
• Hiding uncertainty. Show the range, the sample size, the caveat. It builds trust, and it protects you when the number is questioned.
• Pleasing the room. An analysis that avoids the uncomfortable finding is not neutral — it is a decision made badly, by omission.

The local demand is not just for people who can run a query. Employers increasingly want analysts who can take a result to a stakeholder and get a decision out of it. Indicative monthly ranges for data roles in Singapore sit roughly at S$4,000–7,000 for analysts and S$8,000–12,000 and above for senior or lead positions, with the upper end disproportionately going to people who can communicate findings clearly. Ability to present is frequently the difference between the two bands.

This runs alongside national efforts such as IMDA's push on AI adoption and SkillsFuture-supported training, which have made data literacy a mainstream expectation rather than a specialist niche. The same dynamic applies to internal moves: the analyst who can brief a non-technical manager well is the one who gets invited into the decisions.

None of this requires a statistics degree. It requires practice at the specific act of turning a result into a message, delivered to someone who will act on it.

Days 1–10 — Practise the single message. Take any analysis you have already produced. Write its message in one sentence, with no jargon. If you cannot, the finding is not yet clear to you.

Days 11–20 — Build the three beats. Rewrite three past reports using context, conflict, resolution. Keep the appendix. Cut the middle.

Days 21–30 — Present to a real person. Find someone outside your function, give them five minutes, and watch where they get lost. That gap is your next lesson.

Do that once a month for a year and you will be noticeably better than most people who do this work — not because you learned a tool, but because you learned to be understood.