dashboard-design

Dashboard Design

Design dashboards as decision tools, not collections of cards. Make data easier to decide from, not merely decorative. A dashboard is not ready until its important states and interaction paths are verified in the browser, not only in source.

Use when

• Redesigning a marketplace or back-office dashboard
• Reworking KPI cards, charts, filters, tables, navigation, or detail panels
• Choosing chart/table forms for KPIs, trends, rankings, funnels
• Verifying a changed dashboard UI in the running app before calling it done
• Improving visual hierarchy, density, responsive behavior, or empty states

Do not use when

• The task is only backend, data modeling, or query optimization
• The user asks for a poster, presentation, logo, or static illustration

Workflow

1. Inspect before proposing. Read the existing routes, components, tokens, data shape, and current UI. For every metric find the source definition, unit, aggregation, scope, time zone, freshness, and comparison period — never infer business meaning from a label or fabricate sample values.
2. Name the primary decision. State who uses the dashboard, what they need to decide, and the three to five questions the screen must answer. If a visual supports no decision or comparison, prefer a clear value, status, or table over a chart. Remove elements that do not support those questions.
3. Set information hierarchy. Put the primary status and action first, then KPI context, trend or comparison, details, and secondary actions. Keep filters and the active period visible. Use a table when exact values or row-level actions matter.
4. Choose the least complex visual form. KPI for a current value, delta for comparison, line for time series, bars for category comparison/ranking, table for exact values or row actions, funnel only when stages and denominators are defined. Maps, pies, gauges, and dual axes only when the data genuinely requires them. Keep title, units, time range, scope, comparison basis, and freshness attached — no hover-only essential values.
5. Use honest scales and accessible encoding. Zero baseline for bars unless a documented exception is clearer; no distorted axes, unexplained smoothing, false precision, or truncated labels. Never communicate important differences through color alone — add labels, patterns, or direct annotations; provide a text/table alternative for meaningful charts.
6. Define a compact visual system. Reuse project tokens and components, keeping color meaning stable. When visual direction or shared styling needs work, use design-system for token decisions and conditional reference research; its source guide is the shared catalog, not a second dashboard-specific list. Research an unresolved interaction through user-flow examples, not decorative landing pages. Do not load galleries when existing project patterns answer the question.
7. Design every meaningful state. Cover loading, no data, insufficient data, error, stale/partial data, disabled/permission-limited actions, long labels or numbers, and values outside the expected range. Explain the next useful action and keep the layout stable.
8. Handle responsive behavior intentionally. Check desktop, tablet, and mobile layouts. Stack or reprioritize content before shrinking it; recheck long category names and large numbers. Allow horizontal scrolling only for genuinely wide data tables; never let the whole page overflow. Keep keyboard focus visible and respect reduced-motion preferences.
9. Critique before implementation. Remove decoration, redundant labels, cards, charts, or animation only where they do not improve comprehension or actionability. Do not impose a removal quota on an already clear interface.
10. Verify in the running app. A rendered check is part of the work, not optional follow-up: launch the real app (project run instructions, browser/DevTools or Playwright — never a source-only inspection), and on dynamic pages wait for the network to settle (e.g. networkidle) before reading the DOM. Inspect representative viewports (1440/1024/768/375px or closest supported), exercise navigation, period controls, filters, tabs, sorting, pagination, row actions, and dialogs, and check the state matrix from step 7 plus the browser console for errors. Fix confirmed issues and rerun the affected check; claim completion only after the rerun is clean. Record evidence: surface, viewport, path/state, observed result, pass|defect, location.