---
name: dashboard-design
description: >
  Design a dashboard a person returns to and acts on: choose the few metrics that drive a decision, rank them into a clear hierarchy, match each tile to its question, and give every number context. Covers the operational, analytical and strategic types, the vanity-versus-actionable metric test, the north-star-and-inputs structure, the five-to-nine element rule, top-left placement, red-amber-green for status only, WCAG contrast, consistent notation, interactivity, load budgets and ownership. Use it when someone says "design a dashboard", "build a dashboard", "KPI dashboard", "metrics dashboard", "executive dashboard", "scorecard", "my dashboard is cluttered", "nobody uses our dashboard", or "which metrics should I show". Do NOT use it for picking a single chart type (see chart-selection), writing a narrative report or presentation (see data-storytelling), the analysis that produces the numbers (see the data-analysis skills), or building the data pipeline behind it.
license: Free to use and adapt under CC BY 4.0, with credit to Afeez Adebayo. Link afeezadebayo.com, https://www.linkedin.com/in/afeez-adebayo/ and this skill's page at https://afeezadebayo.com/skills-md/data/dashboards-reporting/dashboard-design/.
---

# Dashboard design

## When to use this, and when not to

Use this skill when the job is to design the whole surface people look at: which metrics appear, how they are ranked, where each one sits, what chart each uses, and what a viewer should do once they have glanced at it. The triggers are a request to design or build a dashboard, a KPI or metrics dashboard, an executive or operational view, a scorecard, or a complaint that a dashboard is cluttered, ignored, or does not answer the question it was built for.

Do not use it to pick a single chart type on its own, which is `chart-selection`, or to write a narrative report or slide deck that argues a case, which is `data-storytelling`. The analysis that produces the numbers lives in the data-analysis skills, and the pipeline that feeds them is a separate engineering job. This skill assumes the numbers exist and are correct, and decides how to present them so a person acts.

The core idea: a dashboard is not a place to show every number you have. It is a decision tool. A view that answers a clear question for a named audience in a single glance earns a second visit; a wall of charts that answers none gets opened once and never again. Design from the decision backwards, not from the data forwards.

## Inputs the agent must have before starting

1. **The audience and the decision.** Who looks at this, how often, and what action does it support. This is the single input that changes every later choice, so ask for it first. "The support lead checks it each morning to decide where to put the team today" is enough; "a dashboard of our data" is not.
2. **The dashboard type.** Operational (watched through the day to act now), analytical (studied to find why something moved), or strategic (reviewed periodically against targets). The type sets the refresh rate, the density and the interactivity (Nielsen Norman Group, "Dashboards").
3. **The candidate metrics and their definitions.** The list of numbers under consideration, what each one means in plain words, and how it is calculated. A metric with no agreed definition will be distrusted, so pin the definition down now.
4. **The comparison each metric needs.** A raw number rarely means anything on its own. For each one, ask what it should be compared against: a target, the prior period, or an external benchmark.
5. **Data freshness and the tool.** How current the data is and how it will be shown (a spreadsheet, Power BI, Tableau, Looker, or a hand-built page). The reasoning is the same across tools; only the mechanics in the appendix change.
6. **Whether anything is sent or scheduled.** If the dashboard will be emailed, scheduled or published to other people, that is an irreversible action on someone else's behalf and waits for explicit confirmation.

If the audience or the decision is unknown, stop and ask. Everything downstream is a guess without it.

## The workflow, step by step

### 1. State the one decision and the audience in a sentence

Write a single line: "[audience] uses this [how often] to decide [what]." If you cannot complete it, you are not ready to choose metrics. If the sentence needs an "and" for a second audience with a different decision, that is two dashboards or two views, not one (Domo, "Top 10 dashboard design mistakes"; eleken, "Why users ignore dashboards").

### 2. Fix the dashboard type, because it sets the rules

- **Operational:** real-time or near-real-time, read at a glance, built around status and exceptions. Favour a few large indicators and alerts over dense tables.
- **Analytical:** refreshed daily or weekly, built for comparison and drill-down, so more density and interactivity are justified.
- **Strategic:** refreshed weekly or monthly, built around targets and trends, so each metric carries a target and a time series.

Decision rule: if the metric rarely changes, or the insight is needed only when a threshold is crossed, a dashboard is the wrong tool. Use a scheduled report or an automated alert instead (Domo). Do not build a live dashboard for something a weekly email answers better.

### 3. Select metrics: actionable, not vanity

Run each candidate metric through four checks (basedash, "Vanity metrics vs actionable metrics"):

