Dashboards framework: a clear way to organize the work

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.

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.

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.
• Attributing a change: a decomposition into contributions, not two lines on one chart.
• Finding where to act: a ranked or exception view, sorted by the measure, not by name.
• Following a group as it ages: a cohort layout, with incomplete cells marked. Where several groups have to be compared side by side, small multiples beat one crowded chart.
• Checking composition: shares over time, read for the overall shift rather than for any middle band.

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.

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

The product level questions, the three kinds of dashboard, and the case for retiring them are in dashboard design. For choosing the panel shape once the slot is defined, see twelve panel shapes. For the general build order this sits inside, see the six layer model. For deciding what promise the page carries, see the three publication tiers, and for defining the primary number precisely enough to survive reuse, see 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.