SaaS dashboard design: start with what people will do next

By Shoghi Bagul · Published 23 October 2026 · Updated 27 October 2026 · 10 min read

Good SaaS dashboard design starts with one question for each view: when this number moves, what should someone do? Decide that action first, then give every number a comparison, a definition, a sign of how fresh it is and a route to the records behind it.

Many dashboards skip that first step. The metrics the data can supply become cards on a home screen, people look at it for a few weeks, and then it becomes the screen they export from. This guide covers the action behind each view, readable numbers, uncertainty, alerts, admin queues and four product patterns worth copying.

Key takeaways

• Write down the action each view should prompt before choosing a chart. A view with no action is an awareness screen, and it should be designed as one.
• A number alone means little. Give it a comparison, a baseline that does not exaggerate, and a sign of how fresh and how certain it is.
• An alert asks for someone's attention. Send it only when someone can act, to the person who can act, with a link to the records behind it.
• An admin dashboard is a work queue: what needs attention, in what order, with the action available in place and a rule for how items leave.
• Judge a dashboard by what people do after opening it, and start measuring that with the first release.

What should a SaaS dashboard help someone do?

A SaaS dashboard should help one named person take one kind of action, or say plainly that it exists for awareness. When Alper Sarikaya and colleagues studied 83 dashboards and the research on their use, they found the purpose had grown well beyond operational monitoring. Some dashboards, in the researchers' words, "may not even support decision-making at all", and exist for awareness, communication or learning.

So decide which job each view does before anyone draws a chart. Write one sentence for the view: "When this measure moves, this person will do this." If the sentence comes easily, you are designing an action screen, and the action belongs next to the number. If nobody can finish it, the view is for awareness, so make it quick to read and easy to share. If it needs ten measures, it is an analysis screen, and it needs filters and room to explore.

The last row deserves particular attention. In a SaaS product, the customer value view is where your customer decides whether the subscription is worth renewing.

What does a number on a dashboard need beside it?

A number on a dashboard needs a comparison, an honest axis and a definition before anyone can act on it. "Revenue this month" on its own invites a shrug: up or down, against what? Choose the reference this person uses to judge the figure, such as the previous period, a target or a forecast, and show both the change and the reference value.

Axes are design choices with consequences. Michael Correll, Enrico Bertini and Steven Franconeri found that bar charts whose axis does not start at zero exaggerate the size of a change. The effect held across the chart types they tested, line charts included, even when the chart visibly marked the cut. Start bars at zero. Zoom a line chart only when a small change is what the decision turns on, knowing the axis label will not undo the exaggeration.

Every measure also needs a definition one click away: what is counted, what is left out, which time zone, and when it was calculated. When two teams find two figures for one metric, they stop trusting both.

Status colours need a second signal. The accessibility standard says colour must never be the only visual means of conveying information (WCAG success criterion 1.4.1). Pair red and green with an arrow, a sign or a word.

How should a dashboard show uncertainty and stale data?

A dashboard should show estimates as ranges and say how fresh each figure is, because forecasts, attributed revenue, health scores and today's partial figures all carry a margin. Showing them as exact invites decisions they cannot support.

Leaving uncertainty out is the norm. Jessica Hullman surveyed 90 visualisation authors and interviewed 13 influential designers, and found a clear contradiction: authors saw the value of showing uncertainty, yet routinely left it out. It can be shown in forms people read well. Matthew Kay and colleagues showed bus arrival predictions as a quantile dotplot, a small set of possible outcomes, and people's probability estimates were more consistent than with density plots.

A follow-up by Michael Fernandes and colleagues measured decisions, not just readings. People choosing when to leave for a bus made better and more consistent decisions with dotplots than with no uncertainty shown. Uncertainty stated as text did less well than the drawn displays.

Four practical rules follow:

• Mark incomplete periods. Today's bar is partial, so draw it differently and say so in the label.
• Show freshness next to the figure. State when the data last updated, and show a clear state when a source fails to load.
• Draw ranges for estimates. Keep a range in words for places where no chart will fit.
• Separate missing from zero. A blank is unknown, and a zero is a fact. A new account's empty dashboard should say what will appear there and what fills it.

How should dashboard alerts reach the right person?

A dashboard alert should reach only the person who can act on it, name the action and open the records behind it. Google's site reliability engineers set a standard for paging engineers that suits product alerts too: "Every page should be actionable". Their questions ask whether a rule catches something urgent that would otherwise go unnoticed, whether anyone can act, and whether others are already alerted.

Applied to the alerts your customers receive, those questions give five design rules:

