Dashboard Design Best Practices: 8 Real Examples

An editorial collage of real interfaces. Explore the full examples and sources below.

A useful dashboard helps someone answer a question and decide what to check next. Its numbers need a population, a time window and a clear meaning.

Study eight real interfaces—from Stripe’s financial overview to PostHog’s funnel—then apply the patterns to the worked SaaS example. You can copy the dashboard design brief to turn those choices into requirements for your own screen.

Images are public-demo captures or official product illustrations, checked October 16, 2026. Select any screenshot to inspect it full size. These are design references, not a software ranking.

Plausible: a focused traffic overview

What changed, and where should I look next?

Plausible puts six headline metrics above one large trend, with sources and top pages below. The site, date range and filter sit together above the analysis. The hierarchy gives the reader a useful sequence: scan the totals, locate a change, then investigate a breakdown.

Plausible’s documentation confirms that selecting a metric changes the graph and report entries filter the dashboard. The limit is the business question: a traffic increase alone does not establish more qualified leads.

Stripe: make the comparison explicit

Am I looking at sales, cash available, or a payout?

Stripe separates today’s activity from its configurable overview. The overview exposes date range, display interval and comparison period; cards name the measure, show a previous-period value, and provide update times and detail links. Gross volume, net volume from sales, balance and payouts are separate measures.

The distinction matters when a large number looks reassuring. Stripe describes Home charts as estimates, including estimated exchange rates, and excludes off-Stripe processed payments from Home gross volume. Detailed reports are the appropriate route for reconciliation.

PostHog: expose the funnel denominator

Which step deserves the next investigation?

PostHog’s example makes the funnel inspectable: View Product → Add to cart → Checkout, with 292 → 263 → 91 people. The final 31.16% uses the first step as its denominator; the 65.4% checkout drop uses the preceding step. Those percentages answer different questions.

Its companion setup exposes unique users, sequential order and a 14-day conversion window. Those settings define the measure. A dense funnel can still overwhelm a quick status check, so choose which rate belongs in the overview.

Linear: combine questions around one job

Which bugs need attention, and what is slowing the work?

Linear’s example combines an open-bug count, a lead-time distribution and a last-cycle status breakdown. Each panel answers a different operational question. The distribution preserves long delays that one headline total would hide.

Filter scope needs equal care. Linear documents dashboard filters applying alongside each imported Insight’s own filters, so a familiar chart can show a different population. Insights is available on Business and Enterprise; combined Dashboards require Enterprise.

Umami: give changes the right meaning

Does a lower number mean the same thing for every metric?

Umami separates visitors, visits and views instead of collapsing them into “traffic”. In this capture, falling visitors are red while a lower bounce rate is green. Direction and interpretation are different pieces of information; the metric’s label gives both a meaning.

Even a sensible default needs context. Longer visits can suggest engagement or confusion, depending on what the visitor came to do. A founder should not have to infer success from color alone.

Vercel: pair the signal with a route to investigate

Is a traffic change accompanied by more failures?

Vercel places invocation volume beside error and timeout rates, then follows with route-level detail and P75 duration. A busier system and a higher failure rate are different signals. The table narrows the next investigation instead of leaving the reader at a red line.

Units and access matter here. One request can generate several infrastructure events, so the counts are not unique visitors. Basic Observability is available on all plans; latency and path breakdown require Observability Plus.

Grafana: connect signals, then check the units

Do response time, traffic and errors move together?

Grafana’s Four Golden Signals demo puts latency, traffic, errors and saturation in one grid with a shared time range. It supports a focused investigation: did responses slow down when load or errors changed? It does not establish why.

This real reference also gives us a unit check. The captured saturation panel displays multi-billion percentage values, while its series name includes system_memory_usage_bytes. That combination warrants checking the query, aggregation and display unit. It does not establish a platform defect. Long infrastructure legends also need decoding before they belong in a founder overview.

Metabase: give a chart a useful next screen

Which underlying accounts explain this part of the chart?

Metabase attaches actions to a selected chart value: inspect the underlying accounts, use a smaller time interval, break out the data or apply a filter. The useful design choice is continuity between an overview and the next question.

The interaction depends on the data and permissions. Metabase requires query-building access; query-builder questions support query-rewriting actions, while native SQL has a smaller set of result-based actions. Public and guest embeds do not support drill-through.

Now turn a reference into your own screen. Use one reader, one decision and one precisely defined measure.

Start with one reader and one decision

A dashboard helps someone monitor a situation, investigate a change or decide what to do next. Choose the layout for that job.

Microsoft’s dashboard guidance starts with the audience and the decisions its metrics support. For a SaaS founder, make that concrete before adding a card:

A phone used for a quick check needs a different level of detail from a large screen used in a team review. Keep the decision visible in both; move supporting records into a clearly named detail view when the overview does not need them.

Define the metric before drawing the card

“Activation: 30%” is incomplete. The reader needs to know what counted as activation, which accounts were eligible and whether the comparison uses the same observation window.

GOV.UK’s completion-rate guidance is useful for its explicit numerator and denominator. Apply the same discipline here: a rate needs a defined completed action and eligible population. A count of events is not automatically a count of distinct accounts.

