Design dashboards around decisions

Ask what happens after someone looks

Dashboard projects usually start with a list of available metrics. We’d turn that around. Who’s going to use this, what are they trying to understand, and what will they do next? An executive checking overall direction has a completely different job from an operator hunting for the one item that needs attention today.

Write a decision sentence for each part of the dashboard. For example: “A team lead needs to spot overdue requests so they can reassign work.” If a chart doesn’t support a decision, an investigation or some genuinely needed reassurance, question whether it belongs on the first view at all.

Build a hierarchy of attention

You don’t need every field on one page. Start with what helps people get their bearings, then give them a clear route into the records behind it.

On a supervision platform at a global investment bank, the old dashboard showed a dense mass of colour-coded alerts. The redesign grouped work into overdue, due today, due tomorrow and upcoming. It sounds almost too simple. But it matched how supervisors thought about their day, and that’s what made the priorities obvious. Personal and team views then let each person focus on their own work while keeping an eye on the wider picture.

An overdue count only helps when it comes with its definition, a time frame and a way to see the affected items. A big coloured number without those raises more questions than it answers.

Explain what the numbers mean

Labels should say what’s being measured, over what period and in what unit. Make it clear whether a figure is live, delayed or based on incomplete data. Define slippery words like “active”, “complete” or “at risk” right where people need them.

Comparisons need care too. A change might reflect a different time period, a new definition or missing records. Show those conditions rather than relying on red and green to imply good or bad. People shouldn’t need a separate data dictionary to read the screen correctly.

Keep the route to detail intact

Filters and drill-downs should hold on to context. If someone narrows the view to one team, the table they land on should make that obvious. Going back to the overview shouldn’t throw away their work. Decide early which filters apply to the whole page and which only affect one section.

For tables, use proper headings and structure, not just visual spacing. W3C’s tables tutorial explains how good markup makes data tables accessible. And for charts, plan a text summary or alternative alongside the visual.

Design the awkward days

A dashboard has to make sense when there’s no data yet, when an integration is late, or when only part of the data has loaded. Zero and unknown are not the same thing, and a blank panel shouldn’t leave people wondering whether the system’s broken.

Check these explicitly:

• First use, before any data is connected.
• No records matching the current filters.
• A delayed or failed data refresh.
• Partial access because of permissions.
• A change in how a measure is defined.
• A record that changed since the page loaded.

Test the decision, not the chart

When you test, give people a realistic task and see whether they can spot the right issue and take the next step. Whether they prefer bar charts to line charts matters far less than whether they read the situation correctly.

There’s more on recommendation tiles inside customer dashboards in the personalised financial dashboards case, where research found 95 of 115 participants were happy to see relevant products in their dashboard. If your existing dashboard isn’t pulling its weight, a UX Audit will show you where to focus before you commit to a redesign.