And how to build one people actually use
By Steele Consulting
Every business has them. A dashboard somebody spent six weeks building, presented in a leadership meeting with real enthusiasm, and now sits in a browser tab nobody opens. Two months in, the screens still load but nobody is making decisions from them. Six months in, the data has gone stale and nobody noticed because nobody was looking. A year in, somebody asks if the tool should be sunset and nobody objects.
This is the dashboard graveyard, and it’s bigger than most leadership teams realize.
In our 24 years building custom software and data systems at Steele Consulting, we’ve watched the same pattern play out dozens of times. A business pays for a dashboard project, gets a dashboard, and finds that nothing about how the business operates actually changes. The data was right. The visualizations were good. The technology worked. And still nobody used it.
The problem almost never lives in the data layer. It lives in four questions the dashboard was never built to answer.
Why this happens
Most dashboards get built backwards. The conversation starts with “what data do we have” and ends with “what charts can we put on a screen.” The middle — what decision is this actually supporting, who’s making it, and what changes after they look — gets skipped because it feels obvious, or because the people in the room are different from the people who will eventually be using the thing.
The result is dashboards that look impressive to a stakeholder in a sign-off meeting and provide no daily value to the actual users. The team that built it was incentivized to make it look comprehensive. The team that has to use it was incentivized to keep doing what they were already doing. Six weeks later, the tool exists. Nothing has changed.
We use a simple test with clients before any data project starts — and after any data project that’s been ignored for more than a few months. We call it the 4 Questions Test. If a dashboard can’t answer all four, it will not be used.
Question 1: Who is this for, exactly?
Not “the leadership team.” Not “operations.” A specific person, or a specific role, in their actual job. The COO looking at the dashboard between meetings on a Tuesday. The warehouse supervisor checking it at 6 a.m. before the shift starts. The CFO scanning it Monday morning before the all-hands.
The audience shapes everything else. The COO needs aggregated trends. The warehouse supervisor needs three numbers and an alert. The CFO needs the same numbers every Monday so they can spot week-over-week change without having to interpret a new view.
A dashboard built for “everyone” is built for nobody. The most-used dashboards in any company are usually the simplest, because they were designed for one person doing one job at one time of day.
If you can’t name the user — first name, role, when they look at it — start there.
Question 2: What decision does it help them make?
Every useful dashboard answers a question that ends in a verb. “Should we hire?” “Do we have enough inventory for next week?” “Is this customer about to churn?” “Are we on track for the quarter?”
The decision is the entire point. The metrics, the visualizations, the time ranges, the alerts — every choice about what to show should fall out of the decision the dashboard exists to support. This is a smaller version of the broader problem we wrote about in How to Make Decisions Faster Without Making Worse Ones: most leadership teams don’t lack data, they lack data shaped around the decision.
When we audit dashboards nobody uses, the most common failure pattern is that the dashboard shows status without supporting any decision. “Here are 15 KPIs” is a status report, not a decision tool. A status report can be useful in a meeting. It is rarely useful Monday morning.
If you can’t finish the sentence, “After looking at this, the user will decide whether to ___,” you don’t have a dashboard yet. You have a chart collection.
Question 3: What’s the one number that matters most?
Every dashboard should have a primary metric — the number the user is actually trying to manage. Everything else on the screen exists to explain or qualify that number.
This is the part that gets the most pushback, usually from stakeholders who want their own metric on the screen too. But a dashboard with twelve equally-weighted metrics asks the user to do the prioritization work every time they open it. They will do that work twice and then stop opening the dashboard.
The right number is usually obvious once you know the user and the decision. The COO managing operations probably cares most about throughput. The CFO checking the quarter probably cares most about revenue against plan. The warehouse supervisor probably cares most about open orders behind SLA. Everything else on the screen exists to help the user understand why that number is what it is.
If the user can glance at the dashboard and immediately know whether things are good or bad, the dashboard is working. If they have to read it, it’s already losing them.
Question 4: What should change because of it?
This is the question that most fundamentally separates dashboards that get used from dashboards that don’t. A dashboard that informs but doesn’t trigger action is a dashboard that ends up ignored, no matter how good the data is.
What does the user do differently when the number turns red? When trends move? When a threshold breaks? If the answer is “nothing specific” or “we’d talk about it in our next meeting,” the dashboard isn’t part of how the business runs — it’s just a status board. Status boards are easy to skip.
The most-used dashboards we’ve ever built had a behavior wired in. The supervisor looks at it at the start of the shift and re-prioritizes the day based on the open-order count. The COO looks at it weekly and the number drives a specific staffing decision. The CFO looks at it Monday and the variance triggers a specific conversation with department heads. The dashboard isn’t a passive view. It’s part of a routine that already exists, supporting a decision that already had to be made.
A note on building it twice
The first version of any dashboard is almost always wrong. That’s not a failure of the team building it — it’s the nature of the problem. You don’t know exactly what the user will need until they’ve used a version that isn’t quite right.
The teams that build dashboards people actually use plan for this from the start. They build a rough version in two or three weeks. They get it in front of the user. They watch what they actually do with it (often: nothing). And they iterate based on what got skipped, ignored, or worked around — not on what the stakeholder said in the kickoff meeting.
A dashboard project that ships a “final version” and walks away is almost certainly going to end up in the graveyard. A dashboard project that ships a v1 and stays close to the user for the next two months is the one that gets used a year later. This is also where most dashboards belong inside the broader DRIFT picture: an unused dashboard isn’t a sunk cost, it’s a Friction Cost — the team works around it instead of with it, every day.
Red flags worth naming directly
A handful of patterns are worth flagging on their own:
- The dashboard is built for a meeting, not a daily user. It will be used once.
- Nobody has named the user by role and time-of-day. It will be used by nobody.
- The dashboard has more than seven or eight elements on the screen. The user will not absorb it.
- The data is more than 24 hours stale relative to the decision being made. The user will stop trusting it.
- The dashboard doesn’t show what changed since last look. The user will have to remember, and they won’t.
- The dashboard has no alert mechanism for the one number that matters. The user has to remember to look. Eventually, they won’t.
How we approach this at Steele Consulting
Our Big Data and Data Analytics practice has been doing this for 24 years, and the pattern of what gets used and what doesn’t is remarkably consistent. We start every analytics project with the 4 Questions answered in writing — by the user, not by the stakeholder — before anyone touches a dataset. The technology, the design, and the integration choices all fall out of those answers.
If you have a dashboard nobody is opening, or a dashboard project you’re about to start and want to make sure it lands, that’s the conversation we’re built for. Reach out and we’ll walk through what your first 4 Questions look like.