• Route to the person who can act. That is usually the owner of the record or account. Everyone else can see the alert without being interrupted.
• Name the action and link to the records. The alert opens the affected items with the filters already applied.
• Send one alert per situation. Group repeats and update the alert as things change. Let people snooze it, and bring it back if the situation gets worse.
• Choose the channel by urgency. Show alerts in the product first, and use email or chat only for urgent items.
• Let customers set thresholds. Defaults come from your data; each customer tunes them against their own normal.

Measure the alerts themselves: how many are opened, acted on and muted. An alert most people mute is noise, and it should be retired or redesigned.

How is an admin dashboard different from a reporting dashboard?

An admin dashboard is a work queue, while a reporting dashboard explains a period. An administrator who opens the product many times a day wants the list of things waiting for them, so design the screen closer to an inbox than a report.

Items that need attention come first, ordered by urgency or by how long they have waited, each with an owner and the action in place: approve, reassign, fix or dismiss. The counts at the top work as filters, so selecting the count of items awaiting approval opens exactly those items. Routine items get bulk actions, with a summary of what will change before anyone confirms.

Two smaller details make a queue trustworthy. Show what was recently resolved, and by whom, so an admin can check a colleague's work. And when the queue is empty, say so plainly: "Nothing is waiting for you."

Which product patterns are worth copying?

Four software products document dashboard behaviour that solves problems raised above: how parked items return, which direction is good, what a metric excludes and whose problem a row is. Each is described from the vendor's own documentation.

Sentry: a parked item comes back if it gets worse. In Sentry's issue list, archiving moves an issue out of the stream and pauses its alerts. The default is to archive until escalating, and Sentry returns the issue to the top of the list when its events rise sharply. That re-entry rule is what makes snoozing safe: people can clear the queue without losing sight of what they cleared.

Tableau Pulse: the direction of good is part of the definition. When someone defines a metric in Pulse, they state whether a rise is neutral, favourable or unfavourable, and set definition filters that viewers cannot change. Decide those before drawing anything. Without them, neither a colour nor a written summary can tell good news from bad.

GitHub: definitions include their exclusions. GitHub publishes how each security overview metric is calculated. Mean time to remediate leaves out alerts closed as false positives, and a reopened alert is aged from its original creation date. The same page warns that figures for one period can differ when viewed at two different times. Saying so in advance keeps a moving number trusted.

Google Search Console: each row says whose problem it is. The page indexing report lists each reason pages are not indexed with a source, and Google says you can generally fix only the reasons whose source is your website. After a fix, a Validate fix button closes the loop; Google says validation typically takes up to about two weeks.

A dashboard we designed: ConnectX's energy workspace

Writing each view around its next action is what made an adaptive dashboard specific enough to build and test. In ConnectX's building-energy product, facility, finance and sustainability teams ask different things of one system. One dashboard for all three would bury each team's answer, and a fixed dashboard per team would break when a situation involved more than one.

With ConnectX we defined eight representative scenarios. Each specified the request and the intent behind it, the data and modules required, how the digital twin behaves and the next action. Conversation establishes what someone wants to understand, and the product assembles a workspace around it that stays open for comparing and acting. The result is a working demonstration on an interim data layer, built to keep a path open to ConnectX's eventual APIs. Read the ConnectX case.

For a project on one dashboard, see how we design a dashboard around each role's questions. For analytics products as a whole, see how analytics products get customers to act on what they show.

Questions about SaaS dashboard design

What is the difference between a dashboard and a report?

A dashboard is opened repeatedly to see the current state and act on it. A report answers a question about a period, and is often read once and shared. Many SaaS products need both, so design them as separate views with different defaults.

How many metrics should a SaaS dashboard show?

As many as the actions it supports, and no more. Start with the sentence test above. A measure that changes nobody's next step can move to a report, where people who need it can still find it.

Should customers be able to build their own dashboards?

Let them save views, choose filters and pick from a set of well-defined measures. In our experience, full freedom to define new metrics produces figures that disagree, so keep definitions shared and let the layout vary.

Should an AI assistant replace the dashboard?

A question in plain words is a good way to start a piece of work, but people still need a stable place to compare figures and act. The stronger design uses conversation to open the right view and keeps that view on screen. Our article on whether an AI product should replace its dashboard with chat covers the handover in full.

How do you know whether a dashboard works?

Track what people do after opening it: how often a view leads to an action, an alert to a fix, or a filter to the records underneath. Track exports to spreadsheets too. If most visits end in an export, the analysis is happening somewhere else.

What should a new account see before there is any data?

Show the shape of what will appear, in a quiet preview, and the one or two steps that will fill it. Avoid sample figures that look real. A first view that explains itself is better than a page of zeros.