Turn analysis into charts people read correctly: visual principles, matplotlib and seaborn, small multiples, dashboards and a short data story.

Data Visualization & Storytelling

Pick one audience and write one sentence: who checks this dashboard, how often, and which decision it helps them make (for example, a café owner each Monday deciding how much stock to order).

List three to five questions that person needs answered to make that decision.

For each question, choose one tile: a headline number, a trend line, a sorted bar chart or a short table. Write which chart type and why.

Add a comparison to every headline number (vs target, vs last period or vs last year) and write how it would be shown.

Draw the layout as boxes on one page: the most important KPI top-left, headline numbers across the top, trends in the middle, detail at the bottom.

Write a short definition for each metric (what is included and excluded) and note where the data would come from and how often it refreshes.

Show the sketch to someone else for two minutes, then ask what they think the dashboard is telling them. Note anything they misread.

## Why it matters

A dashboard is a set of charts and numbers, usually on one screen, that someone checks regularly to monitor something and decide what to do. Most dashboards fail not because of bad charts but because nobody decided **who** it was for and **what decision** it supports. The result is 25 tiles, five filters and no clear message, and people go back to asking the analyst for a spreadsheet.

Good dashboard design starts on paper, long before any BI tool.

## Three kinds of dashboard

- **Strategic** (executives, checked weekly or monthly): a handful of top-level KPIs against targets, with trends. "Are we on track?"
- **Operational** (team leads, checked daily or live): current status and exceptions. "What needs attention right now?" Think support queue size, orders stuck in shipping.
- **Analytical** (analysts, explored as needed): filters and breakdowns for investigating why something changed.

Trying to make one dashboard serve all three usually serves none. Pick one.

## The design process

**1. Name the audience and their decisions.** Write one sentence: "The support team lead checks this every morning to decide where to assign agents." If you cannot write this sentence, you are not ready to build.

**2. List the questions.** From the decision, list three to five questions. "How many tickets are open? Is the queue growing? Which category is backed up? Are we meeting the 24-hour response target?"

**3. Choose KPIs and charts for each question.** Each question gets one tile: a big number (with comparison), a trend line, a sorted bar chart, or a short table. Use the chart-choice rules from Module 1.

**4. Add comparison to every number.** "1,240 open tickets" means nothing alone. "1,240 open tickets, up 18% vs last Monday, target under 1,000" tells the reader whether to worry. Comparisons can be: vs target, vs previous period, vs same period last year, or vs average.

**5. Lay out by priority.** People read screens in an F or Z pattern: top-left first. Put the most important KPI there, a row of headline numbers across the top, trends in the middle, and detail (breakdowns, tables) at the bottom.

**6. Keep it to one screen.** If it scrolls, the bottom is rarely seen. Five to nine tiles is a sensible range.

**7. Decide filters sparingly.** A date range and one key dimension (region, team) are often enough. Every filter is something the reader has to set correctly.

## Worked example: support team lead

Audience: support team lead, every morning. Decision: where to assign agents today.

Wireframe (sketched as boxes on paper):

```text
+----------------+----------------+----------------+----------------+
| Open tickets   | New yesterday  | Median first   | % within 24h   |
| 1,240 (+18%)   | 410 (-3%)      | response 6.2h  | 91% (target 95)|
+----------------+----------------+----------------+----------------+
| Open tickets per day, last 30 days (line, target line at 1,000)   |
+-----------------------------------+-------------------------------+
| Open tickets by category (sorted  | Oldest 10 open tickets        |
| bars, Shipping highlighted)       | (table: id, age, category)    |
+-----------------------------------+-------------------------------+
Filters: date range, team.  Data refreshed hourly from the help desk.
```

Each tile answers one question from step 2. The headline row uses colour only for the KPI that misses its target. The table at the bottom is actionable: the lead can assign those exact tickets.

## Practical details that build trust

- **Show when the data was refreshed** and where it comes from.
- **Define every metric**, in a tooltip or an "About" panel: what counts as "open"? Are spam tickets excluded?
- **Use consistent colours**: if Shipping is orange in one tile, it is orange everywhere.
- **Round sensibly**: 6.2h, not 6.18734h.

## Common mistakes

- Building first and asking questions later.
- Vanity metrics (total sign-ups ever) that only go up and never change a decision.
- Gauges and speedometers that use a lot of space for one number.
- Every tile a different colour scheme.
- No comparisons, so nobody can tell good from bad.

## Quick recap

- One audience, one set of decisions, three to five questions.
- One tile per question, each number with a comparison.
- Most important at top-left; detail at the bottom; one screen; few filters.
- Show definitions and refresh times.

## Try it

The **Do** tab walks you through sketching a dashboard on paper for one audience of your choice.


Sketch a dashboard for one audience by starting from their decisions, choosing a few KPIs, and laying them out by priority.

Dashboard design

12 Dashboard design tips for better data visualization

Data Dashboard Design Best Practices

