Most SaaS dashboards are built by engineers who understand the data. They're rarely designed by people who understand what a first-time user sees when they log in for the first time, find nothing, and close the tab.
These twelve patterns address the full lifecycle of dashboard interaction — from the empty state a new user sees to the data-dense view a power user needs six months in.
The empty state is the screen users see when they first log in, before they've added any data. It's also the screen with the highest abandonment rate in most SaaS products.
A good empty state does three things:
Shows what the populated state looks like. Not a sad icon with "No data yet." A preview of what the dashboard will look like once they've added data. Users need to see the value they're working toward.
Provides exactly one action. "Connect your first integration" or "Create your first project." One action, one button. Not three options and a help article.
Explains why the state is empty. "Your analytics will appear here once you've installed the tracking snippet." Context prevents confusion about whether something is broken.
The empty state is onboarding. Treat it as such.
The most common dashboard mistake is showing everything at once. Every metric, every filter, every edge-case view on the default screen.
Progressive disclosure means: show the essential, reveal the detail on demand.
A practical implementation: a summary card shows the key metric. Clicking it expands to show the full breakdown, trend, and export options. Users who need the summary (most users, most of the time) get it instantly. Users who need depth get it one click deeper.
This has a measurable impact on activation. Users who see a simple, clear dashboard on day one activate at higher rates than users who see a complex one, even if the complex version technically has more value.
Overlays (modal tours, spotlight walkthroughs) are appropriate for features that aren't self-evident from the UI. If you need to explain how to use the navigation, the navigation is wrong. If you need to explain a non-obvious workflow, an overlay is appropriate.
Inline guidance (contextual tooltips, helper text directly in the UI) is better for persistent guidance that helps users of all experience levels. A "?" icon next to a complex metric definition is more useful than a one-time tour that 70% of users will click through without reading.
The failure mode: using overlays to compensate for unclear UI. If users consistently need the tour to understand the product, redesign the product rather than the tour.
A dashboard is not a spreadsheet. Not all metrics are equal. The visual hierarchy of your metric cards should reflect the business hierarchy of the metrics.
Primary metrics (the one or two numbers that define success) get the top position, largest size, and clearest visual weight. These are the numbers your users check every morning.
Secondary metrics (contributing factors, breakdowns of the primary) appear below, smaller, with less visual emphasis.
Tertiary metrics (diagnostic data, edge cases, admin numbers) belong in a detail view or a separate section, not on the main dashboard.
A common mistake: treating all metrics equally because the engineering team values all the underlying data equally. Users need hierarchy to know what to focus on.
Both are valid. The choice depends on what users need to do with the data.
Use tables when:
Use cards when:
Many dashboards use cards when they should use tables because cards look better in a Dribbble mockup. Cards at scale (50+ items) are slower to scan and harder to compare than tables.
Most SaaS dashboards are built desktop-first and mobile-last. The mobile version is an afterthought that collapses the desktop layout into a single column and calls it done.
A genuinely responsive dashboard redefines the mobile experience rather than scaling it down:
Mobile shows fewer metrics. The full desktop metric set is too dense for a 390px screen. The mobile view should show the three most important metrics by default, with a "view all" link.
Actions surface differently. Desktop: actions are in a row. Mobile: actions are in a bottom sheet or an expandable menu.
Tables become cards. A twelve-column table on desktop becomes an expandable card list on mobile. Each row becomes a card with the key attributes visible.
Charts use mobile-optimised formats. Line charts work on mobile. Complex multi-series charts don't. Adapt the format, not just the size.
The loading state is the experience your user has between clicking something and seeing the result. Most dashboards treat this as a technical necessity rather than a design opportunity.
Skeleton screens (placeholder shapes in the approximate size of the content that's loading) reduce perceived load time significantly compared to spinners. The user sees the structure appearing rather than waiting for nothing to happen.
Optimistic updates (updating the UI immediately with the expected state, then confirming from the server) make interactions feel instant. This is only appropriate when the action is very likely to succeed.
Progress indicators with context ("Fetching your last 90 days of data...") are better than spinners when the operation is genuinely long (>3 seconds). Users know why they're waiting.
Dashboards accumulate alerts. A product with no alert hierarchy makes everything look like an emergency — which means nothing does.
Four levels of alert, with distinct visual treatment:
Critical (red, persistent): something is broken and needs immediate attention. Use sparingly or it loses meaning.
Warning (amber, dismissable): something may need attention soon. Limit to two or three simultaneous warnings.
Info (blue, auto-dismissable): context that's useful but not actionable. Disappears after 5–7 seconds.
Success (green, auto-dismissable): confirmation that an action worked. Disappears after 3–5 seconds.
Never use red for anything that isn't actually critical. Once you train users that red appears for minor issues, critical alerts stop commanding attention.
Power users operate dashboards primarily through filters and search. Their experience degrades dramatically if these are slow, limited, or poorly designed.
Search should be universal and fast. One search input, sub-200ms response, matching across all relevant entities. Fuzzy matching (returning results even with typos) for any product with more than 100 items.
Filters should persist. If I filter to "last 30 days" and navigate to a sub-page and back, the filter should still be there. Filter persistence is the difference between a tool and a toy.
Filter state should be URL-encoded. Filtered views should be shareable. A team lead who wants to share a specific filtered view with their team shouldn't have to describe the filter configuration — they should paste a URL.
Most dashboards use too many chart types. This is a complexity problem that reduces comprehension.
The three chart types that solve 90% of dashboard visualisation needs:
Line chart — trends over time. The default for anything with a time dimension.
Bar chart — comparison across categories. Use when you're comparing several items to each other.
Donut/pie chart — part-to-whole relationships. Use only when the proportional relationship is the story. Never for more than five segments.
Everything else (area charts, scatter plots, heat maps, funnel charts) is a specialisation that belongs in a specific analytics section, not the main dashboard. When in doubt, choose the simpler format.
Export is often treated as an afterthought and is one of the most-requested features by every team that buys a SaaS tool for business use.
Every table should export to CSV. Every chart should export as an image (PNG) or the underlying data (CSV/JSON). Every filtered view should export in its current filtered state.
This is not technically complex. It signals to enterprise buyers that you take their data seriously, reduces "we can't use this for reporting" objections, and increases the switching cost of your product over time.
Good dashboards decay. Features are added, metrics proliferate, and the dashboard gradually becomes a graveyard of data nobody looks at.
A quarterly dashboard audit asks three questions:
What does no one look at? Use analytics on your own product. Which cards, charts, and tables have zero interaction over the last 30 days? Remove them.
What do people search for that they can't find? Your own search logs are a product roadmap. If people are searching for something that doesn't exist in the dashboard, add it.
What do support tickets reference? If users are filing tickets about the same confusing behaviour, the dashboard is failing them.
Simplicity is not a design trend — it's a maintenance commitment. The dashboards that retain users are the ones that continuously remove what doesn't serve them.
Building a SaaS dashboard and want a second opinion on the design decisions? Start a conversation — we review dashboard UX and tell you what's costing you activation.
We take on a small number of projects each quarter. Tell us what you're building.
Ten marketing sites with real Lighthouse scores, Core Web Vitals data, and a breakdown of exactly what each one does right — from above the fold to footer trust signals.
Most SaaS landing pages fail for the same five reasons. Here's the anatomy of one that converts — above the fold, social proof placement, CTA copy, and load speed as a conversion lever.