By Mehdi HassanWhat makes a good dashboard design?
A good dashboard design helps a specific person make a specific decision faster than they could without it. It shows the few numbers that matter for that decision, explains whether each one is good or bad, and points to what to do next. Everything else on the screen is a cost the reader pays in attention.
Most dashboard guides start with chart types and color palettes. We start one step earlier, with words. Before anyone opens Figma, we write down who opens the dashboard, what they're trying to decide, and the one sentence they should walk away with. That sentence becomes the headline at the top of the screen, and it decides which charts earn a place below it.
This guide is the hub for everything we've written on dashboards. It covers the method end to end, and each section links to a deeper article: the SaaS dashboard design best practices checklist, choosing charts, designing KPI cards and tables, admin tools, mobile and the copy that holds it all together.
Quality | What it looks like | What failure looks like |
|---|---|---|
Purpose | One named decision per dashboard | A page of every metric the database has |
Headline | A written insight at the top | A grid of charts with no conclusion |
Context | Each number has a comparison | Bare totals nobody can judge |
Hierarchy | Summary, then trends, then detail | Everything the same size and weight |
Action | A clear next step or drill-down | A dead end that sends people to spreadsheets |
Start with the decision: what is this dashboard for?
Every dashboard should exist to support one decision or one recurring job, and you should be able to say it in a sentence. "Help the head of sales decide which deals need attention this week" is a purpose. "Show sales data" is not. The purpose sets the audience, the time frame, the metrics and how often people will look.
Dashboards usually fall into three jobs. Monitoring dashboards are opened daily to check that nothing is broken. Analysis dashboards are opened when someone needs to understand why a number moved. Reporting dashboards are opened weekly or monthly to show progress to a team, a board or a customer. Trying to do all three on one screen is the most common reason dashboards get ignored.
Dashboard job | Who opens it | What it needs most |
|---|---|---|
Monitoring | Operators, support, on-call | Status at a glance, alerts, exceptions |
Analysis | Analysts, product managers | Filters, breakdowns, drill-down |
Reporting | Founders, boards, customers | Headline insight, trend vs target |
Workflow | Admins, ops teams | Tables, queues, bulk actions |
The workflow row matters for product teams. Many "dashboards" are really work queues, where people come to act rather than read. Those follow the rules of admin panel design and lean on well-built tables more than on charts.
Why should you write the headline insight first?
Writing the headline insight first forces you to decide what the dashboard is actually saying before you design how it looks. If you can't write a sentence like "Trial-to-paid conversion is down this month because fewer trials reached the setup step," you don't yet know which charts the reader needs, so any layout you draw is decoration.
The headline doesn't have to be generated live by the product, although some products do that. In a static design it can be a title pattern: a metric, a direction and a reason or a comparison. The point is that the reader gets the conclusion in the first line and then uses the charts to check it, instead of building the conclusion themselves from six charts.
- Weak title: "Revenue." The reader has to work out whether it's good news.
- Better title: "Revenue this month vs last month." Now the comparison is clear.
- Headline insight: "Revenue is up on last month, driven by annual upgrades." The reader knows the answer and the reason.
This is the copy-first approach we use across product work, and it's the least covered part of dashboard design. Our guide to dashboard copywriting goes deeper on titles, labels, empty states and the small explanations that stop people misreading numbers.
If you can't write the headline, you're not ready to draw the chart.
What are the core dashboard design principles?
The core dashboard design principles are clarity of purpose, a clear hierarchy, context for every number, consistency and restraint. They sound obvious, and most dashboards still break at least two of them because metrics get added over time and nobody removes the old ones.
- One purpose per view. A dashboard that answers one question well beats one that answers ten badly.
- Hierarchy by importance. The most important number is the biggest and sits top-left, where people start reading.
- Context for every number. A number alone means nothing. Show it against a previous period, a target or a benchmark.
- Consistent encoding. The same color means the same thing everywhere. Green is never "good" on one card and "category B" on the next.
- Restraint. Cut gridlines, 3D effects, decorative icons and any chart that doesn't change a decision.
- Progressive disclosure. Summary first, detail on demand through drill-downs, tooltips and linked tables.
- Honest scales. Bar charts start at zero. Axes are labelled. Time periods are stated.
- Accessible by default. Color is never the only signal, text meets contrast guidelines, and charts have text alternatives.
For a pass/fail version you can run against your own product, use our 20-point SaaS dashboard checklist. For the accessibility side, the W3C's Web Content Accessibility Guidelines are the reference most teams design against.
How do you design a dashboard step by step?
You design a dashboard by moving from words to wireframe to visual design, in that order. Each step narrows the options, so the expensive visual work happens only after the content is settled. Skipping straight to high-fidelity screens is how teams end up redesigning the same dashboard twice.
Name the user and the decision
Write one sentence: who opens this, how often, and what they decide. Talk to two or three real users if you can.
List the questions, then the metrics
Write the questions the user asks in order. Map each question to the metric that answers it. Drop metrics that answer no question.
Write the headline and card titles
Draft the headline insight and a title for every card and chart in plain language. This is your content model.
Sketch the reading order
Arrange the summary, trends and detail in the order people read them. Use grey boxes, not real charts.
Choose chart types per question
Pick the chart that answers each question most directly: lines for trends, bars for comparisons, tables for lookup.
Design states, not just the happy path
Draw loading, empty, error, zero-results and partial-data states. These are where dashboards feel broken.
Test with real data
Swap placeholder numbers for real ones, including outliers and long labels. Real data breaks layouts that lorem ipsum hides.
Ship, watch, prune
After launch, watch which cards people use and which they ignore. Remove what nobody needs.
How should you lay out a dashboard?
Lay out a dashboard in the order people read it: a summary row of KPIs at the top, trend and comparison charts in the middle, and detailed tables or lists at the bottom. People scan from the top-left, so the most important number goes there, and each row down adds detail for those who need it.
A 12-column grid gives you enough flexibility for cards of different widths while keeping alignment consistent. Keep spacing consistent too: the same gap between all cards, the same internal padding, the same title position. Inconsistent spacing reads as noise even when users can't say why.
- Top row: three to five KPI cards answering "how are we doing?" Our guide to KPI card design covers deltas, comparisons and sparklines.
- Middle: one or two large charts answering "what changed and when?" Choosing the right one is covered in how to choose a chart type.
- Bottom: a table answering "which ones?" so people can act. See data table design for sorting, filtering and density.
- Global controls: date range and key filters in one place at the top, applied to everything on the page.
Hypothetical example: laying out a customer success dashboard
For example, suppose a B2B SaaS company wants a dashboard for its customer success managers. The decision is "which accounts do I call this week?"
The headline reads: "Seven accounts show falling usage this month." The KPI row shows accounts at risk, renewals due in 30 days and average health score, each compared to last month. The middle chart shows weekly active users across the manager's book of accounts. The bottom table lists every at-risk account with its usage trend, renewal date and owner, sorted by renewal date, with a "log call" action on each row.
Nothing on the page shows total company revenue or marketing traffic, because those don't help this person decide who to call.
What does good dashboard UI design look like in practice?
Good dashboard UI design is quiet: neutral surfaces, one accent color for emphasis, clear type hierarchy and consistent components. The data should be the loudest thing on the screen. When the interface competes with the numbers through gradients, heavy shadows and decorative icons, readers take longer to find what matters.
UI element | Good default | Avoid |
|---|---|---|
Color | Neutral base, one accent, semantic red/green used sparingly | A different color per card |
Typography | Tabular figures for numbers, two or three sizes | Many sizes and weights |
Charts | Direct labels, light gridlines or none | Legends far from the data, 3D |
Cards | Consistent padding, title in the same spot | Mixed card styles |
Dark mode | Designed as its own theme with tokens | Inverted colors |
Density | A comfortable default with a compact option | One fixed density for all users |
Tabular (monospaced) figures are worth calling out: they keep digits aligned so columns of numbers can be compared quickly. Most modern UI typefaces support them through a font setting, and developers can turn them on with the CSS font-variant-numeric property.
On the build side, most startups don't need a custom component library to get this right. A well-themed set of open-source components and a small set of tokens gets you consistent cards, tables and charts. Our guide to web app UI design covers the patterns around the dashboard: navigation, forms and settings.
How does dashboard UX change for different products?
Dashboard UX changes with the user's time pressure, expertise and risk. A clinician needs the one abnormal value in seconds, an admin needs to clear a queue, and a founder wants a weekly trend. The principles stay the same, but the balance of summary, detail and action shifts with the context.
- SaaS analytics: trends over time, segment comparisons, export. Start with the SaaS dashboard checklist.
- Internal tools: queues, tables, bulk actions and role-aware controls. See admin panel design.
- Healthcare: exceptions first, minimal clicks, careful use of color. See healthcare dashboard design.
- Fitness and wellness: progress, streaks and motivation over raw numbers. See fitness app dashboard design.
- AI products: confidence, sources and controls alongside results. See AI product UX.
- Mobile: a summary-first view with fewer, stacked cards. See mobile dashboard design.
If you want to see these ideas applied, our annotated dashboard design examples walk through well-known SaaS products and the specific decisions that make each one work, from how they title charts to how they handle empty states.
What are the most common dashboard design mistakes?
The most common dashboard design mistakes are showing too much, showing numbers without context and designing only the happy path. A typical failing dashboard has a card nobody can explain and a state, usually empty or loading, that was never designed.
Pros
- Fixing scope (removing cards) is cheap and usually the biggest improvement
- Adding comparisons to existing numbers needs little design work
- Rewriting titles and labels can be done without touching code structure
Cons
- Missing empty and error states often need new components
- Wrong chart types can need new data queries, not just new visuals
- A dashboard built for three jobs usually has to be split into separate views
- Vanity metrics. Totals that only go up, like all-time signups, make people feel good and change no decisions.
- No comparison. "1,204 active users" means nothing without last week or a target.
- Chart overload. Pie charts with many slices, dual axes and stacked areas that hide the trend.
- Unclear time frames. Readers can't tell whether a number is today, this month or all time.
- Broken states. Blank cards while loading, cryptic errors and empty tables with no guidance.
- Ignoring cost. Teams spend on visual polish before the content model is right. Our dashboard design cost guide covers where budget actually goes.
What should you read next on dashboard design?
Read the article that matches the part of the dashboard you're working on now. If you're starting fresh, begin with the checklist. If you're mid-project, jump to the component you're stuck on. Each guide below goes deeper on one piece of this hub.
If you're working on | Read |
|---|---|
Reviewing an existing dashboard | |
Budgeting a dashboard project | |
Picking charts | |
The KPI row | |
Tables, filters and bulk actions | |
Internal tools and back office | |
Inspiration with reasoning | |
Phone screens | |
Titles, labels and insights |
If the vocabulary is the obstacle, our product design glossary explains the UI and UX terms designers use when they talk about dashboards, from progressive disclosure to information density.
