Because it does not answer a question anybody was asking. Most dashboards are assembled from whatever data was available rather than designed around a decision someone has to make. The result is a screen full of correct numbers that changes nobody's behaviour, so people stop opening it.
This is the most expensive kind of design failure, because dashboards are costly to build and their failure is quiet. Nobody files a complaint about a dashboard. They just navigate past it.
We have designed and rebuilt enough of these to have a strong view about what separates the ones people rely on. Most of it comes down to editing rather than adding.
It exists to answer one question fast, and to make it obvious when something needs attention. That is a narrower job than most dashboards attempt. If you cannot name the question in a sentence, the screen will end up as a data dump.
The question is usually some version of is everything normal, or how are we doing against the thing we care about. Both are answerable at a glance if the design commits to them. Neither is answerable if the screen presents twelve equally weighted metrics.
Exploration is a different product. When a user wants to slice data and ask their own questions, that is a reporting tool, and it belongs on a separate screen with different affordances. Merging the two produces something that does neither job well.
Treating every metric as equally important. When everything on a screen has the same visual weight, the user has to do the prioritising, every single time they look at it. That work is exhausting, so they stop.
Good dashboards are aggressively hierarchical. One number is the headline. Two or three support it. Everything else is smaller, further down, or on another page. Making that choice is uncomfortable because it means telling a stakeholder their metric is not the headline, and that discomfort is why most dashboards avoid it.
The principle behind this is one of Jakob Nielsen's ten usability heuristics, developed with Rolf Molich in 1990 and unchanged in substance since 1994. Aesthetic and minimalist design holds that every extra unit of information competes with the relevant units and diminishes their visibility. A dashboard is where that competition is fiercest.
Fewer than you think, and grouped rather than gridded. We aim for one headline, a small set of supporting figures, and a single trend. When a screen needs more than that, the honest answer is usually that it is serving two audiences and should be two screens.
Grouping matters as much as count. Six numbers arranged in three labelled pairs read faster than six numbers in a row, because the user learns the structure once instead of reading each tile independently.
Give every number a comparison. A figure on its own is not information. The same figure against last week, against target, or against a normal range is a judgement the user can act on without doing arithmetic.
Yes, but never as the only signal, and never at low contrast. Colour is the fastest way to communicate good and bad, and it is also the least reliable, because it fails for colour blind users, in bright sunlight, and on cheap projectors during a board meeting.
The contrast requirements are specific. The Web Content Accessibility Guidelines success criterion 1.4.3, at level AA, requires a contrast ratio of at least 4.5 to 1 for normal text and 3 to 1 for large text, where large means at least 18 point or 14 point bold. Pale grey secondary metrics on white are the most common failure we find on dashboards, and they fail for everyone, not only for users with low vision.
Pair colour with a second cue. An arrow, a sign, a label, or position. Our guide to WCAG accessibility covers the wider set of requirements this sits inside.
As real designs, not as afterthoughts. A new customer's first view of your dashboard is the empty one, and it is the screen most likely to determine whether they continue. If it shows zeros in the layout meant for real data, it reads as broken.
Say what will appear here and what produces it. An empty state that explains the connection to make or the first action to take converts a dead end into a next step. This is visibility of system status, the first of Nielsen's heuristics, applied to the case where the status is nothing yet.
Loading matters for the same reason. A dashboard that pops elements in at different times causes layout shift and makes people lose their place. Reserve the space, show a placeholder that matches the eventual shape, and never move content after the user has started reading it.
Fast enough that interaction feels immediate. Google's Core Web Vitals guidance sets the good threshold for Interaction to Next Paint at 200 milliseconds, measured at the 75th percentile of page loads and segmented across mobile and desktop. Interaction to Next Paint became a stable Core Web Vital in 2024, replacing First Input Delay.
Dashboards fail this more often than marketing pages, because filtering and re-rendering large datasets is genuinely expensive. The fix is usually not a faster query. It is rendering less at once, and acknowledging the interaction immediately even when the data takes longer.
Acknowledgement is the cheap win. Disabling a control and showing that the filter has been applied, right away, feels far better than a screen that stays inert for a second and then jumps. Our piece on Interaction to Next Paint covers how the metric is measured.
Eventually, and never as a substitute for a good default. Customisation is often proposed as the answer to disagreement about what belongs on the screen, and it moves the problem to the user instead of solving it. Most people never change a default, so a weak default with strong customisation is still a weak dashboard.
The heuristic worth citing here is flexibility and efficiency of use, which is about letting experienced users move faster without getting in the way of newcomers. That is customisation done well: shortcuts and saved views for people who have earned them, not a blank canvas on day one.
Where we do add flexibility early is time range and scope. Those are the two dimensions everyone genuinely differs on, and they are cheap to support. Our notes on data table design cover the drill down layer underneath.
Watch people use it, and watch what they do next. Analytics tell you a dashboard was opened. They do not tell you whether the person found the answer, and a dashboard that gets opened and abandoned looks identical to one that works.
Five users at a time is enough. Jakob Nielsen argued in an article published on March 18, 2000 that the first five users in a test reveal roughly 85% of usability problems, and that further rounds after a redesign beat one large study. Dashboard problems are usually severe enough that five people surface them immediately.
Ask each person what they think the headline number means before you explain it. The gap between your intent and their reading is the design problem, and it is almost always larger than the team expects.
Write the one question your dashboard answers, then look at your current screen and count how many elements help answer it. Everything that does not is a candidate for a different page. That edit is usually the entire redesign.
Then check your contrast ratios and your empty state, because those two are quick and they affect every user. If you want help reworking a dashboard that people are not opening, or a review of one before you build it, we are happy to look at it with you at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.