How do you design a dashboard?

In short

Page Laubheimer (NN/g) defines a dashboard as data visualisations assembled on one page. The aim is to give users information at a glance so they can act quickly. According to Laubheimer, a dashboard isn’t meant for open-ended exploration.

People also say admin panel, back office or just panel. I describe it all here as one pattern: the user looks at the screen, looks for the answer to a question and decides.

The most common dashboard problem in my audits is clutter. The team puts every available metric on the screen, and the user can’t find the one number they are looking for. In the live example below, you measure this difference with your own time.

Audience and decision first

I don’t start a dashboard with a chart but with a question. Who looks at this screen, and which decision do they make afterwards? If you can’t write down the answer, you can’t decide what belongs on the screen either.

Laubheimer distinguishes two kinds of dashboards. An operational dashboard quickly delivers the crucial information for time-critical work. Constantly changing data such as server status or patient vital signs are examples.

An analytical dashboard is for less urgent decisions. It shows which topic should be looked at more closely. If both kinds mix on one screen, both are hard to read.

Kate Moran (NN/g) also starts chart choice with the same question: what is your goal? According to Moran, a number without context is meaningless; to interpret it, we compare it with another. In Moran’s examples, these are earlier years, another feature or another user group.

Before I start, I write a short list:

• Who looks at this screen, and how often? If you have a persona, start there.
• Which question does the person ask when they look? Write it in one sentence, such as “Which region is below target this month?”.
• What do they do when they see the answer? Do they call someone, open a record? Maybe they do nothing at all.
• What do they compare each number with? The target, the previous period or another group.

With an admin panel, the question changes a little. Someone administering often doesn’t look at a number but looks for a record and edits it. Why the person who buys and the person who uses differ in B2B products is described in the article B2B and B2C UX.

Hierarchy: where the most important information goes

The most visible spot on the screen belongs to the answer to the audience’s question. Everything else comes after or moves to another page.

Kate Kaplan (NN/g) writes eight guidelines for complex applications. The last is about highlighting important information. According to Kaplan, adding emphasis isn’t enough for that; you have to remove what is unnecessary.

In Kaplan’s example, a dashboard has money-themed icons next to the numbers. Kaplan writes that these extra graphics make visual search harder and that plain number cards make the data easier to find. The colourful icons in the cluttered dashboard below are of this kind.

The same rule applies to alerts. Laubheimer says that dashboards monitoring large amounts of data should draw attention to critical values. Alerts that follow one another without prioritisation do the opposite.

I use this order:

1. At the very top, the answer to the question: a sentence or a number, with a comparison.
2. Below it, the chart that explains the answer.
3. At the very bottom or on click, the details: table, breakdown, history.

Kaplan also recommends showing details without leaving the main screen. One example is showing the exact value in a tooltip when you hover over a point in the chart. How the number of options affects decision time is described on the Hick–Hyman law page.

Live example: same data, two dashboards

Below is a sales team’s monthly dashboard. The data is the same in both states. In the cluttered state, the answer is spread over a donut chart, a legend and a separate target table. In the simple state, the answer is at the very top and the chart below shows it.

Try the task in the cluttered state first, then in the simple one. You are faster the second time because you know the answer; allow for that. Even so, I expect most of the difference to come from the design.

Same data, two dashboards

Cluttered state

Period: this month Channel: all Amounts: $K Updated: 9:00 a.m. Comparison: last month

Total sales

$1,135K

Vs. last month +2%

Visits

48,210

Vs. last month −3%

Conversion rate

2.4%

Vs. last month +0.1 points

Average order value

$61

Vs. last month +1%

Return rate

3.1%

Vs. last month −0.4 points

Active customers

9,874

Vs. last month +5%

Share of sales by region

• Southeast 168
• West 236
• Midwest 198
• Northeast 121
• Southwest 412

Overall target attainment

103%

Regional targets ($K)

Region	Target	Last month
Southwest	380	395
West	250	241
Midwest	190	185
Southeast	160	171
Northeast	120	118

Alerts (7)

