Why I Hate Dashboards
I was talking to an analyst last week about a problem we wanted to solve. We walked through the question together, talked about the data, and landed on a pretty clean answer. Straightforward and easily the kind of thing you could explain in two paragraphs.
Their immediate response at the end of the conversation was “Okay, I’ll get started on the dashboard.”
Wait what?
We didn’t need a dashboard. We needed an email. Maybe a few slides if we wanted to be fancy. The answer was clear, it wasn’t going to change, and the audience was a handful of people who needed to make one decision. A dashboard would have taken a week to build, required ongoing maintenance, and buried a simple answer inside filters and tabs that nobody asked for.
I hate dashboards. Not in the way someone who has never built one hates them. I like to think I hate them in a much more sophisticated way. The way you hate something that keeps getting requested even after it has clearly failed to solve the problem it was supposed to solve.
Analysts default to dashboards the same way my dog defaults to stealing socks. No matter how many times I tell her not to go digging in the laundry basket, and there’s a better toy in her bed, she sneaks at least one sock per load.
And yes, I track socks stolen per laundry load as ax mischief KPI.
Dashboards have become the default deliverable for analytics teams. They feel tangible, they look like a product, and they let everyone say something got “delivered” and “automated.” When the default answer to every question is “build a dashboard,” you stop asking whether it’s the right format.
What we think we’re doing
When someone asks for a dashboard, they usually think they want clarity. What they actually want is confidence. They want to know whether something changed, whether it matters, and what they should do next. They do not want to spend twenty minutes clicking filters, comparing tabs, and trying to reverse-engineer the analyst’s mental model. They definitely do not want to feel like they need a second dashboard just to understand the first one, but eventually they’ll ask for one.
In fact, that’s why most dashboards are awful. They get built the way the analyst thinks, not the way the user thinks. Analysts like structure, logic, completeness and flexibility. Users like speed, relevance, and a path to action. So we hand over a beautiful tool that makes perfect sense to us and then act surprised when the business starts exporting everything into Excel so they can “analyze it their way.”
We joke about the export behavior, but it should be a clue. It says the dashboard doesn’t match the user’s workflow. If the user has to leave your dashboard to think clearly, the dashboard is just Excel with a nicer interface.
The dashboard fantasy
The fantasy goes like this: build one dashboard, and everyone will see the same truth, make better decisions, and stop bothering you.
That fantasy is adorable.
In practice, dashboards create new work. Someone has to maintain them, explain them, defend them, update the definitions, handle the edge cases, and answer the inevitable “can you add one more filter?” request that is allegedly simple and is never simple. Updating filters, tweaking definitions and adjusting views feels productive, but it’s busywork and it’s rarely moving the organization forward.
Where dashboards are useful
I should be fair. Dashboards do have a job, and I’ve built plenty of good ones over the years (probably fewer than I think, but still).
They’re good when the question is broad, the audience is mixed, and the goal is shared visibility. They work for stable monitoring, common language, or spotting exceptions. “Useful” is not the same as “best,” though. Too many analytics teams treat dashboards as the universal container for value. They’re one format among many, and often not the format that gets a person from problem to decision fastest.
When you have users that genuinely need to explore data, or have recurring questions they need to answer each month, a dashboard can be a great help. Regular usage helps reinforce understanding, and it does actually streamline their workflow.
We just assume that usage pattern exists a lot more frequently than it does.
The part people skip
Dashboards are often built for the convenience of the analyst or the organization, not the cognitive habits of the person using them. We build them because they’re scalable, because they’re countable, because they feel like a product, and because they let us say we “delivered” something. A dashboard can contain every metric you asked for and still force the user to do the part of the job that analytics was supposed to do. It can say “here’s the data” while avoiding the harder and more important sentence: “here’s what it means and what to do about it.”
That avoidance is a real issue. Dashboards often become a polite way to stay in observation mode when the business actually needs judgment. They create the feeling of progress without the social risk of a recommendation someone doesn’t like. Everyone feels informed and the analytics team doesn’t have to be “responsible.”
How to move beyond dashboards
A better question than “can we build a dashboard?” is “what decision is this for?”
That question forces the request into a shape where you can ask about timing, owner, action, and consequence. It also makes it obvious when a dashboard is overkill, underpowered, or simply the wrong format.
If the answer is a recurring check-in, maybe you DO need a dashboard. If the answer is a decision with a deadline, you probably need something tighter. You could provide:
An email with a recommendation.
A one-page readout before tomorrow’s meeting.
A chat message with two numbers and a suggestion.
A weekly memo that tells people what changed, what it means, and whether they need to do anything.
A five-minute standing agenda item with two slides.
A triggered alert that fires when something crosses a threshold.
A pre-read doc that frames the tradeoffs so the meeting can skip straight to the decision.
The options are endless once you stop treating the dashboard as the only container for value.
A little assignment
Next time someone on your team (or you) starts a project and the first instinct is “I’ll build a dashboard,” pause and ask three questions. What decision does this support? Who needs to act on it, and how quickly? What’s the simplest format that gets them from data to action?
If the answers point to a dashboard, build the dashboard. If they point to an email, a weekly readout, or a five-minute conversation with two slides, do that instead.
The goal of analytics work is not to build things. It’s to change decisions on time. Dashboards are fine when they support that. They’re a problem when they become the goal.
Familiarity is how a lot of mediocre analytics gets dressed up as progress.
Some of what I write about here I’ve turned into more robust guides and playbooks. They’re more in-depth, more structured, and more actionable. You can find them at the Penguin Analytics store.