Rules
Part of Designing dashboards that earn a permanent place on someone's screen
Reading dashboards framework with a sceptical eye
Dashboards framework in two parts: a one page specification, then a four band layout from the answer down to the detail, with a retirement condition.
This is a framework for the hour before anyone opens a charting tool. It has two parts: a one page specification you write and get agreed, and a layout rule that decides what goes where once you start building.
Both exist to prevent the same thing. A page assembled from whatever the data allowed, rather than from what the reader has to decide, cannot be fixed by better charts later.
What to take away
- Write the spec first. If the primary number and its comparison cannot be named in one sentence, the build is premature.
- Lay the page out in four bands, from the answer down to the detail, and make each band earn its space.
- Set the retirement condition at the start. It is the only time anyone will agree to one.
The specification, in one page
| Field | What to write | The test of a good answer |
|---|---|---|
| Reader | A named person or a specific role | Not "the leadership team" |
| Decision | A verb and a frequency | "Reallocates weekly cover" beats "monitors volume" |
| Cadence | How often it is opened, and when | Ties to a meeting, a shift, or an event |
| Primary number | One measure, with its definition | Two candidates means two pages |
| Comparison | Prior period, plan, last year, or an agreed band | Chosen before the data is seen |
| Thresholds | The values that change what the reader does | If none exist, this is not a monitoring page |
| Explaining measures | The two or three that account for the primary one | More than four and you are building a second page |
| Drill path | Where the reader goes when the answer is bad | Named destination, not "they can filter" |
| Freshness promise | How current the data will be, and what happens on failure | Visibly broken beats silently stale |
| Owner and review date | One name, one date | An unowned page is a page nobody will retire |
| Retirement condition | What would make this unnecessary | Agreed now, while it costs nothing |
Two fields do most of the work. The decision field, because a page serving a topic rather than a choice will be opened twice. And the retirement condition, because it is the only field that ever gets negotiated away later.
One-page dashboard specification
- Readera named person or role
- Decisiona verb and a frequency
- Cadencewhen it is opened
- Primary numberone measure, defined
- Comparisonchosen before data is seen
- Thresholdsvalues that change action
- Drill patha named destination
The four band layout
Band one: the answer. The primary number and its comparison. Large, top left, above everything. A reader who sees only this band should know whether to keep reading.
Four bands, answer down to detail
- Band one: the answer, top left
- Band two: the drivers, no scrolling
- Band three: the segments, one dimension
- Band four: the detail, below the fold
Band two: the drivers. The two or three measures that explain the primary one. Same window, same scale conventions, arranged so that a reader can attribute the movement in band one without scrolling.
Band three: the segments. The same story cut by the dimension the reader would act on: team, region, product, channel. One dimension, not five. This is the band that tells the reader where to intervene.
Band four: the detail. Rows, exports, long tables, and anything diagnostic. Below the fold on purpose. People who need it will scroll; people who do not are not distracted by it.
The bands are a claim about priority, and they force a useful argument early. If two people disagree about what belongs in band one, they disagree about what the page is for, and that is much cheaper to resolve now than after the build.
Matching the shape to the reader's task
Once the bands are settled, each slot has a job, and the job determines the shape.
- Judging against a threshold: a value with an explicit expected range drawn behind it, which is the everyday form of a control chart.
Match the shape to the task
Reader task
- Judging a threshold
- Value with expected range
- Attributing a change
- Decomposition into contributions
- Finding where to act
- Ranked or exception view
- Following a group ageing
- Cohort layout, incomplete marked
- Checking composition
- Shares over time
Shape to use
- Judging a threshold
- Attributing a change
- Finding where to act
- Following a group ageing
- Checking composition
Choosing the shape from the task rather than from the data type is the habit that separates a page people use from a page that is technically complete.
What earns a place on the page
Apply one test to every element: what does the reader do differently because this is here? An element that fails the test is not neutral. It costs attention, it costs load time, and it gives the page an air of comprehensiveness that discourages anyone from asking whether the important part is right.
Two elements always earn their place and are usually missing: the last updated time, and a link to the definition of the primary number. Both are cheap, and both are what a reader reaches for at exactly the moment they start to doubt the page.
Running the spec as a conversation
Fill the sheet in with the reader present, in about twenty minutes. Three outcomes are all successes.
Twenty minutes with the reader
Can the reader name the decision?
complete the sheet and build
sit in the meeting and watch
You complete it and build. You discover the decision is made monthly from a fixed window, which means the requirement is a report rather than a page. Or you discover nobody can name the decision, and the honest next step is to sit in the meeting where it gets made and watch what people argue about.
The third outcome saves the most time and is the one most often skipped.
Related reading on this site
Product level questions, the three dashboard kinds, and the case for retiring them: dashboard design. Choosing the panel shape once the slot is defined: twelve panel shapes. The general build order this sits inside: the six layer model.
Deciding what promise the page carries: the three publication tiers. Defining the primary number precisely enough to survive reuse: writing a metric definition.
Common questions
Is a spec not overhead for a small page?
It is fifteen minutes, and the first two fields alone prevent the most expensive outcome, which is building the wrong artifact well.
What if the reader wants everything on one page?
Ask which single number they would want if the connection dropped after one tile loaded. That question produces band one quickly, and the rest of the conversation gets easier.
Can one page serve two readers?
Only if they share a decision. Two decisions on one page means each reader filters past the other's material every time, and both eventually stop.
Nobody will agree to a retirement condition.
Offer a review date instead, and put it on the page. A visible date does most of the same work, because it makes the question askable without anyone having to raise it.
