Dashboard Design: Patterns, Examples, and What Separates Good From Bad
What makes a dashboard work — the job it serves, the hierarchy, density, and the states most teams never design. With real product examples and a pre-launch checklist.
Written ByVlad Hrynchuk
Dashboard design is the practice of deciding what earns a place on a screen people open repeatedly and read at a glance. A dashboard works when it answers its user's first question before they scroll, and fails when it shows everything the database happens to hold. The decisions that matter are which job the dashboard serves, which single metric leads, how dense the screen should be for this user, and what action it drives next.
Key takeaways
- A dashboard is defined by the job it serves — monitor, report, explore, or act. Screens that try to serve all four serve none of them well.
- One metric should dominate the hierarchy. If a user has to hunt for the number that answers their first question, the layout has already failed.
- Density is a function of role and frequency, not of seriousness. A daily operator wants more per screen than a monthly reviewer.
- The empty, loading, and error states are the ones that ship broken, and on a dashboard they are the states new customers see first.
Dashboard design is the practice of deciding what earns a place on a screen people open repeatedly and read at a glance. The hard part is subtraction. Most dashboards fail because they show everything the database holds rather than the one thing the user came to find out.
That failure is measurable. When the default view does not answer the user's first question quickly, they learn that the useful information takes effort to reach, and they stop making the effort. Dashboard hierarchy is a retention lever before it is a visual one.
Here's what this guide covers:
- The four jobs a dashboard can do, and why mixing them fails
- Role, metric, density and action — the decisions that settle the layout
- The component and state work most teams skip
- A pre-launch checklist
Start by naming the job
Four jobs cover nearly every dashboard. They look similar and behave differently, and a screen that tries to serve all four serves none of them.
Monitoring. Live or near-live data, watched for anomalies. Uptime, fraud alerts, fleet status. The design problem is making the abnormal impossible to miss while the normal stays quiet. These need refresh behaviour, status indicators, and a clear timestamp on every figure.
Reporting. A fixed period, summarised. Quarterly performance, monthly spend. These get exported, pasted into decks, and read by people who were not in the product. They need print and share behaviour that most teams discover after launch.
Exploration. An analyst slicing data to find something they did not know to look for. Depth of filtering, drill-down, and saved views matter more than the default layout, because the default is only a starting point.
Operational. The screen that drives the next action in a workflow. A support queue, an at-risk deal list. The measure of success is how quickly somebody moves from opening it to doing something, so the actions belong on the rows, not behind them.
Naming the job before opening Figma is the highest-leverage decision in the whole project. It settles refresh rate, density, interaction depth, and what belongs above the fold.
Role, metric, density, action
Across dashboards we have designed in fintech, proptech, healthcare, and analytics products, four decisions separate the ones people keep opening from the ones they abandon.
Role. Who is the primary user? Not "our users". A specific person with a specific job. Most products have several, and a dashboard serving all of them at sixty percent is worse than one serving the main one completely. Where the roles genuinely diverge, the answer is separate views, not a compromise layout.
Metric. What single number or status answers their first question? That figure dominates the hierarchy. Everything else is supporting. Getting this wrong is instantly legible to the user: showing transaction count to a CFO, or account balance to a developer, signals that the product does not understand their job.
Density. How much can this person process at once? Density tracks role and frequency, not seriousness. Someone who lives in a tool all day reads a compact table faster than spacious cards, because scrolling costs them more than scanning. Someone opening it monthly needs labels and air.
Action. What should happen next? The dashboards that retain users are not reports. They create a visible next step.
PropScore scores a property for three different buyers. Rather than averaging their priorities into one view, the tabs switch the whole hierarchy — an investor and a family are asking different questions of the same address.
The layout layer
If a user has to compare two cards to work out which matters more, the hierarchy has failed.
One metric leads. Size, position and contrast should make it unmistakable.
Five to seven supporting figures without scrolling. Not a rule about working memory, a practical constraint: every extra card makes the leading metric less prominent. When a stakeholder asks for a twelfth KPI, the useful question is which of the eleven it replaces.
Group by question, not by data source. Users think in questions. "How are we doing on revenue?" pulls together figures from billing, CRM, and product analytics. Organising the screen by the system each number came from is an internal concern leaking into the interface.
Put time controls where they are visible. Most dashboard confusion traces back to somebody misreading the period. The date range control belongs at the top, with the active range stated in words rather than implied by a highlighted preset.
The grid underneath all of this is usually a sidebar plus a flexible content area rather than a column grid. What keeps it coherent is a consistent spacing scale and a small set of card sizes.
Three things worth copying here: every figure carries a comparison, the change is signalled by an arrow as well as by colour, and the date range is spelled out in full rather than implied by a highlighted preset.
The component layer
KPI cards need the figure, a label, and a comparison. A number with no baseline is not information. "$48,200" says nothing; "$48,200, up 12% on last month" says something. Where a delta is not meaningful, say so rather than showing 0%.
Charts should be chosen by the question. Trend over time is a line. Composition at a point is a bar, and rarely a pie. Correlation is a scatter. The chart type that looks most impressive is almost never the one that answers fastest.
Data tables carry more dashboard work than charts do, and get less design attention. Column choice, sort defaults, filters, and bulk actions decide whether the table is usable at ten thousand rows or only at fifty.
Colour must not be the only signal — WCAG 1.4.1 treats it as a failure. A red figure needs a direction arrow or a label beside it, both for the roughly one in twelve men with a colour vision deficiency and for anybody glancing at a screen in bright light. See color system.
The cards get the attention in a screenshot; the table does the work. Sparklines inside the rows let someone scan direction across fifty projects without opening any of them.
The states nobody designs
On a dashboard these are not edge cases. They are what new customers see first.
Empty. A new account has no data. Zeroed-out charts read as a broken product. The empty state should say what will appear here and offer the one action that starts producing it.
Loading. Dashboards aggregate from several sources at different speeds, and Nielsen's response-time limits still set the thresholds that matter. Blocking the whole screen on the slowest query wastes the fast ones. Load each region independently with skeletons that match the shape of what is coming.
Error. A failed query must never render as an empty result. Telling a customer with nine thousand records that they have none is a data-loss message that looks like success. See error state.
Stale. When live data stops updating, say when it last refreshed. A dashboard confidently showing yesterday's numbers is worse than one admitting it cannot reach the source.
Partial permission. Somebody who can see three of six panels should see three panels and an explanation, not six broken ones.
Dashboard design best practices: what separates good from bad
The dashboards people keep open share a small set of traits, and almost none of them are visual.
They answer the first question without interaction. No filtering, no scrolling, no interpretation.
They say what a number means, not just what it is. A figure with a comparison, a target, or a threshold is usable. A bare figure is a lookup.
They make the abnormal loud and the normal quiet. If everything is highlighted, nothing is.
They survive real data. Long account names, negative values, thousands of rows, a customer with one record and a customer with a million. Designs validated only against tidy placeholder data break on contact with production, which is the strongest argument for prototyping against a real dataset early.
They respect what the user already knows. A finance team has terms for things. Renaming them to something cleaner costs more than it gains.
Real products, and the decision each one represents
Stripe treats the dashboard as an inspection surface. Dense, event-oriented, built for someone who needs to trace a specific transaction and read its full history. That density is right for developers and finance operators, and copying it into a product used by occasional non-technical users produces anxiety rather than confidence.
Linear takes the opposite position: an opinionated default view with very little configuration. The bet is that a well-chosen default beats a customisable screen most people never customise. It usually does.
Datadog is a monitoring dashboard at the extreme end of density, and it works because its users are specialists who spend hours a day in it and would lose more time to scrolling than to scanning.
Google Analytics 4 is the widely-cited example of an exploratory dashboard where the depth arrived without a usable default. The lesson is not that exploration is wrong. It is that an exploratory tool still needs an opening view that answers something on its own.
Ramp and Mercury both lead with a single figure chosen for a specific role, which we broke down screen by screen in our fintech dashboard guide.
What we see most often in audits
The hierarchy was built around available data. The first screen shows what was easy to query rather than what was asked.
One dashboard for every role. Serving four personas at sixty percent each.
Density borrowed from a different audience. Developer-tool density applied to occasional users.
States shipped as an afterthought. Empty, error, and loading designed at implementation time by whoever hit them.
Charts chosen for looks. A donut where a bar answers faster.
No stated time period. The single most common source of a dashboard being misread.
Pre-launch checklist
| Question | What a good answer looks like |
|---|---|
| Which of the four jobs is this? | One named job, not a blend |
| Who is the primary user? | A specific role, not "our users" |
| What is their first question? | One question, validated with real users |
| Which metric answers it? | One figure that dominates the hierarchy |
| What action does this drive? | A visible next step, not a dead end |
| Is the density right for this role? | Calibrated to how often they open it |
| Does the empty state teach? | Explains what appears and how to start |
| Can error be told from empty? | Two distinct states, error offers retry |
| Is the time period stated? | In words, not implied by a highlight |
| Has it been tested on real data? | Long names, negatives, and scale |
Where to go next
If the dashboard exists and people are not using it, the cause is usually one of the six above, and a UX audit finds it faster than a redesign. If you are building the first version, name the job and the primary metric before anything else is drawn.
We design dashboards for B2B SaaS teams where the screen is the product rather than a feature of it. If yours is not earning the attention it should, our UX audit service starts with exactly this, or see how we work as an embedded design team.
