Data viz best practices

Data Visualization Best Practices

A format-agnostic skill for reviewing or building charts, infographics, and dashboards. Works the same whether the input is code, a design file, a screenshot, or a plain description — the principles don't change with the tool.

Step 0: Which mode?

Figure this out from context before doing anything else. If it's not obvious, ask.

• Review mode — user has an existing chart/dashboard (image, code, file, or description) and wants feedback
• Build mode — user wants a new chart/dashboard created or wants help picking the right chart type

The Core Checklist (applies in both modes)

Run every visualization against these seven checks. Reference files have the depth; this is the fast pass.

1. Chart type fits the question. Does the chart type match what the data is actually trying to answer (comparison, trend, part-to-whole, distribution, relationship)? See references/chart-type-guide.md for the decision tree.
2. Data-ink ratio. Every visual element should carry information. Flag: 3D effects, heavy gridlines, redundant legends, decorative gradients, unnecessary borders.
3. Accessibility (WCAG AA). Non-negotiable, not a nice-to-have. See references/accessibility-checklist.md for full detail:
   • Text contrast ≥ 4.5:1, large text/graphical objects ≥ 3:1
   • Never encode meaning in color alone — pair with pattern, shape, position, or direct labels
   • Colorblind-safe palette (check for red-green and blue-yellow confusion)
   • Data available in a non-visual form (alt text, table, or caption) for anything conveying real information
4. Truthful scales. Y-axis starting at zero for bar charts unless there's a stated, visible reason not to. No dual axes that imply false correlation. No distorted 3D perspective. Axis choices are sometimes a genuine trade-off (e.g., a compressed range makes small real changes visible, but a living/growing dataset will outgrow a manually-tuned truncation and need re-checking every time new data lands). When it's a trade-off rather than a clear violation, don't just prescribe a fix — name the trade-off in plain language and ask what the user prioritizes.
5. Labeling clarity. Title states the takeaway, not just the topic ("Revenue grew 18% in Q2" beats "Q2 Revenue"). Axes labeled with units. Direct labels preferred over legends when there are ≤5 categories.
6. Consistent encoding. Same color = same category across every chart in a dashboard. Same scale conventions throughout. Design in monochrome first; add color only to encode meaning or highlight a focus area — not decoration.
7. Hierarchy (dashboards specifically). Most important metric gets the most visual weight and top-left/first position. Related charts grouped; unrelated ones separated.
8. "Compared to what?" A number alone has no meaning — pair current values with a baseline, target, prior period, or segment. For product/marketing metrics, pair volume (signups, sessions) with quality/efficiency (activation rate, conversion rate) so nobody optimizes volume alone.

Review Mode Workflow

1. Identify what the chart/dashboard is trying to communicate — ask if unclear.
2. Run the 7-point checklist above. For each item, mark: ✅ Pass / ⚠️ Minor issue / ❌ Fails.
3. Present findings as a short prioritized list — biggest impact first, not in checklist order. For each issue: what's wrong, why it matters, and the specific fix. For genuine trade-offs rather than clear violations, ask what the user is optimizing for instead of prescribing one answer (see Output Style).
4. Don't rewrite the whole thing unless asked — flag issues first, offer to fix.

Build Mode Workflow

1. Clarify the question the visualization needs to answer, and who's looking at it (technical audience vs. general audience changes density and annotation level). For a full dashboard (multiple charts, not one), use references/dashboard-strategy.md first — it covers audience/metric clarification, avoiding vanity metrics, and narrative structure before any chart gets picked.
2. Pick chart type using references/chart-type-guide.md.
3. Draft the visualization in whatever format the user needs (code or description).
4. Run the 7-point checklist against the draft before presenting it — don't wait for the user to catch accessibility or scale issues.
5. Note any deliberate tradeoffs (e.g., "I used a non-zero baseline here because X, but flagged it in the title").

Output Style

• Keep feedback concise and prioritized — lead with the 1-3 things that matter most, not an exhaustive audit dump.
• Use plain language for why something matters, not just what to change. Default to jargon-free: if a technical term (baseline, data-ink, encoding) is genuinely useful, define it in the same sentence rather than assuming it's known.
• When the fix is a specific value (contrast ratio, hex code, spacing), give the exact number, not "increase contrast."
• Distinguish clear violations from genuine trade-offs. A violation gets a direct fix. A trade-off (e.g., axis compression, chart density vs. simplicity, static vs. interactive) gets the trade-off named in plain terms plus a clarifying question about what the user is optimizing for — don't silently pick one side and present it as the only answer.

Reference Files

• references/chart-type-guide.md — decision tree for matching data shape to chart type
• references/accessibility-checklist.md — full WCAG AA specifics for data visualization, including contrast math and colorblind-safe palette options
• references/dashboard-strategy.md — audience/metric clarification, avoiding vanity metrics, narrative structure, and funnel-stage layout for multi-chart dashboards (draws on Tufte, Few, and Knaflic's dashboard/graphics principles)