There's a scene that plays out in almost every mid-sized company that has invested in data. The product or business team asks for "a dashboard." The data or development team builds it. Three weeks later, there's a screen full of charts, real-time KPIs, trend arrows in red and green, and possibly a heatmap because it looked good. Everyone nods. Nothing changes.
The problem isn't technical. Data visualization tools — Metabase, Looker, Tableau, PowerBI — are perfectly capable of representing any number in any form. The problem is design. More specifically: most dashboards are built from the data upward, when they should be built from decisions downward. They are answers to questions nobody asked. And data without a question is decoration.
The conversation around UX applied to dashboards has been gaining momentum across several specialist publications this week, and the diagnosis is always the same: when data teams and design teams don't talk, the result is an artifact that impresses in a demo and moves zero needles in production. Here's our read on why it happens and what separates a dashboard that actually works.
Most dashboards display metrics that nobody uses to make concrete decisions.
The design failure isn't in color palettes or chart types — it's in never asking what action each piece of data should trigger.
A good dashboard doesn't show everything: it discards 80% so the remaining 20% is impossible to miss.
The Root Cause: Data as an End, Not a Means
When a team builds a dashboard, the usual sequence is: "what data do we have?" → "how do we display it?" → "does it look good?" This logic produces exhaustive, technically impeccable panels that nobody checks after day one. They are data museums: beautiful, organized, static, and irrelevant to the person who has to make a call at 9 a.m.
The correct sequence is the reverse: "what decision does this person need to make?" → "what information do they need to make it?" → "what is the most efficient way to deliver it?" This is Jobs-to-be-Done logic applied directly to information design. The dashboard user isn't there to look at data. They're there to solve a specific job: detect whether something is going wrong before it escalates, understand why conversions dropped last week, or decide whether to scale a campaign. If the dashboard doesn't do that job, it's a product failure — regardless of how polished it looks.
There's a fundamental difference between a dashboard that has the data and a dashboard that makes the answer obvious. The first forces you to be an analyst to extract value. The second has already done that work for you. The first is what most organizations have.
A dashboard that shows everything shows nothing. Information abundance without hierarchy produces the same effect as information absence: paralysis.
Decision Hierarchy: The Criterion Nobody Puts in the Brief
Dashboards don't have a single user. They have at least three: the person who commissions them (leadership or product), the person who uses them daily (operations, marketing, sales), and the person who builds them (data or engineering). Each has a different idea of what should appear. The usual result is a compromise where everything everyone requested shows up, with no hierarchy between metrics, no distinction between what's urgent and what's merely interesting, no signal of what requires action versus what is just context.
Designing a useful dashboard starts with defining an explicit decision hierarchy. Which metric, if it deviates from its normal range, demands action today? Which are for weekly review? Which are simply historical context? That hierarchy can't be defined by the data team alone — it requires someone who understands the user's real workflow. That's UX work, and it almost never gets done.
Cold Data vs. Actionable Data
There's a distinction worth naming explicitly: cold data and actionable data. Cold data is a correct number that triggers no behavior. "Checkout abandonment rate: 68%." Fine. So what? Actionable data is the same number placed in context with its threshold, its trend, and its expected impact: "Checkout abandonment has been above 65% for three days — the last time this happened, we recovered €12,000 in 48 hours with this change." That's a dashboard that decides.
The difference isn't technical. It's design. It requires someone to have sat with the real user — not the PowerPoint version of the user — to understand what they do when they see that number and what they'd need to act faster. This connects directly to the problem we've explored before around why so many UX improvements improve nothing: optimizing how you present an irrelevant data point is still irrelevant.
Information Density: The Balance Dashboards Constantly Break
There's an understandable temptation in dashboard design: if one data point is useful, more data points are more useful. This logic produces what we could call aviation cockpit syndrome — hundreds of indicators, all technically relevant to someone at some point, impossible to read at a glance for any human under any real pressure. A commercial pilot doesn't read all instruments all the time. They know which ones to check and in what order. The rest are for when something fails.
A well-designed dashboard works the same way. It has a fast-read layer (is anything urgent happening right now?), a diagnostic layer (why is it happening?), and a context layer (is this normal for this time of year?). These layers can literally be separate views, or they can live on the same screen with clear visual hierarchy. What they cannot do is exist all mixed together without distinction — which is the default state of most enterprise dashboards.
The Cognitive Cost of the Saturated Screen
Edward Tufte, the canonical reference in data visualization, popularized the concept of "data-ink ratio": the proportion of visual space dedicated to representing actual information versus decorative elements. But there's a dimension Tufte doesn't name explicitly that is equally important in UX: the cognitive cost of processing a dashboard. Every additional chart, every secondary table, every KPI that "might interest someone" imposes a processing load on the user. It's not that the user ignores the data point — it's that they spend cognitive energy dismissing it before reaching the one they need. At the scale of 20 daily dashboard checks, that cost is significant.
Dashboards with few, well-chosen elements don't look "incomplete." They look professional. Visual austerity is a design decision that's hard to defend in a meeting — there's always someone who asks "why don't we also add...?" — but it's exactly what separates an artifact that gets used from one that gets visited once in the launch demo and never opened again. This tension between what the client requests and what the user needs sits at the core of real UX work, and it's closely related to the principle we explored when discussing intentional friction as a design tool: sometimes the best decision is to remove, not add.
AI in Dashboards: The Latest Layer of Noise (When Done Wrong)
The current trend is adding AI to dashboards. "Ask AI," "Smart Insights," "Automatic Anomaly Detection." Some of these features are genuinely useful. Many are the 2026 version of the same old mistake: adding capabilities without asking what specific job they actually solve for the real user.
The most common case is the data chatbot: users can "ask in natural language" from the dashboard. It's a seductive interface in a demo. In production, it replicates the same fundamental problem in a different format: if the user doesn't know what to ask, AI can't help. And if they know exactly what question needs answering, it would probably have been more efficient to design that answer directly into the dashboard without the conversational overhead.
Where AI genuinely adds value in dashboards is in proactive anomaly detection with enough context for the user to understand whether to act or not. Not "conversion rate dropped 3%" — any chart shows that — but "conversion rate dropped 3% in the mobile user segment, which is outside the normal range for a Tuesday; the last few times this happened it correlated with cache changes on mobile." That's applied intelligence. Everything else is product marketing.
AI in a dashboard shouldn't answer questions. It should make it unnecessary to formulate them.
This principle — that well-applied AI reduces friction rather than adding a conversational layer on top of it — has a direct and underexplored application in dashboards. The question isn't "do we add an AI chat?" but "which decisions take too long today, and could AI accelerate that process without requiring the user to formulate anything?"
How to Design a Dashboard That Works: The Process That Matters
The right process starts with interviews, not tools. Before opening Figma, Looker, or Metabase, you need to sit with the real users of the dashboard — not the people who commission it, but the people who will check it every day — and ask three concrete questions: What decision do you make that could go better with better information? When did you last make that decision and what information did you wish you had? What do you do when something goes wrong, and how do you find out it's going wrong?
With those answers, the metric hierarchy becomes obvious. Level-1 indicators are those that, when they deviate, require action that same day. Level-2 metrics are for periodic review. Level-3 metrics are historical context accessed on demand. This classification should appear explicitly in the design — visually differentiated, not buried in a filter menu.
The next step is defining thresholds and normal ranges for every level-1 metric. A number without context for what's "good" or "bad" cannot drive a decision. If the abandonment rate is 65%, is that a problem? Always? Only on Mondays? Only on mobile? The design must answer those questions without requiring the user to calculate them. The threshold is part of the data.
Finally, the dashboard needs real iteration with real users — not with stakeholders who approve it in a meeting. First versions always reveal metrics nobody looks at and gaps nobody caught in the brief. A dashboard isn't a deliverable: it's a live product that improves with use, exactly like any other interface. Abrupt changes to established interfaces carry a high cost, but in dashboards the cost of not iterating is paid by every decision the entire organization makes.
If your company has dashboards that nobody opens — or ones that get opened but never acted upon — the problem isn't in the data or the tool. It's in the design process that produced them. At Room 714 we audit dashboards from the decision perspective: we map what real jobs each panel is supposed to resolve, redefine the metric hierarchy, and design the presentation layer so the right information is impossible to ignore. If you want to know how much value you're leaving on the table with your current dashboards, we can start with a one-hour conversation.
