Your Dashboards Are Bad and You Should Feel Bad
The name and inspiration for this post comes from an excellent resource I’ve had to the pleasure of knowing for several years. Nick, I’ve shamelessly stolen it.
I’ve been building dashboards for nearly twenty years. Some were good. Some were terrible. Most were somewhere in between. If you’ve built dashboards in an IT environment, you’ve probably had the same experience.
So, this isn’t a shame post. It’s a perspective post requesting you shift your perspective.
Dashboards are one of the most misunderstood tools in our industry. We treat them like decoration, or like a dumping ground for every metric we can collect. Hell, we even devote masses of real estate in glass-walled rooms to them (yes, I’m looking at you and your multiple 85″ NOC screens). But dashboards aren’t about data. They’re about understanding. And if your dashboard isn’t helping someone understand something, it’s not doing its job.
Let’s talk about why most dashboards fail and how to build one that actually works. First, we need to start with the unifying truth.
Dashboards Aren’t Displays. They’re Narratives.
A dashboard should tell a story. Not a novel. Not a mystery. A story.
It should answer three questions immediately:
- What’s happening?
- Is it normal?
- Do I need to do something?
Most dashboards don’t answer any of these. They’re a collage of charts, gauges, and colors that look impressive but communicate nothing. They are poster art for a nothing burger movie. Frequently, they’re built by technicians for technicians, and even then, only the person (not even the team) who created it truly understands what’s going on.
To illustrate the problem, let’s start with the dashboard everyone thinks they want.
The Executive Dashboard
Executives often say they want “a simple dashboard.” What they really want is reassurance. So, let’s give them the dashboard they deserve: a single giant green button that says, “Everything’s OK.”
It’s a joke, but it’s also not. Executives don’t need details, they need clarity. They need to know whether the system is healthy and whether they should be worried. That’s it.
This dashboard works because it tells a story instantly. It’s not useful for anyone else, but it’s perfect for its audience.
The Dashboard Technicians Build for Themselves
This is the opposite extreme: the dashboard built by the engineer who knows the system inside and out. It has every metric, every log stream, every trace, every panel, every color, and every visualization offered.
It’s chaos. But it’s familiar chaos—to the person who built it.
The problem is that this dashboard is only useful to one person. Most everyone else sees noise. And noise is dangerous. It hides problems, creates confusion, and makes people think they’re informed when they’re not. If there’s too many critical things, where does one even start?
A dashboard that only works for its creator isn’t a dashboard. It’s a personal notebook.
The Purpose-built Dashboard
This is what a good dashboard looks like.
It’s built for a single audience with a single purpose (in this case DNS resolution via Pi-hole). It doesn’t try to be everything for everyone. It doesn’t try to show every metric. It doesn’t try to impress anyone.
It answers one question clearly. In this case, “Is my Pi-hole doing what it’s supposed to be doing?”
But there are more examples with different dashboards for specific audiences, like:
- For on‑call engineers: “Is something breaking right now?”
- For product managers: “Are users experiencing issues?”
- For new hires: “What does normal look like?”
- For executives: “Is the business impacted?”
A good dashboard is a clarity machine. It reduces anxiety. It makes the system feel understandable. It gives people confidence.
And it does all of that by telling a simple, obvious story.
The Three Rules of a Good Dashboard
1. Show Only What Matters “Right Now“
If everything is important, nothing is. For dashboard context, historical information is fine being a click deeper.
2. Make the Story Obvious
A dashboard should be readable in ten seconds. You should not need to scroll, or hover to get the full story. Not understood—readable.
3. Remove Anything That Requires Explanation
If you must explain a chart, it doesn’t belong on the dashboard. Dashboards are not puzzles. They are tools for understanding.
The Dashboard Litmus Test
Ask someone who didn’t build the dashboard to look at it for fifteen seconds.
Then ask them:
- What’s the story this dashboard is telling?
- What would you do next?
If they can’t answer both, the dashboard has failed. If they answer incorrectly, the dashboard is dangerous. The former is bad, but the latter is catastrophic.
Dashboards Should Make You Feel Safe
A good dashboard reduces uncertainty. It makes your system feel predictable. It helps people make decisions quickly and confidently.
A bad dashboard does the opposite. It amplifies confusion, hides problems, and creates false certainty. Dashboards aren’t just visualizations: they’re trust.
The Only Lesson You Need
There’s only one lesson when it comes to dashboards: the audience matters. If you build dashboards for specific teams, roles, applications, or individuals, you need to speak with the consumers of the dashboard. If you aren’t having these conversations, then you aren’t building what your target audience needs.
It’s ok to have multiple conversations – in fact, it’s better than ok, because you should be. Dashboard design, like monitoring, observability, alerting, and reporting should be a reoccurring conversation. Put that meeting on the books. Your users will be happier for it.
You want to know an even better solution? Giving your users enough training and access to build their own dashboards. Then your only responsibility is making sure the data keeps streaming in to populate it.
