TheDashboardNobodyOpens
Analytics · adoption
The scenario
A team asks for a dashboard. Someone builds it, carefully, with clean charts and the right filters. It gets demoed, people nod, it gets praised in the review. Three weeks later, the actual usage numbers come back: two people have opened it. One of them is the person who built it, checking if it still works.
This is one of the most common, least discussed failures in analytics work, not a technical failure, an adoption failure.
Why it happens
A dashboard built to answer the specific question someone asked in a meeting is not the same thing as a dashboard built to support a decision a team makes repeatedly. Most requested dashboards are built backwards from a one-time question, "can you show me X," rather than forwards from an ongoing ritual, "we need to check this every Monday before we decide Y." Without being wired into something that already happens on a recurring basis, a dashboard has no natural reason to be opened again after the initial question is answered. It sits there, technically correct, functionally invisible.
What I would build instead
- Design backwards from a specific recurring decision, not a one-time question. Before building anything, identify the exact meeting, ritual, or moment where this data would actually change what someone does next. If that moment does not exist yet, the dashboard is solving the wrong problem.
- Attach the dashboard to that ritual directly. Give it a default view tuned to exactly what that recurring meeting needs to see first, not a general-purpose exploration tool that requires configuration every time.
- Push the data to people instead of waiting for them to pull it. A subscription digest, an automated summary sent right before the recurring meeting happens, does more for adoption than a dashboard sitting in a tool people have to remember to open.
- Treat low usage as a design signal, not a communication problem. The instinct when a dashboard goes unused is often to send a reminder email. The better response is to ask whether it was ever actually wired into a real decision in the first place.
Why this matters, and how I would measure it
The cost of an unused dashboard is not just wasted build time. It is a quiet signal that the team is measuring things without those measurements actually shaping decisions, which is a worse problem than not measuring at all, because it creates the appearance of data-driven work without the substance.
I would track weekly active viewers relative to the actual size of the decision-making group it was meant to serve, a dashboard used by 2 out of 20 relevant people is failing even if those 2 people love it. I would also track how often the dashboard gets directly referenced in the meetings it was meant to support, since that is the real test of whether it changed a decision or just existed alongside one.