Charts and Data Visualization

A chart answers one question, drawn so the answer is legible before the labels are read. Default posture: pick the mark from the question and the shape of the data, give it the least chrome that stays readable, and make everything derived from the data move together when the data changes. Most bad charts are not ugly — they are a mark that cannot express the question (a pie for a comparison, a line across a gap, a truncated bar), wrapped in gridlines and a legend that make the failure harder to see.

The boundary with the siblings that look like this one: rows and cells are dense-ui; axes and marks are here. motion owns every curve and duration — this skill owns only which values share one interpolation. Hues, ramps, and contrast ratios come from color; here we decide what a channel encodes, not what it is set to.

Draw with whatever the project already draws with. Check for an existing charting layer — Recharts, visx, Chart.js, ECharts, D3, hand-rolled SVG — and work inside it, taking series colors from the project's palette tokens rather than the library's defaults, which are the loudest tell that nobody chose them. A chart fix never justifies a second charting library, and library selection is out of scope unless explicitly asked for (pick-library).

Quick Reference

Decision: which mark?

Rank channels by how precisely a reader decodes them — position, then length, then angle, then area, then color — and give the question's answer to the highest one available.