Every organization has them: dashboards that took weeks to build, launched with a demo, and now sit unopened while the real decisions are made from a spreadsheet someone emails on Monday. The usual response is a redesign. New colors, a cleaner layout, a different tool. It rarely helps.
Our view is that dashboards rarely fail on design. They fail on trust. A dashboard nobody opens is not finished, and the fix starts well before anyone draws a chart.
The symptoms
You can usually spot an unused dashboard without checking the usage logs:
- Meetings start by reconciling numbers instead of discussing them.
- People export the data to a spreadsheet and rebuild the view they wanted.
- The same question has two or three dashboards, each with a different answer.
- Nobody can say who to call when a figure looks wrong.
- An older report is still circulated "because people are used to it".
Four reasons dashboards go unused
1. There is no shared definition
Ask three teams how many active customers you have and you may get three answers. Finance counts one way, sales another, operations a third. Often the difference is the definition, not the arithmetic. Once a reader has seen two dashboards disagree, they stop trusting both, and the dashboard that was right loses along with the one that was wrong.
2. It was built for the builder
Forty charts, six filters and every measure at equal weight. That is what a dashboard looks like when it was built to show what the data contains rather than to support a decision someone makes. The reader has to do the analysis the dashboard should have done.
3. Nobody owns it
A source system changes, a field is renamed, and a number drifts. If the dashboard has no owner, nobody notices until a reader does. They quietly go back to the spreadsheet, and they do not come back.
4. The old report was never retired
A new dashboard launched alongside the report it was meant to replace has to win a contest it did not need to enter. People keep the habit they have. Replacing a report means switching the old one off.
Treat reporting as an estate
The question to start with is not "how many dashboards do we need?" It is which decisions matter, which numbers support them, what reporting already exists, and what can be retired. Every existing report gets one of four calls:
| Call | When it applies |
|---|---|
| Keep | Used, owned, and in line with the agreed definition |
| Consolidate | Several reports answering the same question |
| Automate | Still assembled by hand every cycle |
| Retire | Nobody opens it, or nobody owns it |
Modernizing reporting usually means fewer reports, not more. Each one that stays should have an owner and a purpose you can state in a sentence.
Put a figure on what the current estate costs, where your records allow it: the hours spent assembling recurring reports by hand, the time spent reconciling numbers before meetings, how long decisions wait for their report, and what is paid in licences and capacity for reports nobody opens. That figure is what makes retirement a business decision rather than a matter of taste, and it gives the sponsor something to defend when a team asks to keep its favorite report.
Define the number once, then design
Before a chart is drawn, every measure on it needs three things written down: a definition (what counts and what is excluded), a source, and a named owner who approves changes. Those definitions belong in a governed semantic layer that sits behind every dashboard, report and export, so a metric is defined once and reused everywhere.
This is the unglamorous part, and it is where most of the value sits. When the finance pack, the sales view and the executive dashboard all show the same figure, the meeting moves from "which number is right?" to "what do we do about it?"
Design for one reader and one decision
Once the numbers agree, design decides whether anyone acts on them. Good information design is mostly what you take out. For each view, answer three questions:
- Who reads it? One role, not "the business".
- What do they decide? One decision, on a known cadence.
- What do they do next? One obvious action from the view.
Put what is off target first and let what is on target stay quiet. Show the definition, the owner and the refresh time on the view itself, so a reader never has to ask where a number came from. Then build it with the person who will use it in the room, not from a requirements document.
Resist the request to add "just one more chart". Each addition is reasonable on its own, and together they turn a decision view back into a data catalog. If a new question keeps coming up, it may deserve its own view, for its own reader, or a place in self-service.
Measure use, not delivery
Most BI projects end at launch. That is the wrong finish line. Treat use as the deliverable, and track it where usage data is available:
- who opens it, how often, and in which roles;
- whether the meeting it was built for actually relies on it;
- which old reports were retired because this one replaced them;
- how many questions people now answer without raising a ticket;
- who owns each metric when a source changes.
If a dashboard is not used a few cycles after launch, find out why from the people who were meant to use it. Sometimes the answer is a missing measure. Often it is that the decision is made somewhere else, and the dashboard should be retired too.
A checklist before you build the next one
| Check | Ready when |
|---|---|
| Decision | You can name the reader, the decision and its cadence |
| Definitions | Every measure has a written definition, a source and an owner |
| Overlap | Existing reports on the same question are listed for consolidation or retirement |
| Design | The exception comes first, and the next step is on the view |
| Ownership | Someone is named to respond when a number looks wrong |
| Use | You have agreed how use will be measured after launch |
If the definitions are sound but people still want to explore beyond the dashboard, the next question is self-service. We cover that in self-service analytics without the chaos.
