# Data Viz Best Practices

> Applies data visualization best practices to any chart, infographic, or dashboard, whether reviewing existing work or building something new. Covers chart type selection, accessibility (WCAG AA contrast, colorblind-safe palettes, non-color encoding), truthful scales, labeling clarity, and dashboard layout/hierarchy. Format-agnostic — works whether the visualization is code (matplotlib, D3, Chart.js), a design tool file (Figma, Canva, PowerPoint), a screenshot, or just a description of one. Use this skill any time the user mentions charts, graphs, infographics, dashboards, data visualization, "does this chart work," "review my viz," or wants help picking a chart type or improving one — even if they don't use the word "visualization" explicitly.

- Skill: `callahkate/data-viz-best-practices` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add callahkate/data-viz-best-practices`
- Raw SKILL.md: https://api.skillmd.com/api/skills/callahkate/data-viz-best-practices/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Design & Media
- Author: callahkate (https://skillmd.com/u/callahkate)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/callahkate/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)