Create a small sample dataset with columns date, region, category, units and revenue (at least 100 rows over several months). You can generate it in Python or type a short version into a spreadsheet.

Connect the dataset in your chosen tool (Google Sheets or CSV upload in Looker Studio; Get data > Excel/CSV in Power BI Desktop).

Check the field types: date is a date, units and revenue are numbers. Fix any that are text.

Create one central measure for total revenue (a calculated field in Looker Studio or a DAX measure in Power BI).

Add a headline number for total revenue with a comparison to the previous period.

Add a monthly revenue trend chart and a bar chart of revenue by category sorted descending.

Add a date range filter and one region filter, and confirm every chart responds to them.

Add a text box with the data source, a definition of revenue and the date you built it.

Take a screenshot for your portfolio. If you shared the report, set sharing to view-only, or remove sharing when you are done.

## Why it matters

Python is ideal for analysis and one-off charts, but most organisations share regular reporting through **business intelligence (BI) tools**: Power BI, Tableau, Looker Studio, Looker, Qlik, Metabase, Apache Superset and others. Job postings for data analysts mention at least one of these more often than not. The good news is that they share the same core ideas, so learning one makes the next much easier.

## What a BI tool does

Almost every BI tool has the same five parts:

1. **Data connection.** Connect to a spreadsheet, CSV, database or warehouse (Google Sheets, Excel, PostgreSQL, BigQuery, Snowflake...). Some tools import a copy; others query the source live.
2. **Data model.** Define tables and how they relate (for example, `orders` joined to `customers` on `customer_id`), set data types, and mark which fields are dimensions and which are measures.
3. **Calculated fields and measures.** Formulas such as `Revenue = SUM(quantity * unit_price)` or `Conversion rate = buyers / visitors`. Defining a metric once, centrally, is what keeps every chart consistent.
4. **Visuals.** Drag fields onto a chart: a dimension (region, month) on an axis, a measure (revenue) as the value.
5. **Interactivity and sharing.** Filters, date pickers, drill-down, scheduled refresh, and sharing with permissions.

**Dimensions vs measures** is the key vocabulary. A dimension is something you group or filter by (category, date, region). A measure is a number you aggregate (sum of revenue, count of orders, average delivery time). Most confusing BI results come from aggregating the wrong way, such as averaging an average.

## A quick tour of free options

| Tool | Cost to learn | Runs on | Notes |
|---|---|---|---|
| **Looker Studio** (Google) | Free with a Google account | Web browser | Easy sharing; great with Google Sheets and BigQuery. |
| **Power BI Desktop** (Microsoft) | Free download | Windows only | Very common in job postings; publishing to the online service needs a work account and often a licence. |
| **Tableau Public** | Free | Windows, macOS | Everything you publish is **public**; never upload private data. |
| **Metabase / Superset** | Free, open source | Self-hosted (Docker) | Popular in startups; needs a little setup. |

Pricing and features change, so check each vendor's site before relying on a feature. Free tiers are enough to learn and to build portfolio pieces. Never upload confidential or personal data from work or school to a public or personal account.

## Worked example: a sales dashboard in Looker Studio

1. Put a small dataset in Google Sheets: columns `date`, `region`, `category`, `units`, `revenue` (a few hundred rows is plenty; you can generate them with pandas or use a public sample dataset).
2. In Looker Studio, create a blank report and add the sheet as a data source. Check each field's type: `date` should be a Date, `revenue` a Number (currency).
3. Add a **scorecard** for total revenue and set "comparison date range" to the previous period. This gives you the number plus a percentage change.
4. Add a **time series chart** with `date` (granularity: month) and `revenue`.
5. Add a **bar chart** with `category` as the dimension, `revenue` as the metric, sorted descending.
6. Add a **date range control** and a **drop-down control** for `region`. Every chart on the page now responds to them.
7. Add a text box with the data source and a one-line definition of revenue.
8. Use **Share** (view-only) to send it to a friend for feedback, or keep it private.

Power BI Desktop follows the same path: Get data, check types in Power Query, build visuals on the report canvas, add slicers (filters), and write measures in DAX, such as `Total Revenue = SUM(Sales[revenue])`.

## Common mistakes

- **Aggregating twice.** Averaging a column that already contains averages gives a wrong overall average. Compute ratios from sums: `SUM(buyers) / SUM(visitors)`.
- **Wrong field types.** A date stored as text sorts alphabetically and cannot be grouped by month.
- **Metrics defined in each chart.** Define them once as a calculated field or measure.
- **Publishing private data publicly**, especially on Tableau Public.
- **Over-filtering.** Ten filters make a dashboard hard to use and easy to misread.

## Quick recap

- BI tools connect data, model it, define measures, draw visuals and share them with filters.
- Dimensions are grouped by; measures are aggregated.
- Learn one free tool well; the concepts transfer.
- Define metrics once, check field types, and keep private data private.

## Try it

The **Do** tab walks you through building a small dashboard in Looker Studio or Power BI Desktop, using only free tools and sample data.


