How to Design Useful Dashboards

Most dashboards in most organisations are read once at launch, mentioned in a stand-up the week after, and then quietly ignored for the rest of their existence. The investment was real (someone built them, the data team validated them, the launch announcement went out), but the dashboard never crossed over from "interesting" to "essential" for the people it was supposed to serve.

The reason is rarely the BI tool. It is the design of the dashboard itself: too many metrics, no clear decision the dashboard supports, absolute numbers with nothing to compare them against, no signal of how fresh the data is, and an audience for which the dashboard was not really shaped. This article is about the design discipline that turns a dashboard from a decoration into a working tool.

It pairs with the data strategy article, which sits one level above and frames "decisions first, dashboards second"; here, the focus is the artefact itself, written so a team can recognise the patterns that make a dashboard usable and the ones that quietly kill its chances.

The single most useful constraint in dashboard design is to limit each dashboard to one decision. The decision is named, the audience is named, and every element on the page either supports that decision or is removed.

When a dashboard tries to support every possible decision the team might want to make, it ends up supporting none of them well. The user opens the page, sees thirty charts, scans for the one they actually need, gives up, and goes back to asking the question by email. Useful dashboards are short. They have a title that names the decision (not the topic), a small number of charts that speak directly to it, and an obvious "so what" reading that the user can take into a meeting without further interpretation.

If the same audience needs multiple decisions, the answer is multiple dashboards, each named by the decision it supports, not one large dashboard that tries to be all of them. The cost of "one more dashboard" is much smaller than the cost of one dashboard that nobody trusts to give them a clean answer.

The temptation when designing a dashboard is to include every metric the team has access to, on the theory that "more is better, the user can ignore what they do not need". The result is the opposite: the user cannot find what they need because too much else is competing for attention.

A working dashboard typically holds three to seven metrics. The ones at the top are the headline answers to the decision the dashboard supports. The ones below are the supporting context: the components, the breakdowns, the leading indicators that explain the headline. Anything that does not contribute to interpreting the headline is either moved to a separate dashboard or removed.

The discipline is brutal but the payoff is real. A dashboard with three honestly relevant metrics gets used. A dashboard with twenty-five everything-the-team-could-think-of metrics gets bookmarked and never opened.

A single number on a dashboard, without context, tells the reader almost nothing. "Revenue: 4.2M". Is that good? Bad? Up from last month? On track for the quarter? The user has to know the answer before reading the number, which means the dashboard is reinforcing what the user already knew rather than informing them.

Every metric should appear with a comparison. The comparison can be: against the same period last year, against the previous period, against a target, against a forecast, against a baseline. Which comparison is right depends on the decision the dashboard supports, but the absence of any comparison is almost always a design mistake.

The visual encoding matters as much as the comparison itself. A small sparkline next to the headline shows the trend. An arrow with the percentage change makes the direction obvious. A target line on the chart shows whether the metric is on track. None of these are decorative; they are what turns a number into a piece of information.

A dashboard that does not say when the data was last updated is a dashboard the user cannot trust. The most useful question after "what does the number say" is "as of when", and a dashboard that hides the answer is a dashboard the user has to go ask the data team about every time they need to act on the number.

Freshness signalling is small but unmissable. A timestamp at the top of the dashboard, or next to each metric if the refresh cadences differ, with a visual indicator (a coloured dot, a "stale" badge) when the data has not refreshed within its expected window. A dashboard that should refresh every hour but has not refreshed in eight hours is broken; a user who cannot tell whether it is broken is being asked to trust numbers that may be wrong.

The same discipline applies to caveats. If the metric excludes certain segments, if the underlying definition changed last month, if the data is provisional until end of day, that has to be on the dashboard, not in a wiki page nobody reads.

The most common design mistake at the artefact level is to use the same dashboard pattern for executive and operational audiences. They have different jobs and need different shapes.

Executive dashboards answer the question "is the business on track" at a glance. The audience reads them in a meeting or on a phone, between other meetings. The right shape is a small number of headline metrics, each with a clear comparison and trend, and a "so what" that fits in a sentence. Detail is available on click, but the front page is the answer. Frequency is daily or weekly, sometimes monthly.

Operational dashboards answer the question "what should I do today" for a specific role. The audience reads them several times a day, often as part of their workflow. The right shape is fewer headline metrics and more interactive filters, queues, drill-downs that take the user to the action they need to take. Real-time or near-real-time refresh matters here in a way it does not for executive dashboards.

Asking a single dashboard to do both jobs produces something the executive finds too detailed and the operational user finds too high-level, and both stop using it. Two dashboards, designed for two audiences with two jobs, is almost always the right answer.

When a previously well-used dashboard starts being ignored, four causes recur, and each one has a specific fix.

The decision the dashboard supported is no longer the decision the team is making. The fix is to retire the dashboard, or to redesign it around the new decision. A dashboard nobody uses costs maintenance and erodes trust in the data layer; retiring it deliberately is healthier than leaving it stale.

The data has stopped being trusted. Two metrics with the same name show different numbers somewhere else, or a recent change to a definition was not communicated. The fix is upstream of the dashboard, in the governance and definitions side of the data work.

The dashboard has slowly accumulated metrics until it is too long. The fix is editorial: a periodic review where each metric has to justify itself, and the ones that cannot are removed. Dashboards age badly without active pruning.

The owner left the organisation. Without a named owner, the dashboard has no advocate, no one to investigate when a metric looks wrong, no one to retire it cleanly. The fix is to name a new owner, or to retire the dashboard. Ownerless dashboards slowly become broken without anyone noticing.

A useful dashboard is not the one with the most metrics; it is the one designed around a single decision, with the right metrics in the right comparison, with freshness on the page and an owner attached. The dashboards that survive their first quarter are the ones whose design respected the user's time enough to filter what mattered down from what was available.

The wider context, including how dashboard design connects to data strategy, source ownership and the engineering layer underneath, is collected in the data systems and performance insights cluster. And when the question moves from "we have dashboards nobody uses" to "we recognise the pattern and we now need someone to redesign them around the actual decisions, with the right comparisons and the right ownership", that is exactly what my data analysis and decision-support practice is built around.