Your Dashboard Problem Isn’t a Dashboard Problem
The tool isn’t the problem. The missing brief is.
A dashboard is a decision-support tool.
If you don’t know what decision it supports before you build it, you’re designing a report, not a dashboard.
Most dashboard failures aren’t technology problems, data problems, or budget problems. They’re process failures. Organizations often skip critical design work and jump straight into building.
This is the same pattern we see whenever organizations reach for a tool before they understand the need. We’ve written about this before with platforms, AI, and automation. Dashboards are no different.
Start with the decision
When you’re designing and building a dashboard, before you even think about metrics, visualization or software platform, ask:
What decision will this dashboard help someone make?
The decision comes first. Everything else is downstream of that.
Once you’re clear on the decision, other questions become much easier to answer:
What information is actually needed?
Who needs it?
How often do they need it?
What would cause them to act?
Reverse that sequence and you risk building a dashboard that looks impressive but doesn’t help anyone do their job.
Need to think about it another way? Try asking one of these questions instead.
Three ways to ask the same question
If “decision” feels too abstract, try asking one of these questions instead:
What problem am I trying to catch earlier, and what would earlier look like?
What behavior am I trying to change, and what would prove it’s working?
What threshold would tell me to change course, and what would I do next?
These questions force clarity about decisions, ownership, and action. They aren’t always easy to answer. But when they get skipped, the dashboard rarely solves the problem later.
Why dashboards get built backwards
Dashboards fail due to several common pitfalls.
Failure pattern #1: The Excel migration
The dashboard request arrives as an upgrade: “Can we get this out of spreadsheets and into a real tool?”
It sounds reasonable - central location, perhaps some automation and version control.
But often the spreadsheet is simply recreated in a browser without first asking what decisions it supports or whether it’s working at all.
Spreadsheets have a tendency to accumulate uses over time, accommodating as many people as possible. It might have a little performance reporting, a little forecasting, a little exception tracking, a little historical archive. The decisions it was meant to support get lost over time.
The dashboard faithfully recreates all of it. It’s more polished, but just as hard to act on
The tool changed. The confusion didn’t.
Failure pattern #2: Built for someone else’s questions
Dashboards can fail because the people designing them and the people using them aren’t solving the same problem.
Leadership dashboards often fall into this trap. They’re designed around assumptions about what leaders should want to see, rather than the questions leaders actually ask. Sometimes the dashboard is technically for the executive, but the real users are the people expected to interpret the numbers and turn them into action.
The same thing happens in reverse. A dashboard gets built by people who don’t understand the decisions the end users need to make. The result is threshold alerts nobody uses, complex visualizations that answer the wrong questions, and metrics that aren’t central to the team’s work.
What question is this audience trying to answer?
How often do they need those answers?
If the numbers change, what would they do differently?
Failure pattern #3: Built assuming data and processes can keep up
This may be the most optimistic failure mode. Someone knew exactly what good, bad, and concerning looked like. They had thresholds, a vision.
What they didn’t have was reliable access to the data needed to support it. A dashboard signals confidence in the underlying metrics. But if the data underneath can’t be sustainably supported over time, that dashboard won’t be credible, and therefore, won’t be used.
This tends to happen when manual work is needed to prepare and load data into a dashboard. Or, there is no clear accountability for maintaining the dashboard on an agreed-upon cadence.
The pattern behind the patterns
These aren’t the only ways dashboards fail. But they share a common thread: the work of defining the need either didn’t happen or didn’t happen thoroughly enough.
The tool drives the design. Available data replaces needed data. Someone copies a template from another business without asking whether the same questions need answering.
By now, this probably doesn’t sound like a dashboard article anymore. That’s because it isn’t really about dashboards. It’s about how organizations approach tools.
The dashboard brief
What most organizations lack is a clear blueprint for the dashboard they want to build.
Before any conversation with an analyst, consultant, or software vendor, there are a handful of questions that should already have answers.
What decision is this supporting?
What action should it trigger?
How will we know it worked?
Those questions sound simple, but they’re often surprisingly difficult. As a result, they’re also the work that gets skipped when teams are eager to start building.
We’ve turned those questions into a one-page Dashboard Decision Brief, which helps teams clarify the need before they rush into building.
The dashboard brief isn’t paperwork. It’s where you decide what the dashboard is supposed to do. It’s the thinking that determines whether a dashboard will ever become useful.
It won’t guarantee a perfect dashboard, but it will dramatically reduce the odds of building one that nobody uses, trusts, or acts on.
AI and automation: the same argument, higher stakes
Replace “dashboard” with “AI” or “automation” and the questions barely change.
What process is this improving? Who owns the outcome? How will we know it helped?
Organizations struggling to realize value from AI aren’t struggling simply because the technology is immature. They’re struggling because they reached for the tool before they understood the need.
While these investments are larger and the expectations are bigger, the fix is exactly the same. Understand the need first. Then choose the tool.
Before you build the next dashboard
The best dashboard you’ll ever build is the one designed around well-defined decisions. The second-best dashboard is the one you revisit after realizing the first one never had a clear brief.
Both are better than the dashboard sitting unused on someone’s bookmark bar.
Download the Dashboard Decision Brief and bring it into your next dashboard conversation. See what happens when the first question in the room isn’t “what data do you want to include?” but “What decision are we trying to make?”
Pre-generative AI, I found myself in environments where the stakeholders were increasingly averse to self-serving analytics (maybe correlated with my shifting geographies).
In my first job, I worked with people who were pretty fluent with getting what they wanted from interactive dashboards by clicking through the widgets, but not so much in my latter jobs and I felt like they in fact wanted... voice-controlled data table and graph views that lo and behold generative AI can do now. 🤣