How to build a dashboard people use

Most organizations have far more dashboards than people who open them weekly. The gap exists because dashboards are easy to build and hard to kill — building one feels like progress, and nobody wants to be the person who deletes a report a director might still glance at. The fix starts before the first chart is placed: know exactly who this is for and what decision it changes, and build only that.

Start with the audience, not the data

A dashboard for an executive, an operator and an analyst are three different products, even if they draw on the same underlying tables.

• Executives want a small number of headline metrics, trend over time, and a clear signal of whether something needs attention — not a page to explore. Five to seven numbers, updated on a cadence they actually check, beats forty.
• Operators — a support lead, a marketing manager — need current, actionable numbers they check daily or more, often with the ability to drill into a specific case or campaign that needs action today.
• Analysts want raw, flexible access more than a fixed dashboard; give them self-service BI access to modeled data instead of trying to anticipate every question in a static layout.

Building an executive summary with an analyst's flexibility, or an analyst tool with an executive's simplicity, satisfies neither audience well.

Ask what decision this changes

Before adding a chart, name the decision or action the viewer takes differently because of it. "It would be interesting to know" is not that answer. A dashboard built around decisions naturally stays small, because most curiosities do not clear that bar — and the ones that do not can still be answered with ad hoc analysis instead of a permanent chart.

A useful test while designing: if a number moves in the wrong direction, does the dashboard make it obvious what to do next? A KPI on its own answers "how are we doing"; pairing it with the guardrail metric it might be traded off against — for example, conversion rate next to refund rate — answers "how are we doing, and at what cost," which is usually the more honest question.

Choose chart types for the comparison, not the decoration

The chart type should follow from the comparison being made, not from what looks most polished. A trend over time is a line; a comparison across a handful of categories is a bar, ordered by value rather than alphabetically unless alphabetical order is itself meaningful; a part-to-whole comparison with more than five or six segments is usually better as a table or a sorted bar chart than a pie chart, which becomes unreadable past a few slices. Resist chart types chosen because they look sophisticated — a gauge or a radial chart is rarely as legible at a glance as a well-labeled number and a simple trend line, and "at a glance" is the whole point of a dashboard.

Layout: lead with the answer

Put the most important number where a viewer sees it without scrolling, sized so it reads at a glance. Group related charts together, order top to bottom by importance rather than by when you happened to build each one, and label plainly enough that someone opening the dashboard for the first time understands what they are looking at without asking the builder. This is the core of data storytelling: the layout itself should communicate a conclusion, not just present data and leave the viewer to find one.

Avoid the common failure of cramming every available metric onto one screen because removing any of them feels like a loss. A dashboard that requires a legend to explain what fifteen small charts mean has usually failed the audience test above — split it, or cut it.

Build for maintenance, not just launch

A dashboard is a commitment, not a one-time deliverable:

• Document the source and filter logic behind each number, so the next person to maintain it — or to answer "why doesn't this match the other dashboard" — does not have to reverse-engineer the query.
• Build on modeled, governed data, not a one-off query against raw tables, so a change upstream does not silently break the dashboard. See how to build a metrics layer if the underlying definitions are not yet centralized.
• Set an explicit refresh cadence and make staleness visible — a "last updated" timestamp costs nothing and prevents a decision being made on data that is quietly a week old.
• Assign an owner. A dashboard with no owner is the one that breaks silently and stays broken, because nobody is notified and nobody feels responsible for noticing.
• Teach the reading, not just the building. A well-built dashboard still fails if viewers do not know how to read it — whether a spike is normal seasonal variation or a real signal. A short walkthrough at launch does more for data literacy than another chart added to the page.

Retire deliberately

Most organizations are much better at creating dashboards than removing them. This asymmetry compounds: every unretired dashboard is one more place a definition can quietly drift out of sync with the metrics layer or the tracking plan that fed it, and one more place a stakeholder can screenshot a stale number into a meeting as current. Two practical habits fix this:

1. Track last-viewed dates — most BI tools expose this — and review the list quarterly. A dashboard nobody has opened in three months is a candidate for archival, not a permanent fixture.
2. Sunset with notice. Post a deprecation date, point people to its replacement if one exists, and only then remove it. A dashboard that vanishes without warning erodes trust in every dashboard that replaces it.

A short checklist

• Named audience, one primary decision it supports.
• Headline number visible without scrolling; supporting detail below it.
• Built on modeled data with documented logic, not a raw one-off query.
• Visible freshness and a named owner.
• A review date, and a plan to retire it if usage never materializes.

Where to go next

For choosing the underlying platform, see how to choose a BI tool; tools such as Looker, Tableau, Power BI and Metabase differ mainly in who builds in them and how self-service they are for the viewers above. Once dashboards sit on well-defined metrics, pair this with how to build a metrics layer so the same number reads the same way everywhere it appears. The full category is browsable at BI and dashboard platforms.