Dashboards people use

Why it matters

Most organisations have more dashboards than anyone reads. Usage logs in BI tools often show that a large share of reports are opened by nobody except their creator after the first month. At the same time, people still email analysts for "a quick number". The problem is rarely the charts. It is that the dashboard was built around the data that was available instead of the decisions people make.

At mid-level, you will often be asked to fix an existing dashboard rather than build a new one. That means auditing it, talking to users and rebuilding with less.

Step 1: Find out how it is used

Start with evidence, not opinions:

• Usage data. Most BI tools (Power BI, Tableau, Looker, Metabase) show views per report and per user. Who opens it, how often, and which page?
• Interviews. Talk to three to five users for 15 minutes each. Ask: "When did you last open this? What were you trying to decide? What did you do next? What did you look at elsewhere?"
• Workarounds. Ask whether people export to Excel. An export usually means the dashboard lacks a view they need.

You are listening for decisions and triggers: "If refunds go above 3% in a region I call that region's manager." That sentence is a dashboard requirement.

Step 2: Audit every tile

For each chart or number on the current dashboard, ask:

1. Which decision does this support? (If none, it is a candidate for removal.)
2. Does it have a comparison (target, last period)?
3. Is the metric defined, and does the definition match other reports?
4. Is the chart type right for the question (Module 1 of Data Visualization & Storytelling)?
5. Is it trusted? Have users noticed numbers that looked wrong?

A simple audit table keeps this honest:

Step 3: Redesign around decisions

• Lead with status: a top row of the three to five KPIs with comparisons, coloured only when they need attention.
• Then the "why": breakdowns that explain movement (by region, channel, product), sorted.
• Then the "what to do": an exception list or table that names specific items to act on (regions above the refund threshold, accounts at risk).
• Make alerts do the watching. If a decision is triggered by a threshold, a scheduled alert (email or chat message when refunds exceed 3%) may be better than a dashboard someone must remember to check. Most BI tools support data-driven alerts or subscriptions.

Step 4: Ship, then measure

Release the new version alongside the old one, tell users what changed, and check usage again after a few weeks. Retire the old version on a fixed date. Keep a changelog on the dashboard itself ("v2, 2026-10: refund rate now excludes test orders").

Worked example

An e-commerce operations dashboard has 22 tiles over three scrolling pages. Interviews show the operations manager makes two weekly decisions: which warehouse needs more staff, and whether to escalate late deliveries with a carrier. The rebuilt dashboard has six tiles on one screen: on-time delivery % vs target, orders per warehouse vs capacity (sorted bars), late deliveries by carrier this week vs last, and a table of the 10 oldest undelivered orders. Two scheduled alerts cover the thresholds. Fourteen tiles move to an "analysis" page for the analytics team.

Common mistakes

• Redesigning visuals without talking to users.
• Keeping every tile because "someone might need it". Move rarely used views to a secondary page instead.
• Metric definitions that differ from the finance or product reports. Reconcile them first.
• No owner. Every dashboard needs a named owner and a review date.

Quick recap

• Measure usage and interview users about decisions and triggers.
• Audit each tile: decision, comparison, definition, chart type, trust.
• Rebuild: status, then why, then what to do; use alerts for thresholds.
• Release, measure adoption, retire the old version, keep a changelog.

Try it

The Do tab walks you through auditing and redesigning a real dashboard.