Designing a dashboard for decisions
A dashboard earns its place when the people who open it decide something faster. This lesson shows you how to design one around its users and their decisions: what goes on it, where it goes, which comparisons and colours it uses, and how to test a wireframe before you build anything.
By the end you can
- Write a decision table: who opens the dashboard, when, what they decide and which question each part answers
- Lay out a dashboard from overview to detail, with KPI tiles on top and a trend and a breakdown below
- Design KPI tiles with a comparison, a target and a written status rule that uses colour only for meaning
- Choose filters, defaults and a phone layout that fit how people really read the dashboard
- Wireframe a dashboard, run a five-second test, and write the SQL behind its tiles
The everyday picture
Think of the departures board at an airport. Thousands of people read it every hour, and each of them has one decision to make: where do I go, and do I need to hurry? The board shows only what that decision needs: flight, destination, time, gate and status. It does not show fuel loads, crew rosters or catering orders, even though the airport has all of that data.
Most lines on the board look the same. Colour and words appear only when something needs action: "Boarding", "Delayed", "Gate closed". The ground crew and the control tower have their own screens with very different content, because they make different decisions. A good business dashboard follows the same rules: one audience, one job, the few numbers that job needs, and visual emphasis only where someone should act.
Start from the people and their decisions
Stephen Few, who has written the most widely read books on dashboard design, describes a dashboard as a single screen that shows the most important information someone needs for a job, arranged so it can be read at a glance. Two parts of that idea matter most: a job, and at a glance. A page with 30 charts that answer everyone's questions is a report, or a collection of reports.
Most bad dashboards are built from the wrong end. Someone lists the data that exists, or collects every chart that anyone asked for, and puts it all on the page. The result looks thorough and helps nobody, because the one number that should drive a decision is lost among twenty that never will. Start instead from the people:
- Who opens it? Name roles, not "management".
- When, and for how long? Monday 9:00 for a 30-minute meeting is a very different design brief from "all day on a second monitor".
- What decision do they make with it? "Which cities get extra help this week" is a decision. "Keep an eye on sales" is not.
- What question must be answered to make that decision, and what would they do if the answer were bad?
Write the answers in a decision table, one row per decision. Every tile and chart on the dashboard must point back to a row. A quick test for any proposed element: if this number moved by 10%, who would do what? If nobody would do anything, the element belongs somewhere else.
The same thinking gives you the most important rule of scope: one dashboard per audience and job. Few groups dashboards by the role they play. Strategic dashboards track a few measures against plan for leaders, usually weekly. Operational dashboards help people run the day, such as a store manager at 7:30 in the morning. Analytical dashboards are for exploring causes, with many filters and drill paths. Mixing them gives leaders a page full of filters they never touch and gives store managers company-wide totals they cannot act on. When a request does not fit the audience, link to the right dashboard instead of adding a chart.
Every number on a leadership dashboard should be a certified metric from the dictionary you built in Metrics everyone agrees on. For choosing the measures themselves (one main measure, its inputs and guardrails), see pm-21.
Quick check
Which proposed element fails the "who would do what?" test on a weekly dashboard for the leadership team?
No leader changes a decision on Monday because of a shift between operating system versions; that chart belongs on the app team's own dashboard. A city behind plan leads to help for that city, and stock-out losses above the limit lead to supply fixes, so both pass.