A dashboard project almost always starts in the same place: someone opens the tool, looks at what data is available, and starts arranging it into tiles.
Six months later the dashboard exists, is technically correct, and nobody opens it.
The mistake happened at the very beginning. The question asked was "what can we show?" when it should have been "what are we trying to decide?"
Dashboards do not create decisions
They support them. A dashboard with forty metrics is a browsing experience, and people do not browse at work. They arrive with a question, look for the answer, and leave. If the answer is not obvious in about five seconds, the question gets answered somewhere else — usually by a colleague who keeps their own spreadsheet.
This is why the most-used dashboards in most organisations tend to have very few tiles on them.
The exercise that changes the conversation
Before anyone opens a BI tool, sit down with the person who will actually use the thing and ask four questions.
What decision do you need to make? Not "understand performance" — a specific decision, made by a specific person, on a specific cadence. "Whether to move depot capacity next week." "Whether to chase this monthu2019s collections." "Whether the new pricing tier is working."
What do you look at today to make it? The honest answer is often an inbox, a WhatsApp thread, or a colleagueu2019s summary. Understanding the current workaround tells you what the real requirement is, and it is usually narrower than the brief.
What would make you act differently? If there is no threshold that changes behaviour, the metric is decoration. A number nobody would act on either way does not belong on a dashboard.
How often does this come up? Something decided weekly deserves real-time infrastructure. Something decided once a quarter does not, and pretending otherwise is how projects get four times the budget they needed.
What this changes about the build
You end up with far fewer metrics, which is uncomfortable at first because the deliverable looks less impressive. In practice it produces the opposite effect on usage.
Fewer tiles means each one can carry context — the target, the trend, the comparison, and what "good" looks like. A single well-designed tile that answers one question beats a wall of charts that invites interpretation.
It also changes the data work. When you know the decision, you know exactly how accurate the number needs to be and how fresh it needs to be. A collection decision made daily needs yesterdayu2019s data and no tolerance for double-counting. A capacity decision made quarterly can survive on month-old figures with known gaps.
That knowledge removes most of the arguments about data quality, because you are no longer trying to build a perfect model of the business. You are building something specific.
Where it goes wrong
The exercise fails when it is run with the procurement contact rather than the decision-maker. A brief assembled from a list of desired metrics is a shopping list, and it will be delivered exactly as written — which is to say, unused.
It also fails when the organisation wants a dashboard because a peer has one. That is a reasonable thing to want, but it is a different project, and it should be scoped as what it is: an exploratory tool for a team that already knows what questions matter.
If you cannot get thirty minutes with someone who will genuinely use the thing, that is the most useful finding available. It usually means the decision itself is unclear, and no amount of visualisation will resolve that.