Data Visualization Engineering
Use this skill when building, reviewing, or repairing an analytical chart, dashboard, or interactive data view. Start with the user’s decision or claim; not a chart type, library, or visual style.
Core workflow
- State the task: comparison, trend, distribution, composition, relationship, location, flow, or a precise lookup
- State the claim the view is allowed to make, its population, measure, time window, unit, and transformation. If any are unknown, expose that uncertainty rather than implying certainty
- Choose the least-complex encoding that lets the intended audience verify the claim. Keep scales, baselines, binning, sorting, filters, and annotations inspectable
- Define the rendering and state contract before implementation: data shape, domains, interaction state, loading/error/empty states, ownership, URL representation, and exportable data
- Build the accessible mobile path alongside the graphic: semantic heading and summary, keyboard-equivalent interactions, non-color cues, a responsive layout, and an accessible text, table, or data-download fallback suited to the task
- Test the data, visual encoding, interactions, export, and assistive path as separate layers
- Evaluate recorded evidence against the stated claim and delivery contract; iterate on data, encoding, interaction, or assistive defects before shipping
Non-negotiable truthfulness
- Do not use a truncated quantitative axis unless the design makes the truncation unmistakable and the chart type still supports comparison. Bar lengths normally require a zero baseline
- Label units, denominators, dates, aggregation, adjustments, exclusions, and source. Distinguish observed values, estimates, forecasts, and targets
- Show uncertainty where it materially changes the conclusion: intervals, ranges, sample size, missingness, or an explicit note that uncertainty is unavailable. Never turn a model output into a measured fact
- Do not encode a ranked claim with unsorted data, a time claim with an unordered axis, or a part-to-whole claim with categories that do not share a whole
- Preserve the raw values used by the visualization so users can inspect or export them
Follow-up reads
| Need |
Read |
When |
| Choose a chart and disclose uncertainty |
references/chart-selection-and-uncertainty.md |
Before selecting marks, scales, or a narrative claim |
| Select a renderer and own React state |
references/renderer-and-state-contract.md |
Before writing a chart component or cross-route interaction |
| Verify behavior, accessibility, and export |
references/visualization-qa.md |
Before shipping or reviewing a visualization |
Delivery contract
Deliver the decision question, chart title/subtitle, source and data currency, visible caveats, accessible summary, and an accessible text, table, or data-download fallback suited to the task. Make controls reversible and keyboard-operable. Keep a shareable URL limited to stable, user-meaningful view state; never serialize secrets, raw records, or ephemeral hover state.
For React, put server data at the route/data boundary, shared filters and selections in the nearest common owner or URL, and local rendering details inside the chart. Do not duplicate the same state across route, store, and component.
Authoritative starting points
1---2name: data-visualization-engineering3description: Use when building or reviewing truthful, accessible data visualizations, charts, dashboards, or React visualizations.4license: AGPL-3.0-or-later5---67# Data Visualization Engineering89Use this skill when building, reviewing, or repairing an analytical chart, dashboard, or interactive data view. Start with the user’s decision or claim; not a chart type, library, or visual style.1011## Core workflow12131. State the task: comparison, trend, distribution, composition, relationship, location, flow, or a precise lookup142. State the claim the view is allowed to make, its population, measure, time window, unit, and transformation. If any are unknown, expose that uncertainty rather than implying certainty153. Choose the least-complex encoding that lets the intended audience verify the claim. Keep scales, baselines, binning, sorting, filters, and annotations inspectable164. Define the rendering and state contract before implementation: data shape, domains, interaction state, loading/error/empty states, ownership, URL representation, and exportable data175. Build the accessible mobile path alongside the graphic: semantic heading and summary, keyboard-equivalent interactions, non-color cues, a responsive layout, and an accessible text, table, or data-download fallback suited to the task186. Test the data, visual encoding, interactions, export, and assistive path as separate layers197. Evaluate recorded evidence against the stated claim and delivery contract; iterate on data, encoding, interaction, or assistive defects before shipping2021## Non-negotiable truthfulness2223- Do not use a truncated quantitative axis unless the design makes the truncation unmistakable and the chart type still supports comparison. Bar lengths normally require a zero baseline24- Label units, denominators, dates, aggregation, adjustments, exclusions, and source. Distinguish observed values, estimates, forecasts, and targets25- Show uncertainty where it materially changes the conclusion: intervals, ranges, sample size, missingness, or an explicit note that uncertainty is unavailable. Never turn a model output into a measured fact26- Do not encode a ranked claim with unsorted data, a time claim with an unordered axis, or a part-to-whole claim with categories that do not share a whole27- Preserve the raw values used by the visualization so users can inspect or export them2829## Follow-up reads3031| Need | Read | When |32| --- | --- | --- |33| Choose a chart and disclose uncertainty | `references/chart-selection-and-uncertainty.md` | Before selecting marks, scales, or a narrative claim |34| Select a renderer and own React state | `references/renderer-and-state-contract.md` | Before writing a chart component or cross-route interaction |35| Verify behavior, accessibility, and export | `references/visualization-qa.md` | Before shipping or reviewing a visualization |3637## Delivery contract3839Deliver the decision question, chart title/subtitle, source and data currency, visible caveats, accessible summary, and an accessible text, table, or data-download fallback suited to the task. Make controls reversible and keyboard-operable. Keep a shareable URL limited to stable, user-meaningful view state; never serialize secrets, raw records, or ephemeral hover state.4041For React, put server data at the route/data boundary, shared filters and selections in the nearest common owner or URL, and local rendering details inside the chart. Do not duplicate the same state across route, store, and component.4243## Authoritative starting points4445- [W3C WCAG 2.2](https://www.w3.org/TR/WCAG22/)46- [WAI-ARIA Authoring Practices Guide](https://www.w3.org/WAI/ARIA/apg/patterns/)47- [React: sharing state between components](https://react.dev/learn/sharing-state-between-components)48- [WHATWG URL Standard](https://url.spec.whatwg.org/)49- [MDN Canvas API](https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API)50- [Khronos WebGL specification](https://registry.khronos.org/webgl/specs/latest/1.0/)
anntnzrb