Dashboard UI Design: Best Practices and Examples for SaaS Products
Most SaaS dashboards start as a good idea — one screen that shows how things are going — and end up as a grid of every chart the data team could produce. Users open them, scan for the one number they care about, and leave. Good dashboard user interface design reverses that: it starts from the decisions people need to make and works backwards to the pixels.
Stephen Few’s definition is still the most useful test. A dashboard is a “single-screen display of the most important information people need to do a job”, presented so they can “monitor what’s going on in an instant” (Stephen Few, Information Dashboard Design, O’Reilly, 2006, via UXmatters’ review). Every recommendation in this guide comes back to those two phrases: most important and in an instant.
This guide is written for founders, product managers and designers working on data-heavy web apps. Throughout, we separate established principles — usability research and accessibility standards, with sources — from our recommendations, which come from designing product interfaces and are worth testing with your own users. The illustrations are conceptual and use sample data.
Start with the job the dashboard does
Before you design dashboard screens, decide what kind of dashboard you are building. The same metrics can need a completely different layout depending on whether someone is watching for problems, investigating a trend or deciding what to work on next.
What the research says: Nielsen Norman Group distinguishes operational dashboards, which “impart critical information quickly to users as they are engaged in time-sensitive tasks”, from analytical dashboards, which support analysis and decision-making. IBM’s Carbon Design System makes a similar split between presentation dashboards that show the current status of key indicators and exploration dashboards that let users interact with data to find patterns. (Sources: Nielsen Norman Group — Dashboards: Making Charts and Graphs Easier to Understand; IBM Carbon Design System — Dashboards)
Three jobs a SaaS dashboard can do
| Dashboard job | The user’s question | Data freshness | Density | Typical SaaS example |
|---|---|---|---|---|
| Monitor (operational) | “Is anything wrong right now?” | Live or near-live | Low: few signals, strong alerts | Infrastructure status, support queue, payments failing |
| Analyse (analytical / exploration) | “Why did this change?” | Hourly or daily is usually fine | High: filters, comparisons, drill-down | Product analytics, revenue reporting |
| Act (home or workspace) | “What should I do next?” | Fresh enough to act on | Medium: summary plus a task list | SaaS app home screen, account overview |
Our recommendation: Treat the third type as its own category. Many SaaS “dashboards” are really home screens whose job is to send the user somewhere — a task to finish, an invoice to approve. These need clear next actions more than they need charts.
Write the questions before you draw anything
The most effective step in dashboard UX design happens before any layout work. For each user role, list three to five questions the dashboard must answer, then map each question to one metric and one visual. If a chart doesn’t answer a listed question, it belongs in a report, not on the dashboard.
Example question map for a B2B SaaS revenue dashboard
| Question | Metric | Visual | Comparison |
|---|---|---|---|
| Are we growing? | Monthly recurring revenue | KPI card + 12-month line | vs last month and target |
| Where is growth coming from? | New, expansion and churned MRR | Stacked or grouped bars by month | vs same month last year |
| Which accounts need attention? | Accounts with falling usage | Sorted table with status | vs their own 30-day average |
Information hierarchy: deciding what the eye sees first
What the research says: Carbon’s dashboard guidance is direct: “Prioritize data by importance, then create a clear visual hierarchy,” and “the most important data should have the highest contrast and occupy the largest area.” (Source: IBM Carbon Design System — Dashboards)
A three-tier layout that works for most SaaS dashboards
In most product dashboard design work we start from three tiers and adjust from there:
- Summary: three to five KPI cards across the top. These answer “how are we doing?” in one scan.
- Trend and breakdown: one or two charts that explain the KPIs — usually a time series and a breakdown by segment.
- Detail: a sortable table or list where the user can act — open a record, assign an owner, export.
Our recommendation: Keep the order stable across every dashboard in your product. When users learn that the top row is always status and the bottom is always the list they act on, they stop reading layouts and start reading data.
KPI cards that answer “compared to what?”
A number on its own is rarely useful. “4,120 active users” means nothing until the reader knows whether that is up or down, and against what. A complete KPI card has five parts: a plain-language label, the value with its unit, the change, the comparison period, and a link to the detail behind it. A small sparkline is optional but helps show direction.
Our recommendation: Use tabular (fixed-width) numerals for figures that sit in columns or update live, so digits don’t shift as values change. Show the direction of change with an arrow and a sign as well as colour, and say “vs last 30 days” rather than leaving the comparison implied.
Metric definitions and data freshness
Dashboards lose trust when two people read the same number differently. “Active users” can mean signed in, performed a key action, or was billed. Every metric should have a definition one click away — what it counts, how it’s calculated, where the data comes from — and every dashboard should say how current it is.
- Show an “updated” time near the dashboard title, and a warning when data is older than users would expect.
- Flag estimates. Stripe’s documentation, for example, notes that its home page charts are estimates and that multiple currencies are converted using estimated exchange rates (Stripe Support). Saying so in the interface prevents support tickets.
- Keep a metric dictionary shared by product, data and design, so labels and tooltips are written once and reused.
Choosing the right chart for the question
Chart choice is where many dashboards go wrong, usually because the chart was picked for variety rather than for the question.
What the research says: People estimate length and 2D position accurately, which is why bar charts, line charts and scatterplots are reliable for quantitative data. Nielsen Norman Group describes pie and donut charts as “notoriously poor at most information-communication tasks”, finds radial gauges harder to read than linear graphs, and advises that colour “should not be used to communicate information about quantitative values or magnitude”. (Source: Nielsen Norman Group — Dashboards: Making Charts and Graphs Easier to Understand)
Matching the question to the chart
| The question | Use | Avoid | Why |
|---|---|---|---|
| How do categories compare? | Sorted horizontal or vertical bars | Pie or donut with many slices | Lengths compare accurately; sorting does the ranking for the reader |
| How has this changed over time? | Line chart (bars for few periods) | Area charts with many stacked series | Position over time shows direction and rate of change |
| What share does each part have? | Stacked bar, or a single bar of 100% | Pie with similar-sized slices | Angles are hard to compare; a stacked bar keeps parts on one scale |
| Are we on track to a target? | Bullet chart or progress bar | Radial gauge | A linear scale is easier to read and uses less space |
| How are values distributed? | Histogram or box plot | Averages alone | An average hides skew and outliers |
| Is there a relationship? | Scatter plot | Two separate charts side by side | One shared plane shows the relationship directly |
Layout, navigation and density in web app dashboard design
Grids and layout patterns
Most dashboards sit on a 12-column grid with cards that span 3, 4, 6 or 12 columns. A fixed grid keeps alignment consistent and makes responsive behaviour predictable. Free-form layouts give more control for wall displays or reports but are harder to keep tidy.
Datadog is a useful real-world reference because it offers both: its documentation describes grid-based dashboards, “Timeboards” with automatic layouts that represent a single point in time, and “Screenboards” with free-form layouts (Datadog Docs).
Our recommendation: Default to a fixed grid with a small set of card sizes. Free-form layouts are worth the extra effort only when users build their own dashboards for display on a shared screen.
Density without clutter
Dense dashboards are not a problem in themselves — analysts and operators often prefer seeing more at once. Clutter comes from inconsistency: mixed alignments, too many colours, repeated legends and decorative borders. Remove those and the same amount of data reads more calmly.
Our recommendation: Offer a compact view for expert users rather than making everything compact by default. A comfortable row height of around 48px and a compact one of around 36px is a common pairing in data tables.
Where the dashboard sits in the app
In web app dashboard design, the dashboard is rarely the whole product. It needs a clear path to the screens behind each number. Every KPI and chart segment should be clickable through to a filtered list, and the filters should carry across so the user doesn’t have to recreate them.
Filters, date ranges and drill-down
Filtering is where analytical dashboards earn their keep, and where they most often confuse people. Three decisions matter most.
- Global versus local filters. Make it obvious which filters affect everything and which affect one chart. Linear’s documentation describes both: dashboard-level filters that “apply globally to all insights in that dashboard”, and filters on an individual insight that affect only that insight (Linear Docs).
- Date range and comparison together. Stripe lets users choose a preset or custom date range, a time unit and a comparison range for the home page charts (Stripe Support). Pairing the range with a comparison is what turns numbers into change.
- Filtering by clicking the data. Plausible’s dashboard lets users “click on any of the entries in any of the reports to filter” the whole dashboard by it (Plausible Docs). It removes a trip to a filter panel for the most common question: “show me only this.”
Our recommendation: Show every active filter as a removable chip above the content, store filters in the URL so views can be shared and bookmarked, and keep a visible “Reset” control. A dashboard that silently remembers yesterday’s filter is a common source of wrong decisions.
What the research says: Carbon recommends that “when a user manipulates one chart, other charts showing related data sets should automatically update”, and that colours stay consistent for each data set across the dashboard. (Source: IBM Carbon Design System — Dashboards)
Designing empty, loading, error and no-results states
A dashboard spends much of its life not in its ideal state: data is still loading, a new account has no data yet, a filter returns nothing, or a source fails. These states are part of dashboard UX design, not edge cases to patch later.
What the research says: Jakob Nielsen’s response-time limits still frame loading design: about 0.1 second feels instantaneous, about 1 second keeps the user’s flow of thought, and around 10 seconds is the limit for keeping attention, after which users need an indication of when the wait will end. (Source: Nielsen Norman Group — Response Time Limits)
What the research says: Nielsen Norman Group’s guidance on skeleton screens: below about 1 second, show no loading indicator; for full-page loads under 10 seconds, a skeleton screen works well; a spinner suits a single module such as a dashboard card; and for waits over 10 seconds, use a progress bar. (Source: Nielsen Norman Group — Skeleton Screens 101)
What each state needs to tell the user
| State | What the user needs to know | Design response |
|---|---|---|
| Loading | Something is happening and roughly how long | Skeleton for the page; per-card loading for slow widgets so fast cards appear first |
| Empty (new account) | Why there’s no data and how to get some | Explain what will appear here and give one action, e.g. connect a source or invite a teammate |
| No results | The filters excluded everything | Name the filters responsible and offer to clear them |
| Error | What failed, whether it’s their fault, what to do | Plain-language message, retry, and keep other cards working |
| Stale or partial | The numbers may be out of date | Show the last successful update time and which source is delayed |
Our recommendation: Never show a zero when the truth is “no data”. A chart reading 0 signups after a failed sync looks like a business problem rather than a technical one. Use a distinct empty or error treatment instead.
Role-based and personalised dashboards
The founder, the sales manager and the support lead all log into the same product but ask different questions. One dashboard for everyone usually means a dashboard that serves nobody well. There are two ways to handle this, and most products need both.
- Role-based defaults. Choose a sensible starting dashboard for each role, built from that role’s questions. New users get value without configuring anything.
- Personalisation. Let people add, remove and reorder cards. Shopify’s overview dashboard lets merchants add, remove, rearrange and resize metric cards (Shopify Help Center); Stripe lets users add, remove and organise home page widgets (Stripe Support).
Permissions belong in the same conversation. Stripe’s documentation notes that users with a View only role can’t create payments, refunds or payouts in its mobile app (Stripe Docs). Hide or disable actions a role can’t perform, and say why, rather than letting users discover the restriction through an error.
Our recommendation: Start with role defaults and add personalisation once you see what users change. Fully blank, build-your-own dashboards look flexible in a demo but leave most users staring at an empty canvas.
Responsive dashboards and mobile app dashboard UI design
A dashboard designed for a 1440px monitor will not simply shrink to a phone. The question changes as the screen does: on mobile, people usually want to check a few numbers or respond to an alert, not explore.
What the research says: WCAG 2.2 Success Criterion 1.4.10 Reflow (Level AA) requires content to be usable at a width of 320 CSS pixels without scrolling in two dimensions, with exceptions for content such as data tables and maps that need a two-dimensional layout. Success Criterion 2.5.8 Target Size (Minimum) (Level AA) sets a minimum target of 24 by 24 CSS pixels, with exceptions. (Source: W3C — WCAG 2.2)
How a dashboard typically adapts
| Desktop | Tablet | Mobile | |
|---|---|---|---|
| KPIs | Row of 4–5 cards | 2 × 2 grid | Stacked; top 2–3 only, rest behind “More” |
| Charts | Side by side | Full width, stacked | One chart, simplified axes, tap for detail |
| Tables | Full table with sorting | Fewer columns | List of cards with the key column first |
| Filters | Persistent bar | Collapsible bar | Sheet opened from a filter button with a count of active filters |
Stripe’s mobile app is a good example of mobile app dashboard UI design built around the phone’s strengths rather than a shrunken desktop. Its documentation lists dashboard charts, push notifications including a daily summary, search, and widgets for individual metrics (Stripe Docs).
Our recommendation: Decide what is desktop-only and say so in the interface. Being explicit beats a cramped mobile editor that half works.
Accessibility and colour in dashboards
Dashboards rely heavily on colour and small text, which makes them easy to get wrong for people with low vision or colour-vision deficiency. The relevant WCAG criteria are specific enough to design against.
What the research says: 1.4.1 Use of Color (Level A): colour must not be the only visual means of conveying information. A red/green status dot alone fails; a dot with an icon or text label passes. (Source: W3C — Understanding SC 1.4.1 Use of Color)
What the research says: 1.4.11 Non-text Contrast (Level AA): parts of graphics needed to understand the content need a 3:1 contrast ratio against adjacent colours — for example, chart lines against the background and adjoining pie slices. The criterion doesn’t apply where the same information is given in text, such as values labelled on a chart. (Source: W3C — Understanding SC 1.4.11 Non-text Contrast)
What the research says: 1.4.3 Contrast (Minimum) (Level AA): text needs a contrast ratio of at least 4.5:1, or 3:1 for large text. 2.4.7 Focus Visible (Level AA): keyboard focus must be visible. (Source: W3C — WCAG 2.2)
Dashboard accessibility checklist
- Status uses an icon or text as well as colour
- Chart lines, bars and segments reach 3:1 against neighbours, or values are labelled
- Text, including axis labels and table text, reaches 4.5:1
- Every chart has a text summary or an accessible data table
- Filters, tabs and chart controls work with a keyboard, with a visible focus state
- Live-updating figures don’t move focus or announce every tick to screen readers
- Layout works at 320 CSS pixels wide, except genuinely two-dimensional tables and charts
- Touch targets are at least 24 × 24 CSS pixels
Real SaaS dashboard examples and what to learn from them
The five examples below are described from each company’s public documentation, which we link so you can check the details. We have not reproduced product screenshots; the descriptions are limited to what the documentation states.
Stripe: a customisable home with comparison built in
Stripe’s Dashboard home lets users add, remove and organise chart widgets, choose a preset or custom date range, pick a time unit and set a comparison range (Stripe Support). The mobile app carries dashboard charts plus push notifications and metric widgets (Stripe Docs). Lesson: make the comparison period a first-class control rather than an afterthought.
Datadog: different layouts for different jobs
Datadog offers grid dashboards, Timeboards with automatic layouts tied to a single point in time, and free-form Screenboards. Template variables dynamically filter the widgets, and its documentation notes that publicly shared dashboards refresh every thirty seconds (Datadog Docs). Lesson: monitoring and storytelling need different layouts, and a shared time context keeps every widget comparable.
Linear: dashboards built from reusable insights
Linear’s Dashboards bring insights from across teams and projects onto a single page, with dashboard-level filters as well as per-insight filters. The documentation states they are available on Enterprise plans (Linear Docs). Lesson: build dashboards from components users already know from elsewhere in the product, and make filter scope explicit.
Plausible: one page, no sub-menus
Plausible deliberately gives users one dashboard with “the essential website stats”, with “no sub-menus and no need to build custom reports”. Users click a metric to show it in the main graph, click any report entry to filter the dashboard, and use a date picker to change the period (Plausible Docs). Lesson: a narrow scope, deliberately chosen, can be the whole design strategy.
Shopify: merchant-controlled metric cards
Shopify’s analytics overview lets merchants add, remove and rearrange metric cards, organise them into labelled sections and resize them, drawing on a card for each available report (Shopify Help Center). Lesson: personalisation built from a fixed set of known cards is easier to support than unlimited flexibility.
Common dashboard UX mistakes and how to fix them
Mistakes we see most often in SaaS dashboards
| Mistake | What goes wrong | Fix |
|---|---|---|
| Showing everything the data allows | No hierarchy; the important number is lost | Start from the question map; move the rest to reports |
| Numbers without comparison | Users can’t tell good from bad | Add change, comparison period and, where relevant, a target |
| Colour carrying meaning alone | Fails WCAG 1.4.1; misread by colour-blind users | Pair colour with icons, labels or patterns |
| Decorative chart types | Gauges, 3D and many-slice pies slow reading | Use bars, lines and bullet charts |
| Hidden filter state | Users act on filtered data without realising | Visible filter chips, URL state and a reset control |
| Zero instead of “no data” | A sync failure looks like a business problem | Distinct empty, error and stale states |
| No definitions | Teams argue about what a metric means | Definition, source and update time on every metric |
| Desktop layout squeezed onto mobile | Tiny charts and sideways scrolling | Choose the mobile job first, then the components |
Dashboard design checklist
Before you ship a dashboard
- Each role has three to five written questions the dashboard answers
- Every chart maps to one of those questions
- KPIs show value, unit, change, comparison period and a path to detail
- Chart types match the question (comparison, trend, share, target, distribution)
- Metric definitions and an “updated” time are visible
- Filter scope is clear, active filters are visible and shareable
- Loading, empty, no-results, error and stale states are designed
- Role defaults exist; personalisation has clear limits
- Mobile shows the mobile job, not a shrunken desktop
- Accessibility checklist above is complete
Dashboard UI design FAQs
What is dashboard UI design?
Dashboard UI design is the design of screens that summarise the most important information for a task so people can understand it at a glance. It covers what to show, in what order, which charts to use, and how users filter, drill down and act on what they see.
What is the difference between dashboard UI and UX design?
UI design covers the visible layer: layout, typography, colour, chart styling and components. UX design covers whether the dashboard answers the right questions for each role, how filters and drill-down behave, and how states such as loading and errors are handled. Good UI UX dashboard design treats both together.
How many KPIs should a dashboard show?
There is no research-backed fixed number. As a working rule, we start with three to five KPIs in the summary row because that fits a single scan on desktop, then justify each one against a question a user actually asks.
How do you design a dashboard for mobile?
Start from what people do on a phone — check a few numbers or respond to an alert — and design for that. Stack the top KPIs, show one simplified chart at a time, turn tables into lists, and move filters into a sheet. Make sure the layout works at 320 CSS pixels wide.
Should dashboards update in real time?
Only when the user’s decision depends on it, as with operational monitoring. Analytical dashboards are usually fine with hourly or daily data. In either case, show when the data was last updated.
Putting dashboard design into practice
Good dashboard user interface design is mostly a series of decisions made before visual design starts: which job the dashboard does, which questions each role asks, which metric answers each question and how it is defined. Get those right and layout, chart choice and states follow naturally. Get them wrong and no amount of polish will save the screen.
If you’re designing or redesigning a product dashboard, our UI design service covers dashboards and data interfaces as part of SaaS product work, and our product and digital design service covers the wider web app. For the product thinking behind it, see our guide to UX design principles every founder should know, and for how interface quality affects revenue, read why your product UI is your most powerful sales tool.
Designing a SaaS dashboard? See how DesignHQ’s UI design team approaches dashboards and data interfaces. Explore UI design services →