• Inventory: 14 products at a critical level
• West: summer promotion ended
• Server response time increased
• New customer reviews: 23
• Southeast: down on last month
• Invoicing interface delayed
• Weekly report ready

Simple state

Filter: this month, all channels. Amounts in $ thousands.

1 region below target: West. It is at 94% of target, $14K short.

Sales and target by region, the region furthest from its target at the top

• West 236 / 250, 94% Below target

• Northeast 121 / 120, 101% On target

• Midwest 198 / 190, 104% On target

• Southeast 168 / 160, 105% On target

• Southwest 412 / 380, 108% On target

Sales this month Target

Total sales

1,135

Target 1,100

Target attainment

103%

Sum of the 5 regions

Regions on target

4 / 5

Only West is below target

The data is made up and the same in both dashboards. Start the task and choose the region below as soon as you have the answer; your time is recorded. Then choose the other state and try again. Without JavaScript, both dashboards are shown one below the other.

In the cluttered state, you subtract numbers from two places in your head. The alert that Southeast is down on last month also draws attention to the wrong region. Southeast is down but still above target.

In the simple state, the region below target can be seen in three ways: with text, with a label and with hatching. Even someone who can’t tell colours apart reads the answer from the text and pattern.

Choosing the chart

When choosing a chart, I ask myself: what will the user compare in it? Laubheimer writes that people estimate lengths and position in two dimensions quite accurately. Areas and angles, on the other hand, they estimate poorly.

That is why bar and line charts are the basic tools for comparing numbers. The bar chart uses length; line and scatter charts use position.

User’s question	Chart	Note
Which is bigger?	Bar chart	Sort the bars. For long labels, Moran recommends horizontal bars.
How has it changed over time?	Line chart	Moran recommends marking the points where data was collected.
How close is it to the target?	Bullet chart (bar with target line)	Laubheimer recommends it instead of a gauge.
Do two things change together?	Scatter plot	The points aren’t connected with a line.
How does a single number stand?	Big number	Write the target or previous period next to it.

The charts I avoid are settled too:

• Pie and donut charts. Laubheimer considers the pie chart weak for most communication tasks. The exception is when one part is by far the largest. The donut chart is even harder to read because of the hole in the middle.
• Gauge. Round dials like in a car work with angles and take up a lot of space. According to Laubheimer, they are harder to read than linear charts.
• 3D chart. Three dimensions distort shapes and alignment. According to Laubheimer, with 3D bars it is very hard to see which value the top edge shows and how it lines up with the gridlines.
• Stacked bar. Moran writes that parts that don’t start at the same point are hard to compare. She recommends a separate bar chart for each result instead.
• Treemap. According to Laubheimer, it gives an overview of a complex data space in a small area. It doesn’t suit a simple, action-oriented dashboard.

I don’t use colour to show size either. According to Laubheimer, colour has no natural order. Hue or saturation do work as a second signal for grouping.

Empty, loading and error states

The most neglected states of a dashboard are the moments when there is no data or it hasn’t arrived yet. In the design file every card is full. In a real account, a new user’s dashboard is empty, or a query returns nothing.

Empty state

According to Kaplan, an empty dashboard leaves the user in the dark. Is the system still running, was there an error, or is the filter wrong? Kaplan recommends writing a short status message in the empty area: “There are no records for the selected period.”

Kaplan recommends two more steps. The empty area can teach what goes there. It should also offer a direct path to the work that fills it. In Kaplan’s example, an empty alerts panel has a “Create” button.

The empty screen of a new account is covered separately in the onboarding pattern and the empty state pattern.

Loading

Kaplan has a warning about loading too. Writing “No records” while the content is still loading is misleading. The user waits, loses trust or leaves the page before the content arrives.

Samhita Tankala (NN/g) distinguishes by waiting time:

• Under 1 second: neither skeleton screen nor spinner is needed.
• 2 to 10 seconds: a spinner for a single card, a skeleton screen for the whole page.
• Over 10 seconds: a progress bar with a time estimate.

