Dashboards and KPIs¶

Exercise dashboards-and-kpis-annex.pdf · PDF

You are in the middle of a boss fight. How much health do you have left? You know without stopping: a glance at the corner of the screen, half a second, back to the fight. Nobody opens a menu and reads a table to find out if they are about to die.

In Unit 3 you built charts: a bar, a line, a histogram, a scatter, a pie, a heatmap. Each one lives on its own page in Superset. Now imagine a boss with 30 seconds to spare. Do they open seven tabs? No. They need one screen that tells them what matters. That screen is a dashboard, and it is 60% of your RA3 mark.

A dashboard is the HUD of your data¶

All year we have compared this module to a crafting game: you obtain materials, you prepare them, you analyse them, and at the end you represent them. In a game, that last stage has a name: the HUD (heads-up display), the layer drawn over the game with the health bar, the minimap and the ammo counter.

Why is the health bar a bar in the corner and not a table inside a menu? Because you must read it without stopping to play. A dashboard has exactly the same job.

A dashboard is a single screen that groups the few charts and numbers one audience needs to follow one subject and act on it.

Read that definition slowly. Every piece of it is a rule:

This is not a classroom invention. In 2004 the data visualisation author Stephen Few wrote an article called Dashboard Confusion because every software company was using the word for something different. His definition became the standard one: a dashboard is "a visual display of the most important information needed to achieve one or more objectives that has been consolidated on a single computer screen so it can be monitored at a glance". Same ingredients: the most important information, one screen, a glance.

Three questions before you draw anything¶

A game designer does not start by drawing bars. They start by asking what the player needs to know while fighting. Before you open Superset, answer three questions. In class we answer them for our running example, a dashboard called Steam market built on the table games_clean, the cleaned Steam catalogue from Unit 2.

The audience is the specific person or group the dashboard is made for. The purpose is the decision that the dashboard helps that audience take.

Change the audience and the dashboard changes, even with the same data. A journalist writing about the history of Steam does not care about a launch price. They want the growth of the catalogue, front and centre. Same table, different HUD.

Reading order: three bands¶

Where do you put things? Not wherever they fit. People who read from left to right start at the top-left corner, so that corner is the most expensive spot on the screen. Spend it on the most important thing.

Split the empty screen into three horizontal bands:

The reader who has five seconds reads only the top band and still leaves with the essentials. The reader who has a minute goes down to the middle. Only the curious reach the bottom.

Here is the plan for Steam market, as you would sketch it on paper:

flowchart TB
    subgraph TOP ["<b>Top band</b>: the KPIs (health and ammo)"]
        direction LR
        K1["<b>Games</b><br>26,685"] ~~~ K2["<b>Free share</b><br>11.6%"] ~~~ K3["<b>Median price</b><br>4.99"] ~~~ K4["<b>Hits</b><br>623"]
    end
    subgraph MID ["<b>Middle band</b>: trends and comparisons (the minimap)"]
        direction LR
        M1["<b>Line chart</b><br>games released per year"] ~~~ M2["<b>Bar or pie chart</b><br>games per price band"]
    end
    subgraph BOT ["<b>Bottom band</b>: detail (the inventory)"]
        direction LR
        B1["<b>Histogram</b><br>how prices are distributed"] ~~~ B2["<b>Scatter plot</b><br>price against Metascore"]
    end
    TOP --> MID --> BOT

How many charts?¶

Few. The rule of thumb in this course: one screen, at most 8 charts, and every one of them earns its place.

Notice what is missing from the plan above: the heatmap from Unit 3. It is a perfectly good chart. But it does not help a studio choose a price, so it stays out. Leaving a good chart out is the hardest part of the job, and the part that makes the rest readable.

KPIs: numbers with a job¶

The top band holds the KPIs. The word sounds like business jargon, but the idea is simple.

A KPI (key performance indicator) is a number with a definition, a unit and a decision behind it.

Your health bar is a KPI. Definition: hit points left out of the maximum. Unit: points. Decision: under 20%, you stop attacking and heal. Take away any of the three and it is just a number on the screen.

Is "games: 26,685" a KPI for our indie studio? On its own it is context: it says how big the market is, and that is useful to read first. But "median price: 4.99" is the real KPI. It tells the studio where to price.

Here are the four numbers of the top band, each with its formula. A KPI without its formula written next to it cannot be trusted, because nobody knows what was counted.

A hit here is a game with at least one million owners. That is the Hit value of the column owners_tier you built in Unit 2 (Categorisation).

You can check all four in one query in SQL Lab:

SELECT COUNT(*) AS games,
       ROUND(AVG(is_free::int), 3) AS free_share,
       PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY price) AS median_price,
       COUNT(*) FILTER (WHERE owners_tier = 'Hit') AS hits
FROM games_clean;

is_free is a true/false column. ::int turns true into 1 and false into 0, so the average of the column is the share of free games: 0.116, which is 11.6% (3,094 games out of 26,685).

Two KPIs that can lie¶

A KPI is one number, huge, with nothing around it. That makes it powerful, and dangerous: there is no axis, no shape, nothing to warn the reader. Two traps from our own data.

The average that is not typical. Why the median price, 4.99, and not the average? The average price in games_clean is 7.91. You saw the reason in Exploratory statistics: price is skewed. A few very expensive products (the most expensive costs 595.99) drag the average up. Half of all the games cost 4.99 or less. A studio that priced "at the average" would be above most of its rivals.

The average that hides its base. The average Metascore of the table is 71.9. It looks like a quality score for Steam. But run this:

SELECT ROUND(AVG(metascore)::numeric, 1) AS avg_metascore,
       COUNT(metascore) AS rated,
       COUNT(*) AS games
FROM games_clean;

Only 2,849 games have a Metascore: 10.7% of the catalogue. And they are not a random sample. They are the games that got enough professional reviews to receive a score at all. So 71.9 describes those games, not Steam.

Try it: sketch on paper first¶

No Superset yet. Professionals sketch dashboards on paper because paper is fast and nobody falls in love with a pencil box. Take a sheet, landscape, and a pencil.

The sketch is finished when it has the audience, the purpose, four KPI boxes with formulas, at most five chart boxes with a question each, and one discarded chart with a reason.

The dataset behind all of this is on the Resources page.

Key takeaways¶

• A dashboard is a single screen with the few charts and numbers one audience needs to follow one subject and act on it. It is the HUD of your data.
• A dashboard is not a gallery. It starts from the reader's question and leaves charts out: at most 8 on one screen.
• Before drawing, answer three questions: who reads it, what for, how often.
• Order the screen in three bands: KPIs on top (the eye starts top-left), trends and comparisons in the middle, detail at the bottom.
• A KPI is a number with a definition, a unit and a decision. Write its formula next to it.
• KPIs can lie: with skewed data use the median (4.99), not the average (7.91), and always show the base of an average (n = 2,849).

Quick check¶

You have a plan on paper and four KPIs with their formulas. Time to make it real: next, Building a dashboard in Superset.