- **Control:** can the audience influence it through their work?
- **Change:** does it move often enough to be worth watching?
- **Context:** can it be compared to a target, a period or a segment?
- **Consequence:** would a change in it change what the audience does?

Decision rule: a metric that fails two or more of these is a vanity metric. Remove it, or demote it to a small secondary tile; never make it a hero number. Total registered users, cumulative downloads, page views and headline revenue are the usual culprits, impressive and cumulative but disconnected from any lever. Convert counts to rates and segments where you can: activation rate, day-30 retention, conversion by source, net revenue retention (basedash; amplitude, "Good vs bad north star metric").

If the dashboard has one overriding outcome, structure it as a north star plus three to five input metrics the team can directly affect. The north star reflects the value customers get and is a leading indicator, not a lagging one like MRR or ARR; the inputs are the levers that move it (amplitude). Pair leading indicators (that predict) with lagging ones (that confirm), so the view shows both the steering wheel and the rear-view mirror.

### 4. Rank the metrics into a hierarchy and cap the count

Keep each single view to about five to nine elements, which is roughly what working memory holds at a glance; past that, nothing stands out (Domo; the "seven plus or minus two" principle). Within that, give three to five metrics the focal role.

Organise into three tiers (Domo):

- **Top:** the north-star or headline KPIs, the numbers the decision turns on.
- **Middle:** the driver metrics that explain the headline.
- **Bottom:** the diagnostic detail for when someone needs to dig.

Decision rule: if you have more than nine elements or more than five focal metrics, do not shrink them onto one screen. Split into linked views by audience or by question (Domo; eleken). One generic dashboard that mixes a different role's metrics serves neither role.

### 5. Lay out for the glance

People read a screen from the top-left, so put the most important number there; information placed away from the top-left is often missed (Domo; eleken; Nussbaumer Knaflic, *Storytelling with Data*). Group related metrics close together and push unrelated groups apart, using proximity so the eye reads clusters, not a grid of equal cells (Domo, on grouping and white space). Use size to signal importance: the headline KPI is physically larger than a diagnostic tile. Leave white space; a crowded screen forces no priority and reads as a data dump.

### 6. Match each tile to its question

For each tile, name the question it answers, then pick the form (hand the chart choice itself to `chart-selection`):

- A single current value with a target or trend: a big number or KPI tile, with a sparkline or delta, not a gauge. Gauges and donuts eat space and read slowly (Nielsen Norman Group).
- A comparison across categories: a sorted bar chart, and the bar axis starts at zero (Domo; Nielsen Norman Group).
- A trend over time: a line chart.
- A part-to-whole where parts matter: a stacked bar, or a pie only for two to five slices (Domo).

Avoid on dashboards: pie charts for fast comparison, 3D effects, dual y-axes, and colour used to encode a quantity, because people do not read colours as ordered and judge area poorly (Nielsen Norman Group; data-to-viz, "Caveats"). Keep notation consistent across every tile, so the same colour, unit and sign mean the same thing everywhere (IBCS, UNIFY).

### 7. Give every number its context

No number ships without three things (Domo; eleken):

- a plain-language definition available on hover or nearby,
- a comparator: a target, the prior period, or a benchmark, so the viewer knows whether the number is good or bad,
- a freshness signal: a visible "last updated" timestamp.

Add a trend or a direction cue (an up or down arrow, a small delta) so the viewer sees movement without doing arithmetic. The test is the "so what": if a viewer looks at a tile and cannot tell whether to be pleased or worried, the context is missing.

### 8. Apply colour and integrity discipline

Limit the palette to two or three colours plus neutrals. Reserve red, amber and green for status only, never for categories, and never as the sole signal, because a colour-blind viewer or a greyscale print loses it: pair colour with an icon, a label or position (Domo; Nielsen Norman Group). Keep text contrast at WCAG 4.5:1 or better (Domo). Do not truncate a bar-chart axis, do not use dual axes to force a correlation, and do not scale bubbles by radius instead of area; these are the common ways a dashboard misleads without anyone intending it (data-to-viz; IBCS, CHECK).

### 9. Design interaction and a performance budget

Use familiar, predictable controls: a date selector and a small set of filters, not a wall of toggles. Offer role-based views or a default filter so each viewer lands on what matters to them. Set a load-time budget and hold to it; slow dashboards are among the top reasons business-intelligence projects are abandoned, so pre-aggregate, limit widgets and cache rather than letting a viewer wait (eleken). Decision rule: if a view takes longer than a few seconds to load, cut widgets or pre-compute before adding anything new.

