We Make Dashboards Far Too Quickly

A good dashboard supports a decision someone actually has to make. The problem is rarely bad charts. It is the questions that never get asked before building.

Don Crowley · August 2026 · 4 min read

Dashboards get made far too quickly. A question lands on Monday, a charting tool opens on Tuesday, and by Friday there is a screen full of numbers that everyone politely bookmarks. The speed feels like progress. Mostly it means nobody stopped to ask what the screen is for — and every organisation I have worked in carries the evidence: more dashboards than decisions.

The difference between a dashboard that changes what someone does on a Tuesday and one that only gets bookmarked is not chart choice, and it is not visual polish. It is one question, asked before anything gets drawn: which decision does this support, and who makes it? If neither can be named, what is being built is a report, and it deserves to be built as one.

Five more questions do most of the work

Once the decision has a name, settle these. Every one of them changes what earns a place on the screen:

• How often is it read, and under what pressure? A screen watched hourly by someone on shift and a screen opened weekly in a review meeting are different products that happen to share a name.
• Must it fit one screen? Stephen Few's definition of a dashboard says yes. If your content will not fit, decide now whether to cut it or to admit you are building a page.
• What is the comparison baseline? Previous period or same period last year. For anything seasonal, and everything in education is seasonal, previous period is actively misleading.
• Whose week and whose clock? Week start, timezone, and whether the current period is complete cause more disputed numbers than chart choice ever does. A partial week reads as a collapse.
• How many metrics can earn a place? Decide the ceiling before you fill the space. Four to six summary figures is a workable default. Beyond that it is a list, not a summary.

Say what the reader is looking at

Charts are abstract until words anchor them. They are supposed to help you understand, and they do — but a little explanation helps you understand even better. A header that says "Users over time" describes a topic and hands the reader the work of finding the point. A sub-header that says "Weekly active users rose for a third consecutive week" states the finding, and the chart underneath it becomes the evidence for that sentence. So give every chart both: a header that says what happened, and a sub-header that says what is being counted, over what window, and how to read any emphasis. And if the words and the chart ever disagree, readers believe the sentence — which is exactly why the words deserve the same care as the charts.

Design the failures, not just the success

Every wireframe I have ever been handed shows the dashboard fully loaded, every chart populated, every number healthy. Almost none show the other three states the screen will actually spend its life in: loading, empty, and stale. Those are where trust is won or lost. An empty state must separate "genuinely zero" from "nothing matched your filters" — zero is a finding, empty is a dead end. And a failed refresh must show the last known figure plainly marked as old, because an unmarked stale number that looks current is the single most expensive lie a dashboard can tell.

The same goes for provenance. The cheapest region on any dashboard is a line of small text naming the source table, the week convention, the owner, and a route to the metric definitions. It is also the region that decides whether a number gets acted on or argued with. When a review meeting derails, it is almost never over the chart. It is over what "active user" means.

Record the why, and set an end-of-life date

Two habits separate a working dashboard from a future mystery. The first is recording the context of the decision on the screen itself. Dashboards outlive the conversations that created them: three months on, someone is staring at the screen asking why it was ever made, and nobody remembers what the question was. One line — what we wanted to know, who asked, and when — costs nothing at build time and saves the archaeology later.

The second is newer, and it is one of the quietly liberating things about LLMs and MCP connections to live data: a dashboard that once took a sprint now takes an hour, which means it no longer has to be permanent to be worth building. Build it for the question, answer the question, and then trash it. A dashboard with an end-of-life date attached — a week, a month, whenever its use runs out — is not a lesser artefact. It is what stops the collection becoming a graveyard of screens nobody can explain. I have written before about standing one up between a Monday-morning question and lunch; the other half of that speed is being just as quick to take it down.

The test

So the test for any dashboard, existing or proposed, is short. Name the decision and the person who makes it. State the baseline on the screen. Give every chart a header that says what happened. Show me the empty state and the stale state. Tell me where the numbers come from, why this screen was built, and when it can be taken down. A dashboard that passes is a working tool, whatever it looks like. One that fails was made too quickly — and it is far cheaper to slow down before the build than to win back trust after it.