Start with the user's question
Most weak dashboards have the same cause. Someone asked, "what data do we have?" and put all of it on one page. The better question is: what does the user want to know when they open this?
Think about who opens the dashboard and why. A sales manager on Monday morning wants to know if the team is on track. A support lead wants to know what is waiting right now. A founder wants to know if anything is broken or growing. These are three different first screens, even if the data lives in one database.
Try this exercise. Write the user's first question as a plain sentence: "Are we on track this month?" or "Is anything on fire?" The dashboard's first screen must answer that sentence in a few seconds. Everything else is a second question, and it can live on another page.
If you are not sure what the question is, ask five users. Ask what they check first when they log in, and what they do after. Ask what they copy into a spreadsheet or a slide, because that shows what the dashboard fails to give them.
Pick three to five numbers
A user can scan a few numbers at once. Past about five, the eye starts to skip. So choose carefully.
Good headline numbers share some traits:
- They answer the first question. If the question is "are we on track?", show progress against a goal, not total sign-ups since 2021.
- They lead to a decision. The user can tell what to do if the number goes up or down.
- They have context. A bare number means little. Show a comparison, such as against last week, last month or a target. Say what period the number covers.
- They are defined. "Active users" means different things in different companies. Give a short definition on hover or in a note.
- They are up to date. Show when the data was last refreshed, especially if it is not live.
Be wary of vanity numbers: totals that only go up, and figures that look good but change no decision. If nobody would act on a number, it probably belongs elsewhere.
Layout and hierarchy
A dashboard is read, not studied. Layout should guide the eye in the order that matters.
- Put the most important thing top left. In left-to-right languages, people start there.
- Use size to show importance. The key number or chart should be clearly larger than the rest.
- Group related things. Put numbers that belong together in one block, with a short heading.
- Use whitespace on purpose. Crowded cards look like work. Breathing room helps people find things.
- Keep a steady grid. Cards that line up are easier to scan than cards that almost line up.
- Limit colors. Use color for meaning, such as red for problems and green for good, and do not rely on color alone. Add an arrow, a label or an icon so it works for people with color blindness.
Consider a simple structure: a row of headline numbers at the top, one main chart or table below, and a small area for alerts or next steps. That is enough for many products.
Charts or tables
People reach for charts because they look good. But a chart is not always the right choice.
| Use | When |
|---|---|
| A big number with a small trend | The user needs the current value and its direction. |
| A line chart | The question is about change over time. |
| A bar chart | The question is about comparing a few categories. |
| A table | The user needs exact values, many categories, or something to act on, like a list of overdue invoices. |
| A progress bar | There is a clear goal and the user wants to know how close they are. |
Avoid pie charts with many slices, 3D effects, and charts with two vertical axes that nobody can read. Label things directly instead of making users hunt through a legend. Start bar charts at zero. If you cut the axis, say so.
A table is not a failure. For work that people need to act on, a clear table with a few good columns beats a pretty chart. A short list of "things that need you" is often the most useful block on the page.
Filters and date ranges
Filters give users control, but they also add complexity and ways to get lost.
- Set a sensible default. Most people should see something useful without touching a filter. "Last 30 days" is a common default, but choose by how your users work.
- Show what is applied. A user who forgets they filtered to one region will make the wrong call. Display active filters clearly, with an easy way to clear them.
- Keep date ranges simple. Offer a few presets (today, last 7 days, last 30 days, this month) and a custom range. Show the exact dates that result.
- Apply filters to the whole page, or make it very clear which parts they affect. A filter that only changes half the dashboard confuses people.
- Remember the choice. If a user always looks at the same team, save it.
- Do not hide the main view behind filters. The first screen should work without them.
Move the rest to other pages
The hard part is cutting. Once you pick the first-screen numbers, the others still matter, but not here. A good pattern is to let the headline numbers link to a detail page. The user sees the summary and can click to learn why.
Things that often belong on other pages: detailed breakdowns, full tables, historical reports, settings, and metrics that matter to only one role. If different roles need different views, consider role-based dashboards, or let people choose a few cards.
If many teams are asking for "just one more number", ask what decision it supports and who will look at it. If nobody can answer, it does not go on the first screen.
Empty and loading states
Dashboards are often shown in a demo with perfect data. Real users see worse.
- Empty. A new account has no data. Do not show six empty charts. Show one clear step, such as "Connect your data source", and consider sample data labeled as such.
- Loading. Dashboards pull from many sources and can be slow. Show the layout early with placeholders, and fill in each block when it is ready, so one slow query does not block the page.
- Partial data. If one source fails, say which one. Do not show a zero that looks like a real value.
- Stale data. Show the last update time, and a clear way to refresh.
- Errors. Say what failed and what to try. Keep them visibly different from empty states.
Designing these early saves a lot of pain after launch.
Where to go from here
You can test a dashboard quickly. Give five users the first screen for ten seconds, take it away, and ask what it told them. If they cannot say, the screen is not clear yet.
We design dashboards for SaaS and AI teams, and there is more about our focus on the SaaS design agency page. You can see examples of our product screens on the work page. If your dashboard is already live and people do not use it, a UX audit will show where it loses them and what to change first.
