From dashboard to decision: why nobody uses the one they asked for

A dashboard is worth only what it changes. If nobody acts differently after looking at it, it is an expensive report with charts — and the problem is almost never the visual design. It is that the dashboard was built from the data that happened to be available rather than from the decision somebody has to make.

Below: why they get abandoned, what distinguishes one that gets used, how to design from the decision, the questions worth asking first, and how usage is measured.

The sequence is recognisable. A team asks for a dashboard, it is built over several weeks, presented with enthusiasm, used for a fortnight, and then it sits there. Nobody switches it off, nobody looks at it, and a year later somebody requests a new one for the same subject.

The usual explanation points at data culture, which is a comfortable way of not reviewing the build process. The more useful explanation is concrete: the dashboard answers questions nobody had.

Why they get abandoned

It was built from the available data. The conversation started with what information exists in the system rather than what decision has to be made. The result is correct, complete and unrelated to any real problem.

It shows state, not change. A large number with the month total informs very little: the question is always whether it is better or worse than expected, and against what. Without a comparison there is no decision available, only an observation.

It does not say what to do with what it shows. An indicator in red with no associated action generates a meeting, not a correction. If nobody defined what happens when that number leaves its range, the dashboard is a thermometer with no treatment.

It arrives late. Monthly data about something decided weekly cannot be used however perfect it is. The frequency of the data has to follow the decision cycle, not the convenience of the extraction.

What distinguishes one that gets used

Dashboards that survive share four traits, and none of them is aesthetic.

First: somebody has to make a recurring decision and the dashboard is the fastest way to make it. If the decision is not recurring, a one-off analysis serves better and costs far less.

Second: every figure has a reference — a target, the previous period, the average of a comparable group. What informs is not the value but the deviation.

Third: you can get to the detail. Seeing that a region fell is useless if you cannot find out in what. The next question is always "why", and a dashboard that does not anticipate it forces a report request, which is where the momentum dies.

Fourth: it has an owner. Somebody answers for its figures being right and for retiring it when it stops being useful.

How to design from the decision

The method that works inverts the usual order and starts with a twenty-minute conversation rather than an extraction.

You ask what decision is made, how often, who makes it and what information would make it better. With those four answers the dashboard practically draws itself, and it frequently turns out smaller than what was asked for.

That discovery is common and worth anticipating: most dashboard requests ask for thirty indicators and the real decision depends on three. The other twenty-seven are context consulted once a quarter and do not deserve permanent space.

The practical consequence is a shorter project. A dashboard of three well-chosen indicators is built in days and gets used; one of thirty takes weeks and gets abandoned.

The questions worth asking before building

Besides the four above, three save rework. What would you do differently if this number doubled? If the answer is "nothing", the indicator does not deserve to be there. What do you compare it against today? Reveals whether an agreed reference exists or everyone uses their own.

And the most uncomfortable: what do you do today without this dashboard? There is almost always an existing process — a spreadsheet, a phone call, a weekly email — and understanding it prevents building something worse than what already works informally.

That spreadsheet somebody maintains by hand is usually the best requirements document available, because it contains exactly what that person needs and nothing else.

The underlying problem is the definition

A dashboard showing a figure that accounting calculates differently does not get used, it gets argued about. And the dashboard does not settle the argument.

So the definition is agreed before the visualisation is built: what counts as a sale, from when a customer is active, what is excluded. Writing it down and having somebody with authority close it is half the work, and it is the part usually skipped for looking bureaucratic.

Once those definitions live in one place that every dashboard draws from, the problem stops reappearing with each new report. That is the purpose of a semantic layer and the reason it is worth having sooner rather than later.

The dashboard that does get used and nobody requested

One category outperforms any executive dashboard and almost never appears on the request list: the operational one. Not the view that summarises the month for a committee, but the one telling whoever does the work which cases are outstanding today and which have been waiting too long.

The difference is that the second is consulted several times a day out of self-interest rather than discipline. And it produces a valuable side effect: because people use it constantly, data errors surface in hours instead of at close. Intensive use is the best quality control available, and it is free.

Which is why it is worth starting there when confidence in the data is low. An executive dashboard on doubtful data generates arguments; an operational one on the same data generates corrections.

How usage is measured

Three figures say whether the dashboard delivered. Recurring active users, not unique visits: somebody who opens it once out of curiosity does not count. Frequency against the decision cycle: if the decision is weekly and the dashboard is consulted monthly, it is not in the flow. And time to first derived action, the hardest to measure and the only one that speaks to value.

It is also worth reviewing which dashboards nobody opens and retiring them. A catalogue full of dead dashboards makes the live ones harder to find and signals that none of them matter much.

Where the weakness actually sits can be measured. A data and analytics maturity assessment scores source, quality, governance, model and consumption separately, and usually points at a layer other than the one about to be rebuilt. From there comes an analytics plan that orders the investment, with consultants in Bogotá and Mexico City working in the time zone of whoever makes the decision.

Frequently asked questions

Why does nobody use the dashboard the team asked for?

Usually because it was built from the available data rather than the decision to be made, because it shows state without comparison, because it does not say what to do when something leaves its range, or because it arrives less often than the decision.

How many indicators should a dashboard have?

As many as the decision requires, which is usually three or four. Most requests ask for thirty and the real decision depends on few; the rest is quarterly context that does not deserve permanent space.

What should be asked before building one?

What decision is made, how often, who makes it, and what information would improve it. Plus three more: what would change if the number doubled, what it is compared against today, and what is done today without the dashboard.

Why does the metric definition matter so much?

Because a dashboard showing a figure another team calculates differently does not get used, it gets argued about — and the visualisation does not settle the argument. Agreeing and writing the definition is half the work.

How do you know a dashboard is working?

Recurring active users rather than unique visits, consultation frequency compared with the decision cycle, and time to first derived action. The last is the difficult one and the only one that speaks to value.

What should be done with dashboards nobody opens?

Retire them. A catalogue full of dead dashboards makes the live ones harder to find and signals that none of them matter much.