Why Dashboards Go Unused, and What to Check Before Rebuilding
Low usage is a symptom, and poor design is the last of its causes to look for. The causes depend on one another, so a fault in an earlier one cannot be repaired by work on a later one. This is an argument for diagnosis before redesign.
The usual response to a dashboard that few people open is to redesign it: a new layout, better charts, a cleaner colour scheme. The response assumes the cause, and DII’s view is that it assumes the least likely one.
A dashboard goes unused for reasons that sit in a rough order of dependency. Nobody uses a well-designed display of numbers they do not believe, and nobody needs to believe numbers that inform no decision. This article takes the causes in the order DII would look for them and says what each finding implies: fix, replace or retire. It is about one dashboard that has already been delivered. Specifying a new one, and reducing a whole estate of unused reports, are different problems.
Read the usage figure with care first
Before diagnosing, be sure what the number means. Usage telemetry counts events. Microsoft’s documentation for its usage metrics, for example, defines a report view precisely: “A Report View is recorded each time someone opens a report and represents unique landings on the report”1. It also states the window, noting that the standard report “contains usage metrics for that content for the last 30 days”1. A quarterly board pack will look unused in a thirty-day view for two months in every three.
Low use is also not automatically failure, and high use is not success. The research literature on information systems has been cautious on the point for a long time. DeLone and McLean, reviewing a decade of studies, observed that “System use was typically voluntary and was measured as frequency of use, time of use, number of accesses, usage pattern, and dependency”2, and argued that counting is not enough: “Researchers must also consider the nature, extent, quality, and appropriateness of the system use”2. A dashboard that one person consults before a weekly decision may be doing exactly its job.
So the first step is to compare usage with intent. Who was meant to use it, how often, and for what? If nobody can say, that is the first finding.
Is there a decision behind it?
Ask what someone does differently because of this dashboard. If the honest answer is nothing, no further diagnosis is needed.
Stephen Few’s description of what a dashboard is for supplies the test: “The means is a single-screen display; the purpose is to efficiently keep in touch with the information needed to do something”3. The last three words carry it. A dashboard built to provide visibility, or because a team felt it ought to have one, has no decision behind it and no reason to be opened.
If this is the finding: retire. A redesign cannot supply a purpose. If the people it was built for can now name a decision, that is a new requirement, and it should be specified from the start as described in dashboard requirements: what to settle before anyone builds.
Do the intended users believe the numbers?
If there is a decision, ask whether the intended users believe the numbers. Listen for the tell-tale behaviours: checking the dashboard against a spreadsheet, asking an analyst to confirm a figure before using it, quoting a different number in meetings.
Distrust has specific sources, and they are worth separating. The figure may be wrong. It may be right and defined differently from the number the user already knows. Or it may have been wrong once, visibly, and never recovered its standing. The UK Government Data Quality Framework sets a realistic standard for the first: “Perfect data quality may not always be achievable and therefore focus should be given to ensuring the data is as fit for purpose as it can be”4. For the second and third, the remedy is explanation: a stated definition, a visible refresh time, and a note when something is known to be incomplete.
If this is the finding: fix the data or the definition, not the dashboard. The work is upstream. Which data deserves a stated quality standard is discussed in critical data elements: how to choose what to govern first, and the wider conditions for trusted reporting in what makes business intelligence trustworthy.
Does the data arrive in time for the decision?
A trusted figure that arrives after the decision is not used for the decision. Compare when the data is ready with when the user needs it. A dashboard refreshed at nine is no use to a team that plans its day at eight. One that is final on the fifth working day does not serve a review on the third.
Timeliness also fails by unreliability. A dashboard that is on time on most days and stale without warning on the others teaches its users to check elsewhere every day.
If this is the finding: fix the pipeline or the schedule. Catching a late or failed load before the user does is a monitoring problem, covered in data observability: what to monitor and where to start.
Is it where the work happens?
The dashboard may be sound and simply not where the work happens. A manager who runs the weekly meeting from a slide deck will not open a separate tool in the middle of it. A field team on phones will not use something built for a desktop monitor. A clerk who needs to act on individual cases needs the list of cases, and a summary chart sends them to another system to find it.
This check needs observation. Watch the decision being made, or ask to be walked through it, and note what is on the screen at the time.
If this is the finding: replace with a different form. The information is wanted, in another place or shape: an emailed summary, a figure embedded in the system people already use, an alert, a list. Rebuilding the same dashboard more attractively will not move it into the workflow.
Can the people it was built for find it?
Ask a member of the intended audience to open the dashboard without help. In a large estate of reports with similar names, some may not manage it. Others may hold a bookmark to an older version and have never seen the current one.
Findability includes knowing that the thing exists and that it is the official one. A dashboard launched with a single email, to people who have since changed roles, may be unknown to much of its present audience.
If this is the finding: fix the access, not the content. Give it one obvious location, a name that says what it is, a mark showing it is the current official version, and a place in the induction of anyone joining the team. If the estate is so crowded that nothing can be found, the problem is the estate, and rationalising a sprawling BI estate applies.
Only then: does it communicate?
Only now is design the question. If there is a decision, the data is trusted and timely, the dashboard is in the workflow and people can find it, and it is still not used, look at whether it communicates.
The faults here are well understood: too much on the screen, the important figure not prominent, no comparison to show whether a number is good or bad, charts chosen for appearance. Few’s definition gives the standard to design against: the most important information, on a single screen, readable at a glance3.
One cause at this stage is easy to mistake for bad design and is really a mismatch with the reader. A 2018 survey of dashboards in practice, by researchers at Microsoft, Tableau Research and Simon Fraser University, reports that “A consistent theme in the literature was the challenge of supporting users with weak visual, analytic, or data literacy”5. A dashboard can be well made for an analyst and unreadable to the manager it was meant for. The remedy may be a simpler display, and it may be help for the reader. A redesign that adds sophistication makes this fault worse.
If this is the finding: redesign. This is the one case where the original instinct was right, and it is right only after five others have been excluded.
What each finding implies
What to look for, in order, and what each finding implies
| Question | What to look for | Response |
|---|---|---|
| Decision | Nobody can say what they do differently because of it | Retire |
| Trust | Users confirm figures elsewhere before using them | Fix the data or definition upstream |
| Timeliness | Data is ready after the decision, or unreliably | Fix the pipeline or schedule |
| Workflow | The decision is made somewhere the dashboard is not | Replace with a different form |
| Findability | Intended users cannot locate the current version | Fix location, naming and the official mark |
| Design | All of the above hold and it still does not communicate | Redesign |
The order is DII’s judgement about dependency, not a finding from research. It reflects a simple rule: check first the faults that make later work pointless.
Two cautions go with it. More than one fault can be present, and fixing the first may reveal the second, so the checks are worth repeating after a repair. And the retire response at the first check deserves less reluctance than it gets. A dashboard nobody needs costs something to refresh, to secure and to keep in the catalogue, and it makes the useful ones harder to find.
Doing the checks
The diagnosis takes a few conversations and one observation of the decision being made. They do not need a project. Write down what each check found, including the checks that passed. A short record of the findings shows the next person why the dashboard was fixed, replaced or retired, and saves the diagnosis being repeated the next time its usage is questioned. The Dashboard Review Checklist sets them out as questions with space for what was found. Where the first check produces a real, newly stated need, the Dashboard Requirements Template is the place to record it before anything is rebuilt.
Sources
- Microsoft. Monitor usage metrics in Power BI workspaces (preview) (Microsoft Learn). Updated 1 January 2026.
- DeLone, W. H. and McLean, E. R. The DeLone and McLean Model of Information Systems Success: A Ten-Year Update. Journal of Management Information Systems, 19(4), 9-30. 2003.
- Few, S. Dashboard Confusion. Intelligent Enterprise, 20 March 2004 (Perceptual Edge). 20 March 2004.
- Government Data Quality Hub (UK Government). The Government Data Quality Framework. 3 December 2020.
- Sarikaya, A., Correll, M., Bartram, L., Tory, M. and Fisher, D. What Do We Talk About When We Talk About Dashboards? (author manuscript for IEEE Transactions on Visualization and Computer Graphics; presented at IEEE InfoVis 2018). 2018.
This article is general professional information. It is not legal or regulatory advice.