Here's a question worth sitting with: how many dashboards have you designed — or used — that actually changed someone's mind about something?
Most dashboards exist to look like work is happening. Charts go up, numbers tick down, someone screenshots a widget for a Monday morning update. But did anyone actually decide anything differently because of what they saw? Usually not. And that's a design failure we don't talk about enough.
What happened
A growing body of thinking around data visualisation is pushing designers to reconsider what dashboards are actually for. The argument is deceptively simple: dashboards should be designed as decision-support tools, not data displays. That means starting with the questions users need to answer — not the data you happen to have.
It sounds obvious. It isn't.
The distinction shifts the entire design process. Instead of asking "what charts should we use?" you're asking "what does this person need to do next?" Instead of organising by data category, you're organising by decision priority. It's a fundamentally different starting point, and it produces fundamentally different screens.
The bigger picture
Most dashboard projects start in the wrong place. Someone hands you an API, a database schema, or a spreadsheet full of metrics, and the design challenge quietly becomes: how do I make this look good? Which chart type? What colour palette? How many widgets fit above the fold?
None of those questions matter yet.
The actual design problem is upstream. Before you touch any tool, you need to know: what decision does this person need to make? What's the question they're walking in with? And what would the answer need to look like for them to act on it?
When you start there, something uncomfortable happens. Half the data on most dashboards simply disappears — because it was never helping anyone decide anything. It was decoration. Expensive, well-charted decoration.
I've worked on projects where stripping out two-thirds of a dashboard's content made it dramatically more useful. Not because the removed data was wrong, but because it was noise. Every chart that doesn't serve a decision is a chart competing for attention with one that does.
This pattern shows up across UI design, not just dashboards. We debate caret versus chevron on an accordion component without first asking what the user expects to find inside it. We name components based on how they look rather than what they do. We reach for the artefact before we've understood the intent. Dashboards just make the cost of this habit painfully visible — a badly named component causes friction, but a misleading chart causes a bad business decision.
The shift from "data display" to "decision support" changes the designer's job in practical ways. You become less of a chart decorator and more of an information architect — someone who shapes what gets shown, what gets hidden, and in what order. You're designing the absence of data as much as the presence of it.
This is harder than it sounds. It means having conversations with stakeholders that go beyond "can you add a pie chart for regional sales." It means pushing back on dashboards that exist because someone important wants to see their numbers, not because those numbers help anyone act. It means asking "what will you do differently if this number goes up?" and being comfortable with the silence that follows.
But it's also where design adds genuine, measurable value. A dashboard that helps someone make a faster, better decision is worth more than a dozen that look impressive in a board presentation. And it's a much stronger case for design's value than showing off a polished Figma file.
There's a useful test I keep coming back to. Look at any dashboard and ask: if I removed this element, would the user's next action change? If the answer is no, that element isn't informing a decision. It's furniture.
Takeaway
Before you design your next dashboard — or any information-dense screen — write down the three decisions your user needs to make. Not the metrics they want to see. The decisions. If a chart, number, or widget doesn't directly support one of those decisions, cut it. The best dashboard isn't the one with the most data. It's the one where every element earns its place by helping someone do something they couldn't do without it.