A dashboard gets built. It is well designed, it loads quickly, the numbers are correct. It launches to a genuinely enthusiastic reception. Usage peaks in week two and then declines steadily until, by month four, it is opened by the person who built it and nobody else.
This pattern is so consistent that we now treat it as the default outcome rather than a failure case. The interesting question is not why adoption declines. It is why anyone expected it to persist.
Dashboards answer questions nobody asks twice
Most dashboards are commissioned after a specific question is asked, often by someone senior, often urgently. The analyst answers it. Then, sensibly, they build a dashboard so the question can be answered without them next time.
The flaw is in the assumption. Many business questions are genuinely one-off. Somebody wanted to know whether a promotion cannibalised full-price sales. They found out. They acted. They will not need that view weekly for the rest of the year, and the dashboard built to serve it becomes a permanent artefact answering a question that expired.
Recurring questions do exist and they are worth serving well. They are considerably rarer than the dashboard count in most BI estates suggests.
Nobody monitors a dashboard
The second flawed assumption is behavioural. Dashboards for ongoing monitoring assume someone will open them regularly, look at the numbers, and notice when something is off.
People do not do this. Not because they are careless, but because opening a dashboard to check whether anything has changed is an unrewarding activity. Nine times out of ten nothing has, and the visit is wasted. Humans stop doing things that are usually pointless, and they are right to.
Monitoring is a push problem. The system should know what normal looks like and interrupt someone when it does not. Asking a person to poll for anomalies is asking them to do a job that computers are better at and that humans reliably abandon.
Sort by what happens next
The framing we find most useful is to ask what a viewer is meant to do differently as a result of looking. Three answers, three different products.
Nothing, usually
This is monitoring. Most of the time the answer is fine and no action follows. Build an alert, not a dashboard. Define the threshold, route it to a person or a channel, and include enough context in the alert that the recipient can triage without opening anything.
Then build a small diagnostic view for after the alert fires, and expect it to be opened rarely, which is correct rather than a problem.
Make a specific recurring decision
Stock reorders. Weekly staffing. Budget reallocation. These are real recurring decisions and they justify a real interface.
The mistake is building an exploration tool for a decision task. If the user’s job is to decide, the interface should present the decision, the relevant evidence and ideally a recommendation. Twelve filters and a date picker are a hindrance, not flexibility. Design it as a workflow tool that happens to contain data, not as an analytics surface.
Understand something new
This is genuine exploration, and it is the one case where a flexible tool is the right answer. It is also, in our experience, a much smaller share of demand than the tooling investment implies, and it is served by giving competent analysts good data and good access rather than by building views for them.
What we build instead
On a recent engagement a client had over four hundred dashboards. Around thirty had more than five viewers in a month. The rest were either abandoned or personal.
We did not rationalise them, because rationalisation projects are unpopular and rarely finish. We asked a different question of the top thirty: what does the person do after they look?
Roughly half turned out to be monitoring in disguise. Those became alerts, and usage of the corresponding dashboards fell further, which was the intended outcome rather than a regression. A handful were decision tools wearing exploration clothing, and were rebuilt as focused interfaces with far fewer controls. A small number were genuine exploration and were left alone.
Total dashboard views went down. Time from a condition occurring to somebody acting on it went down considerably more, and that was the metric that mattered.
Measure the decision, not the view
Analytics functions are commonly measured on outputs: dashboards delivered, requests closed, users active. These are activity metrics, and they reward building more things regardless of whether the things change anything.
Better questions, harder to answer: how long between a condition arising and someone knowing about it. How long between knowing and acting. What proportion of recurring decisions have a defined evidence source at all.
Those numbers are awkward to instrument and they point at the actual job. A function optimising for them builds fewer dashboards, and the ones it does build tend to survive past month four.
Retiring things is a feature
One structural change makes more difference than any design improvement: give dashboards an expiry date at the point of creation.
Not deletion, archival. Six months after creation, a dashboard with fewer than a defined number of viewers gets archived automatically, with a notification and a one-click restore. The restore matters, because it removes the argument. Nobody is losing anything, and the objection that someone might need it in future is answered.
The effect is not primarily the cleanup, although the cleanup is welcome. It is that the surviving set becomes meaningful. When everything in the BI tool is there because someone actively used it, browsing becomes useful again and new users can be pointed at the collection with confidence. In an estate of four hundred dashboards of unknown quality, a new joiner cannot tell the load-bearing views from the abandoned experiments, and neither can anyone else.
Personal is fine
A caveat on the above. A large share of dashboards in most estates are personal working artefacts: an analyst built a view to help with a specific piece of work and kept it. These have one viewer, look like failures by every adoption metric, and are entirely legitimate.
The mistake is treating them as an estate problem and trying to govern them out of existence. Give people a personal space, exclude it from the metrics, and concentrate governance on the shared collection where the trust problem actually lives.
