Designing a dashboard: from user questions to the screen

The typical failure looks like this: the admin panel collects every chart the database allows — twelve cards, three pie charts and a thousand-row table. A manager opens the screen, can’t find the answer to their question and asks for an Excel export. There is plenty of data, yet no decision can be made from it.

Nielsen Norman Group describes a dashboard as a single-page collection of visualizations for at-a-glance understanding: people glance at the screen and immediately see answers to key questions, with minimal interaction or cognitive effort. NN/g stresses that a dashboard’s job is to communicate critical information, not to facilitate open-ended exploration. Exploration belongs in reports and analytics tools.

A dashboard “for everyone” usually answers no one. An executive thinks in weeks and channels, a sales manager in specific leads today. So the work starts with roles. Take a teaching example: a company that receives leads from its website and tracks them in a CRM. The questions below are a starting point; in a real project you collect them through interviews and observation, as described in the UX research lesson.

“47 leads” — is that a lot or a little? A number without context answers none of the questions above. Every metric needs a point of comparison, chosen from the decision: an executive deciding whether to look into advertising needs the deviation from the usual level, not the absolute figure.

The second trap is ambiguous definitions. Is a “lead” any submitted form, or only one with a phone number? Do duplicates and spam count? Does the week start on Monday, and in which time zone? Until this is written down, the executive and the manager will see different “47s”, and people will stop using the dashboard.

The form follows the question. NN/g relies on preattentive attributes — what the eye notices before conscious reading. For quantitative comparison, length and 2D position work best: people compare lengths well, while area and angle are noticeable but hard to judge in terms of how much bigger one is. Color doesn’t convey order, so it shouldn’t encode magnitude — it suits categories, and only as a secondary cue.

A table is a full-fledged dashboard form, not an admission of defeat. NN/g identifies four tasks people use tables for: finding records that fit criteria, comparing data, viewing or editing a single record, and taking action on one or several records. For a list of unanswered leads, that is exactly what a sales manager needs. Freeze the headers of large tables, make filters discoverable and show active filters clearly.

The order on screen follows the order of questions: the most frequent and urgent at the top left, where scanning starts, details further down. Visual hierarchy and grids are covered in a separate lesson; dashboards add two rules. First, the period and filters are global: they sit above all widgets and apply to all of them; if a widget uses its own period, that is labeled on the widget itself. Second, every number shows which period it covers and when it was updated.

Adaptation is easy to plan with Material Design 3 breakpoints: compact is under 600 dp (a phone in portrait), medium is 600–839, expanded 840–1199, large 1200–1599 and extra-large 1600 and up. Material advises designing for breakpoints rather than specific devices, and deciding what to reveal, divide, resize, reposition or swap when moving between them. One pane is recommended for compact and medium sizes, two for expanded and large.

A dashboard pulls from several sources, and each can be delayed or fail on its own. That is why states are designed per widget, not for the whole page. General rules — skeletons, error messages, empty screens — are covered in the interface states lesson; below is what is specific to dashboards.

According to NN/g, an empty state should communicate system status, provide learning cues and offer direct pathways to the steps that fill the screen. A completely empty widget makes people guess whether something broke or there really is no data. That is why “zero” and “no data” are different states: the first is an answer, the second is a prompt to act.

Chart accessibility is part of the states too. WCAG success criterion 1.4.1 forbids using color as the only visual means of conveying information: duplicate growth and decline in KPIs with a sign and a word, and lines on a chart with labels. For charts, W3C WAI recommends a two-part text alternative: a short description of what is shown and a full description as text or a data table next to the chart.

Let’s put everything into one table — the main artifact of this lesson. You can place it at the start of the mockup: the designer sees why each widget exists, the developer sees where data comes from, and the client sees which questions the screen answers.