Understand what BI tools do and build a small interactive dashboard in a free tool such as Looker Studio or Power BI Desktop.

BI tools tour

Looker Studio Tutorial For Beginners

Power BI from ZERO to Your First Dashboard (in 20 Minutes)

Write your big idea in one or two sentences: we should [action] because [evidence], which will [benefit].

Write the three slide titles as full-sentence takeaways (context and question, key evidence, recommendation and ask). Check that the titles alone tell the story.

Build slide 2's chart: decluttered, one highlight colour, a direct annotation at the key point, rounded numbers.

On slide 3, write the recommendation, the expected impact as a range, at least one caveat, and the specific decision you are asking for.

Move any supporting charts or method notes into an appendix slide.

Rehearse out loud and time yourself; aim for three to five minutes. Then try giving the whole story in 60 seconds without slides.

Present to a friend, classmate or study group and ask them to repeat back your message and your ask.

## Why it matters

Analysts are often judged less by the quality of their analysis than by whether anyone acts on it. A correct finding buried on slide 14 changes nothing. A **data story** is a short, structured presentation that takes the audience from a question to a recommendation, with just enough evidence to trust it. It is not about drama or spin; it is about respecting the audience's time.

## Find the one message first

Before you open any slide software, finish this sentence in no more than two lines:

> "We should **[action]** because **[evidence]**, which will **[benefit]**."

For example: "We should add a delivery-time estimate to the checkout page because 38% of abandoned carts happen on the shipping step, and the stores that tested it recovered about a fifth of those carts."

Nancy Duarte and Cole Nussbaumer Knaflic both recommend this "big idea" step. If you cannot write it, your analysis is not finished, or you are trying to say too many things.

## A three-slide structure

For a short update (five minutes or less) three slides is enough:

**Slide 1: Context and question.** What situation are we in, and what question did we ask? Include one number that shows why it matters. "Checkout completion fell from 64% to 58% this quarter. We looked at where customers drop off."

**Slide 2: The key evidence.** One chart, decluttered, with a takeaway title that states the finding. "Most drop-off happens at the shipping step." Highlight the bar or line that proves the point. Put supporting detail in an appendix, not on this slide.

**Slide 3: Recommendation and next step.** The action, its expected impact (with a range if uncertain), what it costs, the caveats, and the decision you need from the audience. "Recommend: show delivery estimates at checkout. Expected: recover 15% to 25% of shipping-step drop-offs. Caveat: based on a two-week test in three stores. Decision needed today: approve a four-week A/B test."

This follows a classic arc: setup, conflict, resolution. It also follows the "answer first" pyramid principle: busy readers who only see slide 3 still get the message.

## Make each slide readable

- **Headline = the takeaway**, written as a full sentence.
- **One chart per slide**, sized large enough to read from the back of the room.
- **Highlight with colour**, grey the rest (Module 1).
- **Annotate**: add a short label directly on the chart at the point that matters ("Shipping step: 38% of drop-offs").
- **Numbers rounded** to what the decision needs: "38%", not "37.86%".
- **Speak to the chart, do not read it.** Say what to look at, then why it matters.

## Know your audience

- **Executives** want the answer, the impact and the decision needed. Lead with slide 3 if time is very short.
- **Technical peers** want method and caveats. Keep them in a backup slide and be ready to show it.
- **Mixed audiences**: main story for everyone, appendix for detail.

Ask in advance: how much time do I have, what do they already know, and what decision can they actually make?

## Be honest about uncertainty

Storytelling can slide into overselling. Protect your credibility:

- State sample sizes and time periods.
- Give ranges, not false precision.
- Say what the data cannot tell you ("this shows association; the A/B test will show cause").
- Do not cherry-pick a date range that flatters the result.

## Worked example: rehearsal checklist

Before presenting, run through:

1. Can someone who sees only the slide titles repeat the message?
2. Does every chart support the message on its slide?
3. Is there one clear ask?
4. Can you give the whole story in 60 seconds without slides?
5. Have you prepared answers for "how do you know?" and "what if you are wrong?"

## Common mistakes

- Walking through the analysis in the order you did it ("first I cleaned the data...").
- Several messages competing on one slide.
- Default chart titles such as "Funnel by step".
- No recommendation, just "interesting findings".
- Hiding caveats until someone asks.

## Quick recap

- Write the one-sentence big idea before building slides.
- Three slides: context and question, key evidence, recommendation and ask.
- Takeaway titles, one highlighted chart per slide, annotations, rounded numbers.
- Be clear about uncertainty; it builds trust.

## Try it

The **Do** tab has you build and present a three-slide data story from an analysis you have already done.


Structure a short data story around one message and one recommended action, and present it in three slides.

Presenting a data story

Telling Stories with Data in 3 Steps (Quick Study)

Data Storytelling 101 | Think Like a Data Analyst

Design a dashboard for one audience, build it in a free BI tool, and present a short data story that ends in a decision.