In a dashboard, cards often load one by one, so I draw a separate loading state for each card. I also follow Tankala’s warning: shimmering or pulsing skeletons can be distracting and cause accessibility problems.

Error

Tim Neusesser and Evan Sunwall (NN/g) ask for an error message to sit close to where the problem occurs. In a dashboard, that is the card that couldn’t fetch its data. I don’t write the message at the top of the page but in that card.

The message is written in plain language and suggests a solution. “Sales data isn’t coming through right now. Try again in a few minutes.” instead of “Error 503” is an example. According to the authors, an error shouldn’t be shown only with colour or animation.

If one card has an error, the others should keep running. If a single query turns the whole dashboard into an error screen, it hides the working data too.

Filters

For data tables, Laubheimer asks for filters that are easy to find, fast and powerful. I think the same way about dashboard filters. The user shouldn’t have to look for the period or region.

More important is this rule: when a filter is active, the screen must say so clearly. Laubheimer asks for a clear visual sign that filters are active. Without it, the user takes the filtered number for the total.

I often see a trap in audits. The user chose a region filter last week, the dashboard remembers it, and today all the numbers look low. A line at the top of the screen such as “Filter: West, last 7 days” prevents this confusion.

Kaplan also shows as an example how changes appear in the preview right away while a dashboard is being edited. The user doesn’t have to wait until the end to see whether the result matches their intent. Show rarely used options only when they are needed; Kaplan calls this staged disclosure.

Accessibility: charts that don’t depend on colour

If a chart passes on information only through colour, some users can’t read it. Laubheimer writes that up to 4.5% of the population has some form of colour blindness. It is much more common in men than in women.

WCAG 2.2 success criterion 1.4.1 Use of Color (level A) requires that colour isn’t the only visual means of conveying information. Among the W3C’s sufficient techniques, two stand out for charts. One is to use patterns in addition to colour (G111). The other is to give the information conveyed by colour in text too (G14).

Success criterion 1.4.11 Non-text Contrast (AA) requires at least 3:1 contrast against the adjacent colour for the parts of a chart needed to understand it. According to the W3C’s example, the lines of a line chart fall under this rule. If the values of pie segments are given adequately in another way, the segments don’t count as needed for understanding.

In practice I do the following:

• Next to each bar I write the name and value. Nobody has to match colours in a legend.
• I mark values below target with another sign in addition to colour: a pattern, an icon or the label “Below target”.
• The chart gets a text equivalent that the screen reader reads out. The information conveyed by colour is in it too.
• I measure the colours of lines and bars against the background in the contrast checker.

All the criteria and levels are covered in the WCAG guide.

Dashboards on phones

On phones, I stack cards that sit side by side. The order follows the hierarchy on desktop: the answer to the question stays at the top. If you open the example above on a narrow screen, you see the cards stacked.

I don’t fit wide tables on phones by making the text smaller. I turn each row into a card or show only the two most important columns. I set the size of touch targets by the logic of Fitts’s law.

Checklist before launch

• I have written down the screen’s audience and their decision in one sentence.
• The top information is the answer to that decision.
• Next to each number is a comparison: target, previous period or a similar group.
• I have removed decorative icons and 3D effects.
• Instead of pie, donut and gauge, I use bars or a bullet chart.
• For each card, the empty, loading and error states are drawn.
• The active filter is shown as text on the screen.
• The charts can be read without colour too.
• On phones, the cards are stacked in order of hierarchy.

I do the final check with real users. I ask the dashboard’s real question and watch how long the answer takes. How I set that up is described in the usability testing guide.

My note

I check whether a dashboard is good with a single test. I ask the person in front of the screen their real question and count how many seconds it takes them to have the answer. If it takes long, the problem is almost always clutter.

Teams find it easy to add cards and hard to remove them. Every card has an owner, and nobody wants their metric to disappear. That is why I recommend moving instead of deleting: details go to a subpage, and the decision stays on the main screen.

And I ask for one thing: don’t draw the dashboard with the clean data from the design file, but with real, messy data. If a long region name, a zero value or a missing month breaks the screen, you want to see it before launch.