How to Design a SaaS Dashboard That Helps Users Take Action, Not Just View Data
Design an in-product SaaS dashboard around user decisions: a 12-point scorecard, empty and error states, accessible charts and when not to build one at all.
What makes a SaaS dashboard actionable?
An actionable dashboard is built around the decisions a specific user makes repeatedly. Each item shows a number in context (a target, a threshold or the previous period), makes exceptions stand out without relying on colour alone, and puts the next step one click away. If a tile cannot answer "so what do I do now?", it belongs in a report, not on the dashboard.
Most dashboards that get glanced at and closed fail for one of three reasons. They were designed to show everything the product records rather than what one person needs. They show numbers without saying whether those numbers are good or bad. Or they stop at the number, so the user has to go elsewhere to act on it.
This guide is for SaaS founders, product managers and designers building a customer-facing dashboard for a first version or a redesign. It covers in-product dashboards that your customers use, not your own internal analytics. For the wider product design picture, see our SaaS product design guide.
Key takeaways
- Name the user, the job and how often they visit before choosing a single chart.
- Decide whether each dashboard is operational (act now) or analytical (understand and plan).
- Give every metric context: a target, threshold or comparison period.
- Put the next action next to the exception, not on another screen.
- Design the empty, loading, partial and error states, not only the full one.
- Prefer charts based on position and length; never use colour as the only signal.
- Judge success by actions taken from the dashboard, not by page views.
Start with what a dashboard is for
Stephen Few's widely cited definition is still the most useful starting point: a dashboard is "a visual display of the most important information needed to achieve one or more objectives; consolidated and arranged on a single screen so the information can be monitored at a glance". In the same 2004 article he notes that a dashboard tells you what is happening but not why, and that it can be the starting point for drilling into the detail (Few, Dashboard Confusion).
Two parts of that definition do most of the work. "Most important information" means you have to leave things out. "Objectives" means the dashboard exists to serve a goal the user has, not to prove how much data the product holds.
NN/g separates two kinds of dashboard. Operational dashboards "impart critical information quickly to users as they are engaged in time-sensitive tasks". Analytical dashboards give at-a-glance information "used for analysis and decision making" (NN/g, Laubheimer, 2017). Mixing both on one screen is a common reason a dashboard feels busy and useless at the same time.
Map users, jobs and cadence first
Before any wireframe, write down who opens the dashboard, what they are trying to get done and how often. The table below is a template; replace the example rows with your own roles.
| Role | Job on this screen | Visit cadence | Dashboard type | What a good visit ends with |
|---|---|---|---|---|
| Account owner | Check the account is healthy and nothing needs approval | Weekly | Analytical, light | Approved items, or a decision to look deeper |
| Day-to-day operator | Clear today's exceptions | Several times a day | Operational | Exceptions resolved or assigned |
| Team lead | Spot who or what is falling behind | Daily | Operational with trends | A reassigned task or a message sent |
| Finance or admin | Confirm usage and billing | Monthly | Often not a dashboard: a report or email | A downloaded statement |
Pro tip
For every proposed tile, ask: "If this number doubled or halved, what would this user do differently?" If nobody can answer, drop the tile or move it to a report.
The Dashboard Action Scorecard
Use this scorecard to assess an existing dashboard or a design before it is built. Score each criterion 0 (missing), 1 (partly there) or 2 (clearly met), and write down the evidence for the score: a screenshot, a user quote or an analytics figure. Scoring as a group of three or four people (product, design, engineering, someone who talks to customers) tends to surface disagreements that are worth having.
| # | Criterion | Scores 2 when… | Evidence to collect |
|---|---|---|---|
| 1 | Named user and job | The dashboard has a written primary role and job, and every widget maps to a decision that role makes | A one-line purpose per widget |
| 2 | Clear type per role | Each role's default view is either operational or analytical, not a mix | Role list with default view |
| 3 | Context on every metric | Each number shows a target, threshold or comparison period | Count of bare numbers |
| 4 | Exceptions stand out | Items needing attention are visible at a glance, using position, size, icons or text as well as colour | Greyscale screenshot test |
| 5 | Next action within one click | Every exception has a button or link to the place where it is resolved | Click path from tile to action |
| 6 | Drill-down to the records | Users can see the list of records behind any number | Test three numbers |
| 7 | Designed states | Empty, first-run, loading, partial-data and error states are designed and tested | Screenshots of each state |
| 8 | Role-based defaults | Each role lands on a view that suits its job without configuring anything | First login per role |
| 9 | Readable charts | Charts rely on position and length; no 3D; any pie chart has few slices with labelled values | Chart inventory |
| 10 | Accessible | Meets WCAG 1.4.1 and 1.4.11; filters work by keyboard; figures available as text or table | Keyboard and contrast check |
| 11 | Freshness and definitions | Users can see when data last updated and what each metric means | Hover or info text per metric |
| 12 | Instrumented for action | You track clicks into actions, alert-to-resolution time and return visits | Event list in analytics |
Reading your score
The maximum is 24. Treat the bands below as a rough guide for prioritising work, not a benchmark: they are ZSpace Labs' suggested thresholds, not industry data.
0 to 10: the dashboard is probably decorative. Go back to the user and job mapping before changing any visuals. 11 to 18: the foundations are there; fix the lowest-scoring criteria first, usually context (3), next action (5) and states (7). 19 to 24: focus on instrumentation and on testing with real users, because the remaining problems will not show up in a scorecard.
Any 0 on criteria 1, 5 or 10 is worth fixing regardless of the total. Without a named job the rest is guesswork; without a next action the dashboard cannot drive action; and accessibility failures can lock some users out entirely.
Worth noting
The scorecard tells you where a design is weak. It does not tell you whether users succeed with it. Pair it with a short round of task-based testing, as described in our guide to how much UX work to do before development.
Design every state, not just the full one
Design reviews usually show a dashboard full of tidy, realistic data. Real accounts spend a lot of time in other states, and a new customer's first view is almost always the empty one. NN/g recommends using empty states to communicate system status, to provide learning cues and to give direct pathways for key tasks (NN/g, Kaplan, 2021).
| State | What goes wrong | What to design |
|---|---|---|
| First run (new account) | A grid of zeros and empty axes | Explain what will appear, show the one or two setup steps that make it appear, optionally show clearly labelled sample data |
| Empty (no data in range) | Looks identical to a broken chart | Say why it is empty ("No orders in the last 7 days") and offer to widen the range |
| Loading | Layout jumps as tiles arrive | Reserve space with skeletons; load the most important tile first |
| Partial data | Totals look wrong because a source has not synced | Mark affected tiles and show the last successful sync time |
| Error | Generic "Something went wrong" | Say which tile failed, whether other numbers are affected and what the user can do |
| Permission-limited | Blank tiles with no explanation | Hide tiles the role cannot use, or say who can grant access |
Pro tip
The first-run state is part of onboarding. If the dashboard is where new users land, design it alongside your activation steps; see SaaS onboarding optimisation.
Choose charts people can read quickly and accurately
Research on graphical perception, starting with Cleveland and McGill's 1984 paper in the Journal of the American Statistical Association, found that people judge values more accurately from position along a common scale and from length than from angle, area or shading. NN/g's dashboard guidance applies the same idea: use "length and 2D position" to communicate quantities, avoid colour for magnitude, avoid pie and donut charts most of the time, and avoid 3D, which makes charts harder to read.
- Comparing categories: a sorted bar chart.
- Change over time: a line chart with the target or prior period shown as a reference line.
- Progress to a goal: a bar against a target marker, not a gauge.
- Single number: the number, the comparison and a short label saying whether that is good or bad.
- Many items needing attention: a ranked list or table with status text, not a chart.
- Do not use 3D effects, dual axes that invite false comparisons, or colour shading to encode amounts.
Make charts accessible
Two WCAG 2.2 success criteria catch most dashboard problems. 1.4.1 Use of Color (Level A) says colour must not be "the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element" (W3C, Understanding SC 1.4.1). A red tile for "overdue" therefore also needs an icon, a label or a pattern.
1.4.11 Non-text Contrast (Level AA) asks for a contrast ratio of at least 3:1 against adjacent colours for user interface components and for parts of graphics required to understand the content. W3C's guidance applies this to chart lines and to pie segments that are distinguished only by their edges, and notes that labels and values can remove the need (W3C, Understanding SC 1.4.11). Text inside charts follows the normal text contrast rule.
Beyond those two: make date pickers and filters usable by keyboard, give each chart a text summary or a data table, and do not rely on hover tooltips as the only way to read a value. For a wider pre-launch check, see our website accessibility guide. A shared component library helps keep these rules consistent across screens; our piece on design systems for teams that move fast covers how to set one up.
Hypothetical example: a scheduling product's home screen
This example is hypothetical. A B2B scheduling SaaS shows clinic managers six tiles: total bookings, revenue, a donut of appointment types, staff utilisation, a map of locations and a bookings-over-time chart. The team scores it 9 out of 24. No tile has a target, the donut has eleven slices, nothing links to an action, and new accounts see six empty charts.
The redesign keeps two analytical tiles (bookings against last month, and utilisation against a target the clinic sets) and adds an operational "Needs attention" list at the top: unconfirmed appointments for tomorrow, staff with no availability next week and failed reminder messages. Each item has a single button (Confirm, Ask staff to update, Resend). The donut becomes a sorted bar chart in a report. New accounts see a short checklist to add staff and connect a calendar, with a sample view labelled as sample data. The team re-scores it at 19 and, more importantly, starts tracking how many attention items are resolved from the dashboard each week.
How to tell whether the dashboard drives action
Page views tell you a dashboard was opened, not that it was useful. Measure what happens next. The measures below are ZSpace Labs' recommendation rather than a published standard.
- Action click-through: the share of dashboard visits that include a click into an action the dashboard points to.
- Alert to resolution: the time from an exception appearing to it being cleared.
- Return cadence: whether each role returns about as often as you designed for (daily for operators, weekly for owners).
- Drill-down use: which numbers people investigate, a hint about what is missing from the surface.
- Dead tiles: widgets nobody interacts with over a set period, which are candidates for removal.
When not to build a dashboard
A dashboard is not always the right answer, and it is worth saying so in planning before weeks go into charts.
- The user needs to know one thing at one moment. A notification or email is better than a screen they have to remember to open.
- The user visits monthly or less. A scheduled summary, digest or downloadable report usually serves them better.
- There is one obvious next task. Land the user on that task or a to-do list, not on charts about it.
- You have little data yet. In an early product or a new account, a dashboard mostly shows emptiness. Ship the core workflow first.
- The real need is ad hoc analysis. Power users exploring data are better served by exports, a report builder or an integration with the BI tool they already use.
- It is mainly for sales demos. A dashboard built to impress in a demo rarely helps the person who logs in every day.
Worth noting
For a vertical example of a customer-facing dashboard that puts tasks before charts, see how to design a marketplace seller dashboard. For a store team's internal analytics, which is a different job, see ecommerce dashboard design.
Common mistakes
- Starting from the data model ("what can we show?") instead of the user's decisions.
- One dashboard for every role, so nobody's job is served well.
- Numbers with no target or comparison, so users cannot tell good from bad.
- Red and green as the only status signal.
- Exceptions that require navigating elsewhere to fix.
- Never designing the empty, loading and error states.
- Hiding when data was last updated, so users stop trusting the numbers.
- Measuring success by dashboard views.
Conclusion and next steps
Start with the people and the jobs, choose an operational or analytical purpose for each view, and give every number context and a next action. Then design the states real accounts actually see, check charts against WCAG 1.4.1 and 1.4.11, and measure what users do after looking. If you already have a dashboard, run the scorecard this week with three or four colleagues, fix the lowest-scoring criteria first and test the result with a handful of real users. If UI/UX design support would help with the redesign, that is the kind of work we do.
Want a second opinion on your dashboard?
ZSpace Labs is a remote-first technology studio that works with clients globally on UI/UX design and web application development. If useful, we can talk through your dashboard against the scorecard above and what to change first.
Sources
Dashboard definition and types: Stephen Few, Dashboard Confusion (Intelligent Enterprise, March 2004); NN/g, Dashboards: Making Charts and Graphs Easier to Understand (Laubheimer, 2017); NN/g, Designing Empty States in Complex Applications (Kaplan, 2021).
Perception research: Cleveland and McGill, Graphical Perception, Journal of the American Statistical Association 79(387), 1984 (cited at a high level).
Accessibility: W3C, Understanding SC 1.4.1 Use of Color; W3C, Understanding SC 1.4.11 Non-text Contrast.
Accessed 14 October 2026.
Common questions.
An operational dashboard supports time-sensitive work: it shows what needs attention now and lets the user act on it. An analytical dashboard supports slower analysis and planning, so it can carry more history, comparison and filtering. NN/g draws the same distinction. Many SaaS products need one of each, for different roles, rather than one screen trying to do both.