Every organisation we’ve worked with has a graveyard of dashboards. Beautifully built, technically correct, linked in some onboarding doc — and opened by no one. The instinct is to blame adoption: people just need training, or a nudge, or a mandate. The instinct is wrong. People don’t use dashboards that don’t help them decide anything.

Built around data, not decisions

The typical dashboard is assembled by asking “what data do we have?” and putting all of it on a screen. The result is a wall of charts, each individually reasonable, that collectively answers no question. The viewer has to do the work of synthesis — and a busy director will simply not do that work. They’ll go back to asking an analyst, which is exactly the bottleneck the dashboard was meant to remove.

A useful dashboard starts from the opposite end: what decision does this person make, and how often? Everything on the screen earns its place by informing that decision. Everything else — however interesting — is removed.

If you can’t name the decision a chart supports, the chart shouldn’t be on the dashboard.

The three-question test

Before we build any reporting, we ask the eventual user three questions:

  • What will you do differently depending on what this shows? If the answer is “nothing, I’d just like to know,” that’s a curiosity, not a decision — and it belongs in an occasional report, not a daily dashboard.
  • What’s the threshold that changes your action? A revenue number is noise until you know the level at which you’d intervene. Designing for the threshold tells us what to highlight.
  • How quickly do you need to know? A board metric reviewed monthly and an ops metric watched hourly are different products, even if they share a data source.

The answers determine the layout, the cadence, the level of aggregation, and — critically — what to leave out.

Subtraction is the work

Good dashboard design is mostly subtraction. The hardest conversations are about what to remove: the vanity metric a stakeholder is attached to, the chart that’s “nice to have,” the breakdown nobody acts on. Every element you remove makes the ones that remain easier to see.

We aim for a dashboard a user can read in the time it takes to drink a coffee, and act on without asking anyone a follow-up question. That usually means one primary number, the trend behind it, and the one or two cuts that explain a change. Not forty tiles.

Make the default the right answer

The best reporting makes the correct interpretation the easy one. That means honest scales that don’t exaggerate, a clear marker for “is this good or bad?”, and uncertainty shown rather than hidden. A forecast without a confidence band invites false precision; a band makes the viewer appropriately cautious without a word of explanation.

It also means putting the number where the decision is made. The most-used “dashboard” we ever built wasn’t a dashboard at all — it was three numbers piped into the channel where the team already worked, with a link to the detail for the rare moment someone needed it.

The test of a good dashboard

You’ll know reporting is working when the questions stop. When the weekly “can you pull me the numbers” emails dry up, when meetings open with everyone already aligned on the figures, when a decision that used to take a week of back-and-forth happens in the room. That’s the outcome. The dashboard is just how you get there — and if it isn’t getting you there, no amount of polish will save it.