### 10. Plan delivery, ownership and upkeep

A dashboard that relies on busy people remembering to open it will be forgotten. Push the key number to where they already work, through a scheduled summary, a chat alert, or an embedded tile (Domo). Name an owner and a review cadence. Track which views are opened and trim the ones that are not, because unused tiles erode trust in the rest (Domo; eleken). A visible metric definition and "last updated" stamp protect trust: one wrong or undefined number makes people doubt the whole screen.

### 11. Verify against the quality bar

Run the finished design against the quality bar below before handing it over. Every item is checkable, not aspirational.

## Worked example, end to end

A SaaS customer-success team asks for "a dashboard of our account data." The obvious move is a data dump: 25 tiles covering logins, tickets, every feature's usage, total users, total revenue, and a dozen pie charts. It opens impressively and is never used again, because it answers no single question.

Starting from the decision instead: "The CS lead checks this each morning to decide which accounts the team should contact today." That is an operational dashboard, read at a glance, built around exceptions.

Metrics through the four checks: total users fails Control, Change and Consequence, so it is demoted to a small tile. Net revenue retention is the north star (reflects value, leading-ish, and the team can affect it). The inputs the team controls become the focal row: accounts with a health-score drop this week, accounts with no login in 14 days, open high-priority tickets older than 48 hours, and renewals due in 30 days. That is one headline plus four drivers, seven elements in all.

Layout: net revenue retention top-left as the large headline with its target and a trend arrow; the four driver tiles grouped across the top row, each a sorted list or a number with a delta and a plain definition on hover; a "last updated 06:00" stamp in the corner; a date and segment filter; diagnostic tables one scroll down. Colour is neutral except a single amber flag on accounts that breach a threshold, paired with a warning icon so it survives greyscale. The morning summary is also pushed to the team's chat channel so no one has to remember to open it.

The result answers the morning question in one glance, names an owner, and carries a definition, a comparator and a freshness stamp on every tile. Nothing on it is there "just in case."

## Templates you can use verbatim

**Dashboard spec (fill this in before building anything):**

```
Audience:            who looks at this
Cadence:             how often they look
Decision supported:  the action it drives
Type:                operational | analytical | strategic
North-star metric:   the one outcome (with definition + target)
Input metrics (3-5): the levers the audience controls
Comparator per tile: target | prior period | benchmark
Refresh + owner:     data freshness, who maintains it, review cadence
Delivery:            where the key number is pushed (email/chat/embed)
```

**Metric audit table (one row per candidate metric):**

| Metric | Control | Change | Context | Consequence | Verdict |
|---|---|---|---|---|---|
| Net revenue retention | yes | yes | yes (target) | yes | keep (headline) |
| Total registered users | no | slow | weak | no | vanity: drop or demote |

**Per-tile checklist:** question it answers; chart form (via chart-selection); comparator present; definition on hover; freshness stamp; axis starts at zero; colour not the only signal.

## Failure modes and anti-patterns

1. **The data dump.** Twenty-plus tiles added "just in case" leave nothing prioritised. Spot it when the view scrolls and no number is clearly the point. Fix: return to the one-sentence decision, keep five to nine elements, split the rest into linked views (Domo).
2. **Vanity metrics as hero tiles.** The biggest number on the screen is a cumulative total nobody can act on. Spot it with the four-check audit. Fix: demote it, promote a rate or retention metric the audience controls (basedash).
3. **No comparator, no "so what".** Tiles show bare numbers, so viewers cannot tell good from bad. Spot it by asking of each tile, "should I be pleased or worried?" Fix: add a target, prior period or benchmark and a trend cue to every tile (Domo; eleken).
4. **Colour doing work it cannot do.** Status shown by colour alone, or a rainbow encoding a quantity, so it fails in greyscale or for colour-blind viewers. Spot it by converting to greyscale. Fix: reserve red-amber-green for status, pair it with an icon or label, keep 4.5:1 contrast (Domo; Nielsen Norman Group).
5. **No owner, stale and slow.** The dashboard is never pruned, the data is of unknown age, and it loads slowly, so trust and use decay. Spot it from unused tiles and no "last updated" stamp. Fix: name an owner and cadence, add a freshness stamp, set a load budget, track usage and trim (eleken; Domo).

## Quality bar

