Dashboard Design
Designing dashboards that answer questions rather than display data —choosing layout, density, and interaction so a user can find the answer in 30 seconds, not 30 minutes.
Why
A dashboard is not a data dump; it is a decision tool, and the difference is whether the user can act on what they see. A dashboard with 40 widgets, no hierarchy, and no context forces the user to hunt for the number, remember what it was last week, and mentally compute the trend —by the time they have an answer, the decision window has closed. A well-designed dashboard answers a specific question ('is growth on track this week?') with a primary metric, a comparison (vs last week, vs target), and a trend (sparkline or small chart), all visible without scrolling. The design choices that make this work are: one primary question per dashboard (not five), comparison context on every number (a number without a baseline is noise), progressive disclosure (summary first, drill-down on click), and consistent time windows (mixing 7-day and 30-day on the same dashboard causes false alarms). The most common failure is the 'executive request' dashboard —the CEO asks for 'all the metrics' and the team builds a 60-widget wall, which the CEO never reads because it has no narrative. The fix is to ask the CEO what decision they make each week and build the dashboard around that decision, with 5-7 widgets that answer the 5-7 questions the decision requires.
When
When building any new dashboard. When an existing dashboard is not being read (check usage analytics). When stakeholders request 'more metrics' on an existing dashboard. Before adding the 10th widget to any dashboard.
How
1. Start with the decision, not the data: ask the dashboard's primary user "what decision do you make from this dashboard, and how often?" —the answer defines the dashboard's purpose, refresh cadence, and required widgets
2. Define the primary question in one sentence: "Is weekly trial-to-paid conversion on track?" —every widget on the dashboard must serve this question or a direct sub-question
3. Choose 5-7 widgets, no more: the primary metric (trial-to-paid %), the comparison (vs last week, vs target), the trend (8-week sparkline), the decomposition (by channel, by plan), and the alert (if below target, flag red)
4. Give every number a baseline: "3.2%" is noise; "3.2% (vs 2.8% last week, target 3.5%)" is a signal —the baseline can be last period, target, or forecast, but it must be present
5. Use progressive disclosure: the top row answers the primary question in 5 seconds; clicking a widget opens a drill-down with the decomposition, the individual rows, and the ability to filter
6. Standardize the time window: if the primary metric is weekly, every widget on the dashboard is weekly —mixing 7-day and 30-day on the same view causes the user to compare incomparable numbers
7. Choose the right chart for the question: a single number with a sparkline for 'is it on track', a bar chart for 'which segment is biggest', a line chart for 'what is the trend', a table for 'which rows need attention' —never a pie chart (humans cannot compare angles)
8. Add annotations for context: when a metric spikes or drops, an annotation explains why ("deployed pricing change on Sep 15") —without it, the user guesses and the guess is often wrong
9. Set a refresh cadence that matches the decision: a weekly decision needs a daily refresh (to catch issues early), a real-time decision needs a streaming dashboard, a quarterly decision needs a weekly refresh —over-refreshing wastes compute, under-refreshing misses the window
10. Measure dashboard usage: if a widget is never clicked or a dashboard is never opened, remove it —a dashboard is a living tool, not a permanent monument, and unused widgets add noise for everyoneExample
# Dashboard: Weekly Growth Review
Primary user: Head of Growth
Decision: "Is trial-to-paid conversion on track this week, and if not,
which channel is underperforming and needs budget adjustment?"
Cadence: reviewed every Monday, refreshed daily
Layout (7 widgets, 1 primary question):
+-------------------------------------------------------+
| Trial-to-Paid: 3.2% (vs 2.8% last week, target 3.5%) | <- primary
| [sparkline: 2.1 2.4 2.6 2.8 3.0 2.9 3.2] [RED: below] |
+-------------------+-------------------+---------------+
| By channel | By plan | Top movers |
| organic: 3.8% +0.4| Pro: 3.5% +0.2 | +paid-search |
| paid: 2.1% -0.6| Team: 4.8% +0.8 | +0.8% |
| social: 3.4% +0.1| Free: -- -- | -social-ads |
| email: 4.2% +0.3| | -0.6% |
+-------------------+-------------------+---------------+
| Annotations: Sep 18: paid-search budget cut 20% |
| Sep 20: new social creative launched |
+-------------------------------------------------------+
Drill-down (click "By channel"):
- per-channel 8-week trend with conversion count and CAC
- ability to filter by cohort, plan, country
- link to the experiment that may have caused the change
Design choices:
- 7 widgets, not 40: serves 1 question, not "all metrics"
- every number has a baseline (vs last week, vs target)
- sparkline shows trend without taking space
- RED flag because 3.2% < 3.5% target (action: investigate paid)
- annotations explain the likely cause (budget cut on Sep 18)
- drill-down on click, not on the main view (progressive disclosure)
Usage analytics (last 4 weeks):
- opened 22/22 Mondays (100% adherence)
- drill-down used 18/22 times (paid channel investigated)
- dashboard load: 1.2s (acceptable for daily refresh)Common Problems
- ⚠Building the 'all metrics' dashboard with 40 widgets because the executive asked for everything —the executive never reads it because it has no narrative; the fix is to ask what decision they make and build 5-7 widgets around that decision.
- ⚠Showing numbers without baselines —'3.2%' is noise because the user does not know if it is good, bad, or unchanged; every number needs a comparison (vs last period, vs target) to be a signal.
- ⚠Mixing time windows on the same dashboard —a 7-day conversion next to a 30-day retention causes false alarms because the numbers are not comparable, and the user cannot tell which window each number uses.
- ⚠Using pie charts to show composition —humans cannot compare angles accurately, so a 33% vs 35% slice looks identical; use a bar chart or a table where the comparison is linear.
- ⚠Never removing widgets —a dashboard accumulates widgets over time as stakeholders request additions, and after 2 years it has 40 widgets of which 30 are never read; measure usage and prune ruthlessly.
Best Practices
- ✓Start every dashboard from the decision it serves —ask the primary user what decision they make and how often, and build 5-7 widgets that answer the questions that decision requires; a dashboard without a stated decision is a data dump.
- ✓Give every number a baseline (vs last period, vs target, vs forecast) —a number without comparison is noise, and the baseline is what turns a number into a signal that the user can act on.
- ✓Use progressive disclosure: the top row answers the primary question in 5 seconds, and clicking a widget opens the drill-down —this keeps the main view clean while making detail accessible, and it respects the user's attention.
- ✓Standardize the time window across the dashboard and state it in the title —'Weekly Growth Review (7-day windows)' prevents the user from comparing a 7-day number to a 30-day number and drawing a false conclusion.
- ✓Measure dashboard usage and prune widgets that are never clicked —a dashboard is a living tool, and unused widgets add load time and noise for every user; quarterly pruning keeps the dashboard focused on what matters.