So What Dashboard

So What? Dashboard

You are designing a decision artifact, not decorating charts.

Core chain:

Data -> Reader -> Decision -> Tension -> Evidence -> Interpretation -> Action -> Format -> Dashboard -> Critique

The user may bring a spreadsheet, CSV, pasted table, database export, Jira issues, HR data, KPI metrics, or rough notes. Your job is to help the reader decide, diagnose, compare, intervene, allocate resources, approve, refuse, or monitor.

This skill carries a chart library (references/chart-primitives.md) so that "build a dashboard" reliably produces a dashboard full of charts, not an essay with two charts bolted on. The discipline below exists because the easy path for any writer — human or model — is to narrate findings in prose. A decision dashboard earns its name by showing the evidence visually.

Use this skill when

• dashboards and KPI dashboards
• HR / people analytics dashboards
• performance, attendance, rewards, appraisal, recruitment, training, attrition, engagement, and operations dashboards
• executive dashboards and CHRO / CXO dashboards
• data storytelling pages and decision briefs built from data
• "make this data visual" requests where the real need is sensemaking

Do not use this skill for tiny CSS fixes, ordinary CRUD screens, or visual polish without data or decision stakes.

The rule

Never start from charts. Start from the decision. Then make the decision visible with charts.

Bad interpretation: "The user asked for a dashboard, so I should make charts."

Good interpretation: "The user asked for a dashboard, so I must discover which decision this data should support, then choose metrics and charts that serve that decision."

Phase 1: Inspect the data first

Before asking what to show, inspect the raw material and build a compact data profile:

• source type: CSV, Excel, JSON, database/API, screenshots, notes, or mixed
• rows and columns
• entities: employee, team, manager, department, candidate, ticket, account, learner, project
• time fields and grain: daily, weekly, monthly, event-level, snapshot
• categorical fields that enable segmentation
• numeric fields that enable scoring, trends, thresholds, or comparisons
• missing, duplicate, suspicious, or sensitive fields
• fields that look like decisions, outcomes, or interventions

If the data contains sensitive people information, recommend anonymization and avoid naming real individuals unless the user confirms it is appropriate.

Phase 2: Ask the decision question

If the user already named the decision, state it back and move on — do not re-interview them. Otherwise ask at most three questions:

1. Who is the primary reader?
2. What decision should this dashboard help them make?
3. What action is one step away if the signal is strong?

If the user is in a hurry, propose 4-6 candidate decision questions drawn from the data and ask them to pick one. Example:

I see employee, performance, attendance, award eligibility, manager, and contribution fields. This can support several dashboards:

1. Which 20 employees should receive the award, and who are the borderline cases?
2. Which departments are over- or under-represented in the shortlist?
3. Where is manager nomination inconsistent with contribution evidence?
4. Which high performers are at risk of being missed?

Which decision do you want the dashboard to support?

Phase 3: Select metrics like KPIs — but only if they serve the decision

For each candidate metric, test: Relevant (supports the decision), Measurable (present or derivable), Actionable (the reader can act on it), Timely (recent enough), Bounded (has a target, threshold, ranking, or cutoff), Simple (a non-analyst gets it fast).

Limit the dashboard to 5-7 core measures for the primary reader; push the rest into drill-downs, tabs, or an appendix. Include both outcome indicators (what happened) and driver indicators (what can be acted on). Demote any metric that is interesting but not decision-useful.

Phase 4: Surface the tension

Every strong dashboard has a tension. Write it in plain language before designing.

Strong: "One department over-indexes in the shortlist, but the dashboard must show whether that reflects stronger contribution evidence, manager nomination bias, or a small-sample effect."

Weak: "Award data needs to be visualized."

Common tensions: high performance but low visibility; high output but weak quality; high attendance but low contribution; strong score but policy ineligibility; over-representation by department or manager; strong aggregate hiding a weak cohort; a data-quality issue that could change the recommendation.

Phase 5: The format gate — three dials, asked once

After the decision and tension are clear, the dashboard still has three independent choices to make. Ask them together, in one short message, so the reader gets a fast "drop data → dashboard appears" experience rather than an interrogation. Recommend a default for each and let the user override.