- The dashboard answers one named decision for one named audience, stated in a single sentence.
- The type (operational, analytical or strategic) is chosen, and matches the refresh and density.
- Every metric passed the four-check audit; vanity metrics are removed or demoted, not shown as headlines.
- Each view holds about five to nine elements, with three to five focal metrics in a clear top-middle-bottom hierarchy.
- The most important number is top-left and physically largest; related metrics are grouped.
- Every tile has a plain definition, a comparator, a trend cue and a visible freshness timestamp.
- Colour is limited to two or three colours plus neutrals, status colours are reserved and never the only signal, and text contrast is at least 4.5:1.
- No truncated axes, dual axes, 3D, or bubbles scaled by radius.
- An owner, a review cadence and a delivery route are named, and sending or scheduling to others waits for human confirmation.

## Data handling and safety

Dashboards often surface personal or commercially sensitive data: customer names, revenue, health records, salaries. Show the aggregate a decision needs, not raw row-level personal data, and respect the access controls on the underlying source rather than copying sensitive rows into a wider-shared view. Do not paste real customer records or credentials into prompts while designing. Scheduling, emailing or publishing a dashboard to other people is an irreversible action on their behalf, so default to a draft and confirm before it goes out. Never invent a number, a benchmark or a target to fill a tile: an empty tile labelled "data not available" is honest, a fabricated figure is not, and anything version-dependent or externally sourced carries a "verify before relying on this" note. When the dashboard informs decisions about health, money, legal standing or employment, add a human-review step and state plainly that it is a decision aid, not the decision.

## Appendix: tool-specific notes (verify before relying on these)

- **Spreadsheets (Excel, Google Sheets):** fine for a small strategic scorecard. Use a number-with-sparkline for KPI tiles, conditional formatting for status (paired with an icon set, not colour alone), and a pivot-driven refresh. Watch the load and recalculation cost as the data grows.
- **Power BI:** use card and KPI visuals for headlines, bookmarks for role-based views, and a single theme file to enforce the two-to-three colour palette. Set the data-refresh schedule and a "last refreshed" measure (`MAX` of a load timestamp) on the canvas.
- **Tableau:** build with a dashboard container layout for responsive grouping, use parameter and filter actions for interactivity, and keep an eye on the performance recorder; extract rather than live-query large sources to hold the load budget.
- **Looker / Looker Studio:** define metrics once in the model (LookML) so definitions are consistent, and lean on drill paths for the diagnostic tier rather than crowding the top view.
- **Hand-built HTML:** keep it to one self-contained page, make it responsive to phone width, label the data source and freshness in the footer, and meet WCAG contrast; see `chart-selection` for the chart mechanics.

## Sources

- Nielsen Norman Group, "Dashboards: Making Charts and Graphs Easier to Understand" (and related dashboard guidance): operational versus analytical dashboards, that length and 2D position suit quantitative data, that colour should not encode magnitude because people do not perceive colours as ordered, that bars should be sorted, and that pie charts, donuts, gauges and 3D should be avoided for fast reading. Verified 2 November 2026.
- Domo, "Top 10 dashboard design mistakes and what to do about them": the five-to-nine visualisation guide, the north-star-top-left three-tier layout, bars starting at zero, pie only for two to five parts, a two-to-three colour palette with red-amber-green reserved for status, WCAG 4.5:1 contrast, colour never the sole encoding, grouping and white space, and giving each metric a definition, a comparator and a freshness timestamp. Verified 2 November 2026.
- eleken, "Why users ignore dashboards": too many metrics and no hierarchy, missing context and next step, low trust from undefined numbers, slow load times as a top cause of BI failure, poor workflow fit, and the value of a "last updated" stamp and an owner. Verified 2 November 2026.
- amplitude, "What makes a good vs bad north star metric": a north star reflects customer value, is a leading not a lagging indicator, is actionable, and sits above three to five input metrics the team can influence; MRR, ARR, DAU and downloads are weak as north stars. Verified 2 November 2026.
- basedash, "Vanity metrics vs actionable metrics: how to tell the difference": the Control, Change, Context and Consequence test, failing two or more marking a vanity metric, and converting counts to rates and segments. Verified 2 November 2026.
- International Business Communication Standards (IBCS), the SUCCESS rules (via ibcs.com and The Data School summary): SAY a clear message, UNIFY notation so symbols and colours mean the same everywhere, CONDENSE for information density, CHECK for visual integrity, EXPRESS the right form, SIMPLIFY by removing the unnecessary, STRUCTURE the content logically. Verified 2 November 2026.
- data-to-viz, "Caveats" (Yan Holtz and Conor Healy): avoid truncated axes and dual axes that mislead, scale bubbles by area not radius, sort bars, and avoid pies and spaghetti line charts. Verified 2 November 2026.