The dashboard is the first thing your user sees after they log in. It's also usually the worst-designed screen in most SaaS products — a graveyard of widgets nobody uses, charts nobody understands, and metrics that don't drive action.
Here's how I approach dashboard design when the goal is actually to move the user forward.
The fundamental tension
Dashboards fail because of a tension between two different stakeholder needs:
Business stakeholders want visibility. They want to know that the product is doing things, that data is moving, that the system is alive. More widgets = more confidence.
Users want clarity. They want to open the dashboard and immediately know: what do I need to do right now?
These goals are in direct conflict. The product team needs to choose one to optimize for, and the right choice is almost always the user.
Start with the action, not the metric
Most dashboards are organized around data: here's your revenue, here's your usage, here's your team activity. A better organizing principle is action: what should the user do next?
The dashboard for a project management tool shouldn't lead with "you have 47 open tasks." It should lead with "3 tasks are due today, 2 are blocked waiting on you." The first is a report. The second is a prompt.
Concretely, this means every section of your dashboard should pass this test: if the user acts on what they see here, does a meaningful outcome improve?
If the answer is no, the section is decoration. Cut it.
Widget hierarchy
When I'm laying out a dashboard, I think in three tiers:
Tier 1 — Primary action surface. One or two widgets that tell the user exactly what to do right now. High information density is fine here because the user is already engaged.
Tier 2 — Status overview. Supporting context that helps the user understand why they need to take the tier-1 actions. Usually a summary stat or a recent activity feed.
Tier 3 — Deep links. Quick navigation to the sections of the product they'll actually use. Not charts. Not breakdowns. Just links with enough context to be useful.
Most dashboards have the ratio inverted: they lead with tier-2 content (status), bury tier-1 content (actions), and skip tier-3 entirely.
Progressive disclosure
A common mistake is trying to show everything on load. Instead, design for progressive disclosure:
Load → Show skeleton → Populate primary widgets →
Background-load secondary data → Fill in details
This keeps the dashboard feeling fast even when some data is slow. Users perceive speed based on time-to-first-meaningful-content, not time-to-full-load.
From a React perspective, this means structuring your data fetching so primary widgets don't wait for secondary data:
// Primary content loads immediately
const { data: actionItems } = useSWR("/api/action-items");
// Secondary content loads in background, doesn't block render
const { data: analytics } = useSWR("/api/analytics", { suspense: false });Empty states are product moments
Most dashboards treat the empty state as an edge case. It's actually one of the highest-leverage screens in the product.
A new user who sees a well-designed empty state understands exactly what the product does and exactly what to do first. A new user who sees a bunch of empty charts and "No data yet" messages bounces.
I design empty states before I design the populated state. If I can't write a clear, action-oriented empty state, it's a sign the section itself isn't clear enough.
Personalization beats customization
"Let users customize their dashboard" sounds like a good idea. In practice, nobody does it. The drag-and-drop widget editor that took three sprints to build gets used by 2% of users.
Personalization — where the product adapts automatically based on how the user actually works — is far more effective. Show the widgets most relevant to what the user does most. Surface the data from the teams they interact with most. Highlight the actions in the categories where they're most active.
This requires good analytics and some modeling, but it's achievable incrementally. Start by just tracking which widgets users click most and promoting those.
The best dashboards I've seen don't feel like dashboards. They feel like a well-briefed colleague handing you a concise morning update: here's what matters, here's why, here's what you should do about it.