Dial 1 — Density (always ask this one). How much should this lean on charts versus prose?

• Chart-led — most evidence is a chart; text is captions and the decision panel. Recommended default for most dashboards, and the right answer whenever the complaint is "not enough visuals."
• Balanced — charts and short explanatory paragraphs share the space. Good for mixed audiences.
• Text-led — narrative carries the argument; charts punctuate it. Use only when the reader explicitly wants a written brief.

Dial 2 — Render mode. How should the charts behave?

• Static — charts are inline HTML/CSS/SVG. Opens on any machine with no internet, prints and pastes into slides cleanly. Recommended for boardroom and classroom use, and the safe default when you do not know the room's wifi.
• Interactive — charts use Chart.js (hover, tooltips, animation). Better for exploration, but needs the CDN to load and a config that parses.

Dial 3 — Style. Which visual system? (Tokens live in references/design-system-options.md; chart theming in references/chart-primitives.md.)

• AI Violet (default) — the generic indigo/violet, glassy-card look most AI tools ship. Familiar and safe. In teaching contexts it doubles as a foil — "the dashboard everyone makes" — but keep that framing in the speaker notes, never on the artifact.
• Boardroom Ledger — sober cool-paper, serif headlines, rust accent. Strongest for approval and defensibility.
• Evidence Control Room — dark graphite, signal cyan, command-center feel. Strongest for live, operational, changing data.
• Decision Storyboard — editorial, soft paper, oxblood accent. Strongest for teaching, persuasion, and reveal-style dashboards.

Present it compactly, e.g.:

Three quick choices and I'll build it:

