Decide the question before designing the screen
The most common dashboard failure is a wall of cards that answers nothing. It happens because the brief was "show the data" rather than "answer this", and every stakeholder added the metric they cared about until the screen had no point of view.
A dashboard that works starts from one sentence: when somebody opens this, what do they need to know or decide? Everything that does not serve that sentence goes to a second screen or goes away. If several people need different sentences, that is several dashboards, or one with a role switch, not one screen with everything on it.
A useful test: cover the screen and ask a regular user what the top-left figure is. If they cannot say, the hierarchy is decorative. That position is the most valuable space on the page and it should be occupied by the thing the sentence names.
A number with no baseline is decoration
Almost no figure means anything on its own. Revenue of a given amount is good or bad depending on last month, on the target, or on the same week last year. A dashboard full of bare figures forces every reader to supply that context from memory, which most of them cannot, so they stop reading it.
- Show the comparison next to the number, not on a separate screen. Previous period, target, or the same period last year, whichever the reader actually uses.
- Say which comparison it is. A percentage change with no stated baseline is worse than no percentage at all, because it looks precise.
- Direction is not the same as good. A rise in refunds and a rise in signups should not both be green, and colour alone should never be the only thing carrying that meaning.
- Give the number a time window on the card. "Last 30 days" belongs next to the figure, not in a filter somebody set twenty minutes ago and forgot.
- Round to the precision somebody would act on. Nobody makes a decision on the second decimal place, and the extra digits cost scanning speed.
The states nobody designs
Dashboards are designed against a screenshot of healthy, populated data. Real users meet the other states constantly, and those states are where the design either holds or falls apart.
| State | Who sees it | What it has to do |
|---|---|---|
| Empty | Every single user, on day one | Explain what will appear here and what to do to make it appear |
| Loading | Everyone, every visit | Hold the layout still. Content that reflows as data lands is the main source of accidental clicks |
| Partial | Anyone whose data is still catching up | Say which parts are current and which are not, rather than mixing them silently |
| Stale | Anyone on a slow or failed refresh | Show when it last updated. A stale figure presented as live is a wrong figure |
| Error | Anyone, eventually | Say what failed and what still works. A whole page replaced by one message throws away the parts that loaded |
| Denied | Anyone without permission | Show a page shaped for their role, not the full page with buttons removed |
The empty state deserves the most attention and gets the least. It is the only screen guaranteed to be seen by every user, it arrives at the exact moment somebody is deciding whether the product is worth their time, and in most builds it is whatever the grid does with zero rows.
Density, and when a chart is the wrong answer
Density is a trade-off rather than a style preference. Somebody who lives in a tool for eight hours a day wants far more on screen than somebody who checks it monthly, and designing the daily tool to the monthly reader's comfort is the more common mistake because the monthly reader is usually the one approving the design.
Charts are frequently used where a number or a table would be better. A chart earns its space when the shape over time is the message. When the reader wants a value they can quote, a large clear figure beats a line they have to squint at, and when they want to compare many items precisely, a sorted table beats a bar chart.
- A single figure with a comparison beats a two-point chart every time.
- Sorted tables are underrated. They support scanning, comparison and copying, and they need no legend.
- If a chart needs a legend to be read, consider labelling the series directly instead.
- Never rely on colour alone to distinguish series or convey status. Add a label, a shape or a pattern, which also covers colour vision deficiency.
- Charts need the same states as everything else. An axis with no data still needs to say so.
Permissions are a layout problem, not a filter
The usual approach is to build the administrator's page and hide parts of it for everyone else. The result is a screen full of gaps, where a viewer sees a layout designed around controls they cannot use and has to infer why. It also makes the interface a poor description of what the person can actually do.
A role should get a page shaped for it. Fewer cards is not a degraded experience, it is the correct one. Where an action genuinely exists but is unavailable to this person, saying so plainly is better than the control silently vanishing, because a missing button and a broken page look identical from the outside.
Hiding a control is presentation, never protection. Anything the interface hides has to be refused by the server as well, and that is a different piece of work from the design. We found and published a defect of exactly this family in our own application.
How to check a dashboard design before building it
- Write the one sentence the screen answers. If it takes two sentences, it is two screens.
- Draw the empty state first, then the loading state, then the error state. Only then the populated one.
- For every number, name its comparison and its time window out loud.
- Look at it with colour removed. Status that disappears is status that was never accessible.
- Open it as the least privileged role and ask whether the page makes sense on its own terms.
- Put real data in it, including the longest name and the largest figure anyone will ever have. Layouts break on real content, not on placeholder content.
We keep a working dashboard online rather than a picture of one, because every point above is about behaviour and a screenshot shows none of it.
What this does not cover
- This is design judgement from building dashboards, not a usability study. We have run no formal testing on these points and would not claim they hold for every audience or every kind of data.
- It says nothing about which charting library, framework or design system to use. Those choices depend on the team maintaining the thing more than on the design.
- The accessibility points here are the ones that come up most in dashboards, and they are not a substitute for testing against WCAG properly. Meeting them does not make a product conformant.
- Analytics dashboards, operational monitoring and customer-facing account areas have meaningfully different demands. The advice here leans towards the last of those, which is what we build most.
- Nothing here covers how the underlying numbers are calculated. A beautifully designed dashboard over a wrong metric is worse than no dashboard, and that problem is out of scope.
Sources
- The What Scene dashboard and the demo at /examples/dashboard. The states table and the checklist are the ones we build and review against, taken from the dashboard behind this site and the public demo, both of which implement every state listed. Run: /examples/dashboard, live build 2026-08.
- WCAG 2.2 quick reference, including use of colour and non-text contrast, W3C Web Accessibility Initiative. Retrieved 25 August 2026.
Revisions
- 31 August 2026 First published.
This page is revised in place rather than replaced, so its address does not change.