Show enough precision for the task. A compact overview can display “30%”; a review of individual transactions may need exact amounts. Do not round away a difference that changes the decision. If you need help choosing the underlying measures, use the product metrics guide before expanding the dashboard.

Dashboard example: same data, clearer context

The two layouts below use the same example figures. The first makes the reader reconstruct the question and context. The revised layout puts the cohort, denominator, comparison and segment to investigate beside the headline measure.

The calculation: 18 ÷ 60 = 30%; the previous cohort was 24 ÷ 60 = 40%. That is a decrease of 10 percentage points. It is not a decrease of 10 percent: relative to 40%, the change is −25%. Label the comparison you actually mean.

The self-serve path accounts for this decline. Check source records, account mix and the setup journey before deciding why it changed. These are synthetic data and proposed layouts, not a measured design improvement.

Choose a chart for the comparison

Choose the relationship first, then the chart. The ONS chart-selection guidance recommends simple, familiar charts that communicate the relevant relationship.

There is no need to ban every pie or area chart. Use the form that makes this comparison understandable, and check it with the intended reader. A visually elaborate chart does not earn its space merely by looking impressive.

Make the layout and labels work together

Give the decision-driving measure the strongest hierarchy. Place its definition, period and comparison nearby; group related measures and keep their scales consistent where they are meant to be compared. Do not assume one fixed “top-left” placement works for every language, device and task.

A label such as “Saved first report within 7 days” tells the reader more than “Engagement”. Keep the source, units and population visible rather than hiding all context in hover text. The ONS chart-text guidance explains the role of titles, units, dates and sources.

On a narrow screen, preserve a reading order: question, headline measure, comparison, segment and next investigation. Let a wide record table scroll within its own region rather than pushing the whole page sideways. Keep essential labels readable without zooming into an image.

Make the information accessible

Use a visible label or another cue alongside color. “Self-serve: 15%” must remain understandable without recognizing a red mark. Provide equivalent text or a usable data view for a chart, and make filters and details work with a keyboard.

WCAG 2.2 sets an AA minimum of 4.5:1 for normal text and 3:1 for large text, with specified exceptions. Required graphical information and control states have a separate 3:1 non-text contrast criterion. Check the actual colors and states; this short design checklist is not a complete accessibility audit.

Design loading, empty and error states

A dashboard needs to explain the absence of a number as carefully as the number itself. Carbon’s empty-state guidance distinguishes first use, user actions and failures; its loading guidance treats work in progress separately.

These messages are illustrative: use only the explanation your system can verify. If the issue is getting a new user to their first useful result, the SaaS onboarding guide covers that wider journey.

Use AI summaries with visible context

An AI summary should describe the same population, filters and time window as the visible evidence. Separate the numbers shown from hypotheses about their cause. In our example, a lower self-serve rate supports investigating that path; it does not establish that a design change caused the decline.

For a documented product example, Power BI’s Copilot narrative visual summarizes report-canvas content rather than the underlying semantic model. Microsoft says it does not automatically refresh after filters or data change. Creating it in the service requires write permission, enabled Copilot, suitable region and tenant settings, and paid dedicated Fabric capacity; trial capacity is not supported.

Check the narrative against the referenced visuals after changing the view. This workflow does not require Power BI or an AI subscription, and we have not tested that feature’s output in an authenticated account.

Check the screen with a real task

Give an intended reader a question they actually need to answer. For this example: “Which onboarding path needs investigation, how does it compare with the previous cohort, and what would you check next?” Ask them to use the screen rather than explain its design back to you.

Record what happened: whether they found the right population and comparison, any incorrect interpretation, the source record they tried to open and where they needed help. If they choose the right segment for the wrong reason, the task is not resolved. Test the loading, empty, error and keyboard paths too.

Use those observations to revise the screen. Do not turn a colleague saying “looks good” into a usability result, or a before-and-after mockup into evidence of increased conversion. We have not run this example with participants.

Copy the dashboard design brief

Create a project document named “Dashboard decision brief”. Paste the outline below into it and replace the brackets with your actual definitions. Then sketch one screen against that brief. Pasting the text does not build a dashboard or connect a data source.

Reader and situation: [who uses this, and when]
Decision: [the question this screen must help answer]
Next investigation or action: [what follows the answer]

Metric: [name and event definition]
Unit: [account, person, transaction, or another unit]
Eligible population: [who counts; deduplication and exclusions]
Observation window: [start, end, timezone, and incomplete windows]
Comparison: [same definition and a comparable period or cohort]
Filters: [what changes the population]
Source and freshness: [system, refresh time, and stale-data rule]

Overview: [the few measures needed for this decision]
Detail: [which source records the reader can inspect]
States: [loading, no data, no matches, failure, permissions]
Accessibility: [labels, contrast, data alternative, keyboard path]
Task check: [one real question; what to observe]

Expected result: another person can tell you what the dashboard measures, who is included, which comparison it supports and what to investigate next. If a field is unknown, resolve it before styling more cards.

Choose tools after the brief

If you start with a dashboard UI kit, check its components against your metric, states and mobile needs. A polished kit does not supply those definitions. For subscription-billing analytics rather than a custom product dashboard, the Baremetrics review covers data fit and limitations. Keep tool selection tied to the actual job.