design-dashboards

A dashboard is a focused answer to a specific question for a specific audience. "Dashboard" names the artifact as a whole; "screen" refers specifically to the physical viewport a reader scans — used only for statements about scanning patterns, fold position, and viewport constraints. Dashboards fail when they are built for available data instead of a named decision — the result is a wall of metrics nobody uses. Every rule below derives from three commitments:

• Serve a decision, not a dataset. Every tile must map to a question its readers actually ask; anything that maps to nothing gets cut.
• Answer at a glance. A reader should grasp "on track or not, and where to look next" within about five seconds, without searching or filtering.
• Every pixel earns its place. If an element — color, gridline, icon, decimal place, third dimension — does not help the reader understand faster, remove it (Tufte's data-ink principle). Density is not the enemy; junk is. A dense, junk-free dashboard beats a sparse, decorated one.

These rules apply identically when designing from scratch and when auditing an existing dashboard — auditing is holding what exists against the same commitments and reporting each violation with its fix.

Establish the brief

Before any visual decision, establish who reads this dashboard, what decision they make from it, and how fast they need the answer. If the user hasn't stated these, ask rather than infer — every choice that follows, starting with classification below, depends on them.

Classify the dashboard first

The dashboard's type determines refresh rate, density, and interactivity before any tile is drawn. Pick the row that matches the audience and question; resist blending types on one dashboard — a dashboard serving executives and analysts simultaneously serves neither.