Dashboard design best practices come down to three decisions, not fifty.
First, check whether a dashboard is even the right artifact. Most requests for one are really requests for an alert or a report.
Second, show only what someone will act on. Anything else is decoration.
Third, design what happens when the data is missing, late, or wrong. That is where a dashboard earns trust, or loses it.
Search this phrase and you will find pages from Tableau, Sisense, Geckoboard, and half a dozen other BI vendors. Every one shows the happy path: complete data, perfect timing, nothing broken. This post covers that standard advice quickly, then spends its real weight on the part those pages skip.
Before anything else: is a dashboard even the right artifact?
Nobody frames this as a three way choice, but it is one. Pick the artifact before you pick a chart library.
| Artifact | Use it when | The behavior it assumes | |---|---|---| | Alert | Something crossed a threshold and someone must act now | Nobody is watching, so it pushes to the person | | Scheduled report | A recurring question with a stable answer, reviewed on a cadence | Nobody needs to check for updates | | Dashboard | Someone will glance at it repeatedly and needs to explore, not just read | A habit of looking |
The honest consequence follows fast. If the only reason someone opens the dashboard is to check whether something broke, you built a bad alert. If nobody has opened it in a month, you built a report and gave it a URL.
Most requests for a dashboard are actually requests for one of the other two. Building the wrong one is the most expensive mistake on this list, because you cannot fix it with better charts.
Monitoring products fall into this trap constantly. A team asks for a dashboard, so you build one, and it sits unopened on every day that nothing goes wrong. They needed something that comes to them when a threshold is crossed.
The advice everyone already gives, in one place
This part is quick, because it is well covered elsewhere, and a reader searching this term deserves it stated plainly.
- Know who is looking and what decision they make. A dashboard with no decision attached is decoration.
- Put the most important number top left, since that is where the eye lands first.
- Give each question one chart type: comparison, composition, trend, or distribution. Skip pie charts past a few slices, and skip 3D entirely.
- Label things in the words the reader uses, not the words in your database column.
- Give every number context. A number with no comparison, no target, and no trend cannot be acted on.
- Meet accessibility standards, with the real numbers behind them. WCAG asks for a contrast ratio of at least 4.5:1 for normal text, and 3:1 for non text elements, including the meaningful parts of a chart. Never encode meaning in color alone.
Test in grayscale. Turn on a grayscale filter and look at the dashboard for a minute. If two lines disappear into each other, so does the message, for a chunk of your users.
Once those basics are in place, run a usability pass over it before you ship, since a fresh set of eyes catches what months of familiarity hide.
The 5 to 9 rule is audience-dependent, and everyone repeats it as though it is not
Almost every dashboard guide cites the same working memory research, and lands on the same instruction: limit your dashboard to 5 to 9 elements.
That is correct for one audience, and wrong for another.
An executive who glances at a dashboard once a day has a low tolerance for density. Every extra element costs orientation time, and they never build the muscle memory to skip past it fast.
An operator who watches the same screen for eight hours has the opposite tolerance. Repeated daily use trades initial learnability for information throughput. Take a trading dashboard, or a support floor display. Decluttering it aggressively does not make it easier to use. It makes it slower, because the person now has to click for what used to sit in their peripheral vision.
So the rule is not 5 to 9 elements. It is: match density to how often this person looks, and how long they stay. If someone opens the dashboard many times a day and knows the layout by heart, you can go dense. If they open it weekly, you cannot.
The states nobody designs: loading, empty, partial, and stale
This is the part every vendor page skips, and it is where a real dashboard spends most of its life.
Loading
A spinner tells the user one thing: something is happening. If it never resolves, it does not even tell them that.
Skeleton states that match the shape of the incoming content work better. The layout does not jump when data lands, and the user reads structure before the numbers arrive.
Here is the rule that matters most: tiles load independently. Design for tiles finishing at different times, not for one global loading screen.
On an analytics product, a simple count tile comes back in well under a second, while an aggregate like sentiment can take several. Users read that gap as broken rather than busy, unless every tile carries its own skeleton.
Empty
A blank chart is a bug report the user cannot file.
An empty state has to say which of three things happened. There is no data yet, because the account is new. The filter excluded everything, and you should offer to clear it. Or the query failed outright.
Those are three different messages, and three different next actions. Most dashboards show the same blank rectangle for all three, and the user has no way to tell which one they are looking at.
Partial failure
This is the state that never appears in any guide, and it is one of the most common failure modes of a real dashboard.
One widget's query fails while the rest succeed. The wrong answer is to break the whole page over one bad call. The other wrong answer is to silently show nothing where the tile was, since the user reads absence as zero.
The right answer is a tile that says it failed and offers a retry, while everything else keeps working.
On a trading dashboard, a dropped price feed that quietly blanks its own tile is worse than an error message, because a trader reads the empty space as no position.
Stale
This is the most dangerous state, because it looks fine. A cached number that is four hours old renders exactly like a fresh one.
Make staleness visible. Put an as of timestamp on every tile that can go stale, and change its look once the data passes a threshold you decide up front. Write the rule down: a stale value must never look identical to a fresh one.
Two bugs create this quietly, and I have shipped both by accident. One is caching that outlives its usefulness. The other is a timezone error in the last updated stamp itself, which is a special kind of cruel, since the one thing meant to build trust is the thing lying.
Someone who catches a dashboard being wrong once will not trust any number on it again. They are right not to. That is why these four states are not polish. They are the product.
What a dashboard should not show
Even when a dashboard is the right artifact, some things still do not belong on it.
- Vanity metrics with no action attached. If no decision changes based on a number, it is costing attention and returning nothing.
- Individual level personal data. Naming people on a screen that hangs in a shared room, especially in health or support contexts, is a privacy problem the moment somebody walks past it. Aggregate before it reaches the wall.
- Raw logs. That belongs in a drill down, not a tile.
- Metrics that need real investigation, not a glance. If understanding a number takes ten minutes of context, it belongs in a report, not on a wall.
Before you ship any of this, a structured audit will catch the vanity metrics and the privacy problems faster than another round of internal review.
Closing thoughts
The standard advice is fine, and mostly true. It is just written by people whose product looks best on the happy path.
The dashboards that get trusted are the ones that behave well when the data is missing, late, or wrong. Design those four states first. For money specifically, the rules get stricter, which the fintech patterns cover.
If you are scoping something like this, it helps to see how B2B product work gets scoped before the first wireframe.