1. Chart density — Chart-led / Balanced / Text-led? (I suggest chart-led.)
2. Static or interactive? (I suggest static — opens anywhere, prints clean.)
3. Style — AI Violet (default), Boardroom Ledger, Evidence Control Room, or Decision Storyboard? (For a CHRO approval, I'd pick Boardroom Ledger.)

If the user supplies one or more *-DESIGN.md files, treat each as a fixed style contract and build one dashboard variant per file, so the same decision can be compared across grammars. Do not collapse a supplied design file into a theme picker.

Phase 6: Write design.md before building

Write a one-page design.md and treat it as the governing contract. Include:

• artifact title that names the decision, not the department
• primary and secondary readers
• decision question and central tension
• key metrics and why each belongs
• what the dashboard will refuse to conclude
• the three format choices (density, render mode, style) and why
• information hierarchy: first read, second read, third read
• the chart manifest (Phase 7)
• chart-headline rule: every chart gets a sentence saying what it means
• accessibility / responsiveness notes

If the AI Violet default is being used as a teaching foil, that observation belongs here (or in speaker notes), never on the dashboard. The skill's standing rule holds: the artifact shows data, inference, action, and refusal — not commentary about itself.

Phase 7: Plan the charts first — the chart manifest

This is the step that stops a dashboard from drifting into prose. Before writing any HTML, list the charts. Write a small table — one row per evidence block:

Minimum rows by density: chart-led ≥ 5, balanced ≥ 3, text-led ≥ 2. If you cannot fill the floor from the decision's evidence, the dashboard is under-scoped — find more decision-relevant cuts of the data rather than padding with text. Each "claim" column must be a finding, not a label ("Department seats" is a label; "Engineering takes 8 of 20 seats" is a claim).

Phase 8: Build the dashboard

Read references/chart-primitives.md and paste its theme layer for the chosen style, then build each manifest row with the matching primitive. Use its horizontal-first layout skeleton (.dash → KPI row of four → full-width primary → 3-column details) and follow the Polish & layout craft checklist there — consistent .cards, breathing room, one type hierarchy, tabular numbers, styled tooltips. Polish is not decoration; it is what makes a board reader trust the numbers. Default to a single-page HTML artifact unless the user asked for another format.

Structure:

1. Frame — what this dashboard is for and who should act. Keep it to a line or two; let charts carry the first screen, not a long lede.
2. Lede — two or three sentences naming the main truth, the tension, and the decision.
3. Decision panel — recommended action · confidence · what could change the recommendation · what not to decide yet.
4. Evidence blocks — the charts from the manifest. In chart-led mode every evidence block renders a chart; a raw data table belongs in a collapsed audit appendix, not as primary reading. Each chart carries a claim headline, not a generic title.
5. Interpretation layer — annotations, caveats, footnotes, suspicious-data flags.
6. Action layer — next actions, owners, review cadence, data-quality fixes.

Keep process scaffolding off the screen. Labels like "Chapter 01", "the grid exposes…", or "this dashboard should…" belong in design.md or the lesson plan. The screen shows data, inference, recommended action, and the caveat/refusal.

Default outputs: design.md, dashboard.html (or a variant per supplied design file), and optionally decision-memo.md and data-quality-notes.md.

Phase 9: Chart choice rules

Choose charts by the question they answer (full snippets and a lookup table are in references/chart-primitives.md):

• ranking -> sorted horizontal bars
• two shares compared -> comparison bars
• part-to-whole -> 100% stacked bar (avoid donut unless the split is 2-3 ways)
• flow / funnel -> funnel or stepped conversion
• target / status -> bullet vs target
• cohort comparison -> heatmap or grouped bars
• distribution -> histogram or score strip
• anomaly / two variables -> score scatter
• trend -> line or sparkline
• one headline number -> KPI / delta tile

Avoid: decorative pie/donut for complex comparisons, too many equal-weight cards, unlabeled color meaning, charts without comparison points, and dashboards organized by database-table names.

Phase 10: Critique before final — and count the charts

Before responding, score the artifact. The first check is mechanical on purpose, because "enough charts" is otherwise a feeling that quietly loses to prose:

• Chart count: count the rendered chart elements (each .chart-block, <canvas>, or <svg class> figure). Is it at or above the density floor (chart-led ≥ 5, balanced ≥ 3, text-led ≥ 2)? If not, add charts before finishing — do not pad text.
• If interactive: does every <canvas> sit in a fixed-height wrapper so it actually paints? A Chart.js config typo renders a blank box — verify, ideally by opening the file.
• Does the first screen name the decision?
• Does every chart have a claim headline, not a label?
• Is the chosen style visibly applied (one coherent palette, not a rainbow)?
• Does the eye know what to read first, second, third?
• Are 5-7 core signals respected, with the rest demoted?
• Does color signal meaning rather than decoration?
• Are uncertainty, missing data, and refusal visible?
• Does it end with action — owners and cadence?
• Would a senior reader know what to do in 30 seconds?

Revise before final if the artifact is pretty but not decision-ready, or decision-ready but thin on charts. references/dashboard-quality-rubric.md has the scored version of this check, with chart density and "charts render" as hard gates.

Example trigger

User: "Build a dashboard from this award shortlist Excel."

Response shape: inspect the workbook → say what decisions it can support → confirm the decision question → ask the three format dials in one message → write the chart manifest and design.md → build the chart-rich dashboard → provide decision memo / data-quality notes.

Sample demo dataset

This skill includes a synthetic 300-employee HR awards dataset for demos, class exercises, and safe HR dashboard practice:

• assets/sample-data/anant_awards_300.csv
• assets/sample-data/anant_awards_insight_guide.md

It supports the decision: "Which 20 employees should receive the award, and which cases need review before certificates are generated?" It is deliberately seeded with traps — department over-representation, high performers excluded by tenure, manager-nomination inconsistency, duplicated contribution text, attendance-vs-contribution conflicts, and high scores with data-quality warnings — so a naive "top 20 by score" dashboard would be wrong.

Teaching note (for the room, not the artifact): building the same decision in AI Violet and then in Boardroom Ledger or Decision Storyboard makes the point that the generic look is not neutral — it flatters charts that do not answer the decision. Run the violet version first as the foil, then show how a decision-first style and a chart-led density make the shortlist defensible. Keep that narrative in your notes; the dashboards themselves stay clean.

The point throughout: a dashboard should answer a decision, and it should show that answer in charts — not merely describe it.