Built, launched, ignored
Most dashboards end up ignored. Treating that as the default outcome rather than a failure case changes what you build, what you decide not to, and what you are willing to retire.
Rewritten from a post on my previous blog, first published in April 2025.
It happens to most dashboards, and often enough that it is worth treating as the default outcome rather than a failure case.
The clearest version of this I have watched: a set of account managers went three weeks without noticing their dashboard had stopped refreshing. Three weeks. The data was stale, the charts still rendered, and nobody said anything.
That is not really a data quality incident. It is a usage report. If nobody notices the numbers stopped moving for three weeks, nobody was relying on them to move. The question it raises is harder than why the refresh broke: which decision was this dashboard supposed to change, and when was the last time it did?
So I went back to everyone who had used the dashboard or asked for it, did the same for the other dashboards nobody seemed to open, and asked why they did or did not use them. The team then rebuilt or archived based on what they said. The tempting reaction to an unused dashboard is relief: nobody needs it, delete it. But a gap between something built and nobody using it means something was lost along the way. Either their requests for changes were never prioritized, or they had found another way to solve the problem. Those conversations taught me a lot about why the dashboards went unused, and they turned into a better working relationship, a partnership where each side helps solve the other’s problems.
A dashboard is a claim about a decision
Every dashboard is an implicit claim: someone, at some point, will look at this and do something differently. Most of them never had that claim written down, and that is the usual cause of the outcome above. The request arrived as a subject, visibility into marketing performance, say. The team built a faithful picture of the subject, and the picture had no reader because no decision was waiting for it.
Not every dashboard needs a decision. Monitoring, compliance, a shared reference everyone can point at: those are legitimate purposes, and a dashboard built for one of them should be judged against it. The failure is building a monitoring screen and calling it decision support, or building for a decision nobody could name.
A survey of dashboards in practice by Sarikaya, Correll, Bartram, Tory and Fisher, in IEEE Transactions on Visualization and Computer Graphics in 2019, found one word covering artifacts with different design goals, levels of interaction and practices around them, from decision support to summarization and communication. That is why the purpose has to be chosen before the layout: each purpose has its own definition of success, and a dashboard judged against the wrong one looks like a failure of design when it is a failure of intent.
So the first move is to turn the request into a sentence with a decision in it, before anything is drawn.
“We need a dashboard for marketing performance.”
A subject. Anything can go on it, so everything does.“Every Monday the channel lead moves this week’s budget between channels. She needs last week’s spend and cost per order by channel, against the cutoff she uses, as of Sunday night.”
A reader, a day, a comparison and a cutoff. The layout follows.Three questions get you from the first sentence to the second. Who makes the decision? When do they make it? What would they do differently depending on what they see? If nobody can answer the first, the right build is a report subscription or nothing.
Why they fail
Too many KPIs. When everything is on the dashboard, nothing on it is important. The urge to add one more metric is nearly always the urge to avoid deciding what matters, and it is the symptom of a dashboard built for a subject rather than a decision.
No context. A metric without a comparison does not tell anyone whether to be pleased or worried, which means it does not tell them anything. The comparison is the decision’s raw material: against last week, against plan, against the cutoff.
A number people do not trust. Credibility is the whole asset. One visible error sends people back to asking an analyst, and they rarely tell you they have stopped trusting it. They stop coming.
No owner. Without someone responsible for it, a dashboard is accurate on launch day and decays from there. See the three weeks above.
It sits outside the moment. If reading the dashboard is a step beside the decision rather than part of it, people decide without it. Training does not fix that, and the training usually asked for is the wrong one anyway: the gap is rarely the tool and usually knowing which number answers which question.
What gets one used
Start from the decision, not the data. Write the sentence above, with the reader, the day and the comparison in it, and build only what the sentence needs. Then put the important thing in the top left and cut the views to two or three. People scan; they do not study.
Title sections as questions. “Daily order volume” is a label. “Are order spikes hurting delivery times?” is an invitation, and it tells the reader what the section is for.
Show the as-of time and the source. People forgive a number that says it is a day old. They stop trusting one that looked current and wasn’t. Source and definition, visible, is what makes a number checkable, and checkable is what makes it believed.
Demo it live, then stop talking. Present briefly, then ask the room what they want to know and try to answer it from the screen in front of them. You find out immediately whether you built the right thing, which is uncomfortable and extremely useful.
Push, don’t wait. Relying on people to log in is relying on people to remember. A scheduled summary that arrives before the decision, comparing this period with the last one, does more for use than any redesign. It also makes a promise about freshness and delivery that someone has to keep; a push that arrives late is worse than a page that was never opened.
Cut charts. Every extra visual competes for the same attention. Removing things is the highest-value edit available and the one nobody wants to make.
The Monday review, rebuilt
Take the marketing request through, as an example rather than a record.
Before: a dashboard of fourteen charts, built from the request. Spend by channel, impressions, clicks, conversion rate, cost per click, cost per order, each as a trend, each with a filter. Refreshed nightly. Opened on Monday mornings by the channel lead, who exported two of the charts into a spreadsheet where she kept the only number she actually used: cost per order against the cutoff above which a channel loses budget.
After: one screen. A table of channels with last week’s spend, cost per order, the cutoff, and the change against the week before. The as-of time at the top, Sunday 11 p.m. One chart, the four-week trend for the channels near the cutoff. A line at the bottom naming the owner and the definition of an order.
Nothing was added. Twelve charts were removed and one comparison moved from a private spreadsheet into the shared view. The dashboard now answers the sentence, and it can be checked against it: when the channel lead moves budget, the move shows in the numbers the following week.
What it costs
The requester loses something. Twelve charts were somebody’s idea of thoroughness, and removing them reads as taking the request less seriously than they did. The conversation that turns a subject into a decision is where that cost is paid, and it is paid before anything is built.
Fewer dashboards get built. A team that insists on the decision sentence declines requests that cannot produce one. Some of those requesters build their own, in a spreadsheet, and some of what they build is a second version of a number the team is supposed to keep single. The decline needs a route, usually a subscription or a saved query, so the need is met without a screen.
A push creates an operating promise. A summary that arrives before Monday’s review has a delivery time, a freshness requirement and a response when it fails. That is a service, not a page, and it costs what a service costs.
Retirement has an audience. The dashboard nobody opens may still feed an export, a subscription, or a quarterly obligation nobody remembered to mention. Low page views are a clue, not the decision; the decision is a conversation with the owner, a check of what else reads it, and a date.
Beyond launch
Plan for use from the start, not after the build. Adoption retrofitted onto a finished dashboard is a training request.
Measure whether it changed decisions, not whether it got views. View counts are easy to collect and say almost nothing. The question is whether the budget moved, the order was released, the plan was changed, and whether the dashboard was in the room when it happened. A dashboard that no longer changes a decision costs refresh time, attention and trust, and keeping it alive to avoid the retirement conversation is the most expensive option available. A dashboard nobody uses is not waiting for better adoption. Ask the people who stopped using it why.
A dashboard is a claim about a decision, and the Monday review is how the claim gets tested. When the channel lead moves budget, it worked. When she stops moving budget, it has stopped working, whatever its view count says.