Dashboard Patterns
Practical patterns for dashboards that prioritise insight over widget walls.
01 — Foundation
Dashboards answer questions — not display everything
A wall of widgets is not insight. Prioritise what decision the screen supports.
Dashboards summarise status — sales, operations, health checks. They fail when every metric competes at equal volume, data loads unpredictably, and users cannot tell what changed or why it matters.
02 — Hierarchy
Visual hierarchy and scan paths
Lead with the primary metric; support with detail users can drill into.
- one primary focus per view — “Revenue this month”, not twelve equal cards
- group related metrics; use headings and landmarks for screen reader navigation
- tables for precision; charts for trend — see Data Visualisation
- responsive layouts that reflow without hiding critical numbers on mobile
03 — States
Loading, empty, and stale data
Partial failure should not blank the entire dashboard.
- per-widget loading — users see what is still fetching
- show last updated time when freshness matters
- widget-level errors with retry — not a single generic failure banner
- empty dashboards explain how to get data — see Empty States
04 — Interaction
Filters, drill-down, and performance
Dashboards are often filter-heavy — state must stay visible and shareable.
- date ranges and filters visible with reset — see Filtering and Sorting
- links to detail views for investigation — real navigation, not mystery clicks
- avoid loading megabytes of chart libraries for one number
- prefer server aggregates over shipping raw datasets to the browser
05 — Review
Before you approve
A short checklist for dashboards in code review.
- hierarchy guides attention; primary metric is obvious
- widgets load and fail independently with clear timestamps
- filters and links are accessible; performance is proportionate