dashboard-designer

What this skill does

# Dashboard Designer

## Overview
This skill provides a structured approach to dashboard design—from defining the right KPIs and audience through information architecture, visual hierarchy, color coding, and tool selection. A well-designed dashboard surfaces the right information to the right person at the right time. This skill combines data visualization principles with UX thinking to create dashboards that drive decisions, not just display data.

## When to Use
- You're building a new dashboard and need to decide what to show and how to arrange it
- An existing dashboard is cluttered, ignored, or confusing to users
- You need to choose between BI tools (Tableau, Power BI, Looker, Grafana)
- You want to design a KPI framework before building the technical implementation
- You're presenting data to an executive audience and need to structure the narrative

## When NOT to Use
- Writing SQL queries to power the dashboard (use sql-analyst skill)
- Building chart code in Python/JavaScript (use chart-builder skill)
- Creating a static report or slide deck (use a presentation skill)
- Designing the underlying data model or warehouse (use a data engineering skill)

## Quick Reference
| Design Principle | Rule |
|-----------------|------|
| Visual hierarchy | Most important KPI top-left; details bottom-right |
| White space | 15–20% of dashboard area; prevents cognitive overload |
| Color coding | Max 4–5 colors; use red/green for status, grey for context |
| Chart density | Max 6–8 charts per screen; prefer fewer, larger charts |
| KPI count | Executive: 3–5 KPIs. Operational: 8–12. Analyst: unlimited |
| Text | Titles as insights ("Revenue Up 12%"), not labels ("Revenue") |
| Refresh rate | Real-time for ops, daily for management, weekly/monthly for strategy |
| Interactivity | Filters at top; drill-down by click; default to most common view |
| Mobile | Stack charts vertically for mobile; limit to top 3 KPIs |
| Accessibility | Colorblind-safe palette; min contrast ratio 4.5:1 |

## Instructions

### Step 1: Define the Audience and Purpose
Answer these questions before designing anything:
1. **Who uses this dashboard?** Executive, team manager, analyst, engineer, customer?
2. **What decision does it inform?** ("Should we increase marketing spend in the West region?")
3. **How often will they look at it?** Real-time (ops), daily, weekly, monthly?
4. **What action can they take?** If no action → reconsider whether a dashboard is the right format.

**Dashboard archetypes:**
| Type | Audience | Refresh | KPI Count | Example |
|------|----------|---------|-----------|---------|
| Strategic | C-suite, VPs | Weekly/Monthly | 3–5 | Company health scorecard |
| Operational | Team leads, managers | Daily | 8–15 | Sales pipeline dashboard |
| Analytical | Data analysts | On-demand | Unlimited | Cohort analysis explorer |
| Real-time monitoring | Engineers, support | Live | 10–20 | System uptime & error rates |

### Step 2: Select the Right KPIs
A KPI must be:
- **Actionable**: the viewer can change it based on what they see
- **Timely**: available at the frequency the dashboard refreshes
- **Comparable**: has a target, benchmark, or prior period to compare against
- **Unambiguous**: has one clear definition shared by all stakeholders

**KPI selection process:**
1. List 20 metrics the audience cares about
2. Filter to metrics the audience can act on (eliminate vanity metrics)
3. Group remaining into 3–5 themes (e.g., Revenue, Customers, Operations, Quality)
4. Pick 1–3 primary metrics per theme
5. Define calculation, data source, and owner for each

**KPI tiers:**
- **Level 1 (headline)**: 3–5 KPIs shown large at the top (Total Revenue, MAU, NPS)
- **Level 2 (supporting)**: 6–10 charts providing context (by region, by product, trend)
- **Level 3 (detail)**: Tables or drill-downs for investigation

### Step 3: Information Architecture (Layout Patterns)

**F-pattern layout** (most common): Users scan top-left → top-right → down the left.
```
┌─────────────────────────────────────────────────────┐
│  KPI 1        KPI 2        KPI 3        KPI 4       │  ← Headline KPIs
├───────────────────────┬─────────────────────────────┤
│                       │                             │
│  Primary chart        │  Secondary chart            │  ← Primary context
│  (e.g. revenue trend) │  (e.g. by region)           │
│                       │                             │
├───────────────────────┴─────────────────────────────┤
│  Detail chart 1    │  Detail chart 2  │  Table      │  ← Supporting detail
└────────────────────┴──────────────────┴─────────────┘
```

**Z-pattern layout** (executive dashboards): Fewer elements, high-level narrative flow.

**Grid layout** (operational dashboards): Equal-sized tiles arranged in rows.

### Step 4: Visual Hierarchy Principles
1. **Size**: Larger = more important. Make the most critical KPI card the biggest element.
2. **Position**: Top-left corner gets most attention. Put the hero metric there.
3. **Color**: Use strong color (blue, orange) for primary data; grey for all context.
4. **Typography**: Metric values large (24–32pt), labels small (10–12pt), titles medium (14–16pt).
5. **White space**: Empty space is not wasted—it guides the eye and reduces fatigue.

### Step 5: Color Coding System
Establish a consistent color language:
- 🟢 **Green**: good, on track, above target
- 🔴 **Red**: bad, alert, below target
- 🟡 **Yellow/Orange**: caution, approaching threshold
- 🔵 **Blue**: primary data, neutral information
- ⬜ **Grey**: secondary data, prior period, context

**Colorblind-safe alternative palette:**
- Use: `#0077BB` (blue), `#EE7733` (orange), `#009988` (teal), `#CC3311` (red)
- Avoid: pure red + pure green together without texture or label differentiation

### Step 6: BI Tool Selection Guide
| Tool | Best For | Strengths | Limitations |
|------|----------|-----------|-------------|
| **Tableau** | Enterprise BI, complex visualizations | Powerful viz, strong community, drag-and-drop | Expensive, steep learning curve |
| **Power BI** | Microsoft-centric orgs, self-service BI | Deep Excel/Azure integration, affordable | Less flexible layout, DAX complexity |
| **Looker** | Data-team-driven, engineering-heavy orgs | LookML modeling, governed metrics, Git integration | Requires data engineers, expensive |
| **Grafana** | Real-time monitoring, engineering metrics | Live data, alerting, open source | Not for business users, limited chart types |
| **Metabase** | Small teams, SQL-first analytics | Open source, easy SQL → dashboard | Limited advanced features |
| **Google Data Studio (Looker Studio)** | Google Workspace users, quick sharing | Free, easy to share, Google Sheets integration | Limited transformations, basic visuals |
| **Retool** | Operational dashboards with actions | CRUD operations, internal tools | Requires developer to set up |

**Quick selector:**
- Startup with small team → Metabase or Looker Studio
- Enterprise with existing Microsoft stack → Power BI
- Data team building governed metrics layer → Looker
- Engineering monitoring → Grafana
- Best-in-class viz + large budget → Tableau

### Step 7: Dashboard Quality Checklist
Before publishing, verify:
- [ ] Every chart has a title stating the insight (not just the metric name)
- [ ] Every KPI has a comparison value (vs. target, vs. last period)
- [ ] Color coding is consistent throughout
- [ ] Date range is clearly labeled and user-controlled
- [ ] Filters are at the top and default to the most common view
- [ ] All numbers are formatted with appropriate precision (revenue: $1.2M not $1,234,567.89)
- [ ] Data source and refresh date are visible in a footer
- [ ] Mobile layout tested (if relevant)

## Examples

### Example 1: Design a Sales Performance Dashboard
**Input:** "I need a dashboard for our VP of Sales to review weekly. We care about revenue, pipeline health, and team performance."

**Audience analysis:** VP of Sales — executive level — weekly review — strate