Every business that has built a dashboard has at least one nobody opens. It was specified, built, demoed, and then quietly abandoned — and the usual explanation is that people need to be reminded to use it.
That is almost never the reason. Unused dashboards fail for one of three specific reasons, and none of them is solved by more training or a nicer colour palette.
Failure one: it answers a question nobody was asking
The most common by far. It happens when a dashboard is specified from what the data has rather than from what someone needs to decide.
The tell is that it is organised by data source or by department, and every chart is technically interesting. Nobody looks at it because looking at it does not change what they do next.
The fix: build backwards from a decision. Pick one recurring decision one named person makes — which jobs to chase, which supplier to call, whether to take on the next project — and build the smallest thing that makes that decision faster. One decision, one person, one screen.
That dashboard gets used, because not using it costs its owner something.
Failure two: it is not trusted
Someone once found a number on it that was wrong, or that disagreed with a number they had elsewhere. They mentioned it. It was explained. And from that day the dashboard has been something to verify rather than something to rely on.
Trust in a reporting layer is asymmetric: it takes months to build and one bad number to lose. And an untrusted dashboard is worse than none, because people still open it and then do the work again by hand.
The fix is not a better number, it is a visible definition. Every figure should be able to answer: where does this come from, what exactly does it count, and when was it last refreshed. A "last updated" timestamp is the single highest-value element on most dashboards and is usually missing.
If a number was ever wrong, say so on the dashboard — what was wrong, what changed, from when. Nothing rebuilds trust like a visible correction, and nothing destroys it like a silent one.
Failure three: it arrives at the wrong moment
The dashboard exists, it is correct, it is trusted — and it lives in a tool people open when they remember to. The decision it supports happens in a meeting, or on a phone, or at 7am before a site visit.
A correct answer in the wrong place is not an answer.
The fix: deliver it where the decision happens. That usually means the dashboard stops being the product. The product is the Monday email with three numbers and a link, or the alert when a job crosses a margin threshold, or the view that works on a phone with one hand.
The dashboard becomes the thing you go to when the summary makes you curious — which is the correct role for it.
The test before you build the next one
Before building any dashboard, answer these three in one sentence each:
- Who looks at this, by name?
- What decision do they make differently because of it?
- When do they look — what moment in their week?
If any answer is vague, the dashboard will not be used, and no amount of build quality will change that. It is much cheaper to discover this before it is built than after.
The three questions take five minutes. The dashboard takes two weeks.