Good data visualization comes down to a short list of rules: match the chart to the question, spend your ink on data rather than decoration, use colour to encode meaning, keep axes honest, and put the takeaway in the title. Everything else is refinement. A chart succeeds when a reader who was not in the analysis can look at it for five seconds, state the finding correctly, and know where the number came from — and it fails when they have to ask what they are looking at.

Below are ten practices worth making standard, each with what it means, how to apply it, and the failure it prevents. They apply whether you are building a board slide, a live dashboard, or a chart an AI agent generated from a query.

1. Choose the Chart That Answers the Question

Chart choice is not a style decision; it is the first analytical decision. Start by writing the question in one sentence, then pick the form that answers it. Comparison across categories wants bars. Change over time wants a line. Composition of a whole wants a stacked bar or, sparingly, a pie. Distribution wants a histogram or box plot. Relationship between two variables wants a scatter plot.

The most common error is reaching for a pie chart when the question is really a comparison — humans read length far more accurately than angle, so five bars beat five slices almost every time. If you are unsure, build two versions and see which one you can describe in a single sentence. Our guide to choosing the right chart and the reference on types of graphs and when to use them go deeper.

2. Maximise the Data-Ink Ratio

Edward Tufte's principle still holds: most of the ink on a chart should represent data. Drop 3D effects, heavy borders, background fills, gradient shading, and redundant legends. Lighten gridlines until they guide the eye without competing with the data. Remove the y-axis line entirely when labels alone do the job.

The test is subtraction: for each element, ask whether removing it loses information. If not, remove it. Then squint at the chart from a few feet away — the main pattern should still be legible. Financial publications are the reference standard here precisely because their charts look almost bare. For the opposite lesson, our collection of bad data visualization examples is instructive.

3. Use Colour to Encode Meaning, Not Decoration

Treat colour as a data channel. There are three legitimate uses and one common misuse. Categorical palettes assign distinct hues to separate groups — keep this under about seven categories, because beyond that nobody can match legend to chart. Sequential palettes run light to dark for quantitative intensity. Diverging palettes use two hues around a meaningful midpoint, such as profit and loss.

The misuse is colouring every series brightly because the tool offers a rainbow. A more effective pattern: render everything in neutral grey and reserve one saturated accent for the series that carries the finding. Test in greyscale — if the message survives, colour is doing enhancement rather than load-bearing work — and never rely on hue alone, since red-green colour vision deficiency affects a meaningful share of any audience.

4. Keep Axes and Baselines Honest

Axis choices change what a reader concludes, which makes them an integrity question rather than a formatting one. Bar charts must start at zero, because the bar's length is the encoding — truncating the baseline exaggerates small differences dramatically. Line charts may start elsewhere when the variation is the point, but the axis should be labelled clearly enough that no one misreads a 2% move as a collapse.

Use a logarithmic scale when data spans orders of magnitude, and say so on the chart. If you truncate an axis, mark the break visually. Be sceptical of dual axes: two y-axes on one chart can be scaled to imply almost any relationship, and readers rarely check. When you need to compare two differently scaled series, indexing both to 100 at a start date is usually more honest.

5. Order and Label So the Chart Reads Itself

Default alphabetical ordering hides the finding. Sort categorical bars by value unless the categories have a natural sequence (days, sizes, stages of a funnel), in which case use that. Consistent ordering across a set of related charts lets readers compare without re-orienting each time.

Label directly where you can. A line labelled at its end point removes the legend-to-line matching a reader would otherwise do. Always state units on the axis — "Revenue (USD millions)" rather than "Revenue" — and include the data source and the as-of date somewhere on the chart. The as-of date is the detail most often skipped and most often needed six months later.

6. Provide Context and Reference Points

A number alone cannot be judged. The reader's first question is always "compared to what?", and the chart should answer it before they ask. Add a target line, a prior-period series, an industry benchmark, or shaded bands showing healthy, warning, and critical ranges.

Context also prevents overreaction. A metric that swings 15% every quarter looks alarming until the chart shows the last eight quarters. Annotate significant events — a pricing change, an outage, a campaign launch — directly on the timeline, so a spike is explained where it appears rather than in a footnote nobody reads.

7. Put the Takeaway in the Title

Write the title as the finding, not the subject. "Q3 revenue grew 15% on enterprise expansion" does more work than "Q3 revenue," and it survives being screenshotted into a Slack thread without the surrounding narrative. The chart then supports a claim rather than inviting the reader to derive one.

This is the simplest form of data storytelling and the highest-leverage one. For fuller narratives — a report or a deck — sequence charts as an argument: establish context, show the change or conflict, present the finding, then state what should happen next. Use annotations to carry the reader between steps instead of relying on spoken commentary that disappears when the file is forwarded.

8. Design for Accessibility and for the Actual Device

A chart that cannot be read has no analytical value, however elegant. Check colour contrast, use patterns or direct labels in addition to hue, keep font sizes legible at final display size, and provide alt text or a text summary for screen readers. These are not concessions; charts designed this way are clearer for everyone.

Then design for where it will be seen. Dashboards viewed on phones need simplified views, vertical layouts, and touch targets big enough to hit. Printed and PDF versions must work without interactivity or hover tooltips. Presentation charts need large type and one idea per slide. A dense multi-panel view that works on a 27-inch monitor fails completely in all three contexts. Our guide to designing dashboards for mobile users covers the responsive patterns.

9. Layer Detail With Progressive Disclosure

Showing everything at once guarantees nothing is read. Follow the classic sequence: overview first, then zoom and filter, then details on demand. The landing view carries the single most important finding; filters and drill-downs let a curious reader go deeper; tooltips hold the exact values.

This matters most for dashboards, where the temptation is to add one more chart for one more stakeholder. Every addition dilutes the rest. If a chart has no owner and no decision attached to it, cut it. A well-scoped dashboard answers a small number of recurring questions well; a comprehensive one answers none of them.

10. Make the Data Behind the Chart Inspectable

The practice most lists omit is provenance. A chart is a claim about data, and its credibility depends on whether someone can check it. In practice that means anyone should be able to get from the visual to the query that produced it, see the filters applied, and know when it last refreshed.

This is now a tooling question as much as a design one. When charts are generated from queries — by an analyst or by an AI agent — the useful property is that the chart and the query stay bound together, so changing the SQL updates the chart automatically and no one is looking at a visual whose underlying logic quietly moved. Querio works this way: every answer is produced as real SQL and Python in a reactive notebook with connected cells, charts are built on Vega-Lite via Altair, and dashboards are assembled from those notebooks with their layout as code. Boards can be tagged by trust level — trusted, experimental, team-specific — so a reader knows whether they are looking at a validated metric or someone's exploration. More on that pipeline in how AI turns SQL into charts.

The Ten Practices at a Glance

Making These Standard Practice

1. Write them down once. A one-page house style covering palette, fonts, default chart types, title convention, and required annotations removes most arguments and most inconsistency.

2. Set defaults in the tool. Practices that depend on remembering will erode. Encode the palette and layout rules where charts are actually created.

3. Review charts like code. A second pair of eyes before a chart reaches a board deck catches truncated axes and missing units reliably.

4. Audit the existing estate. Pick your ten most-viewed dashboards and score them against the table above. The results usually justify deleting a third of them.

5. Retire what nobody uses. Chart sprawl erodes trust as effectively as bad design; if no one has opened it in a quarter, it is noise.

Frequently Asked Questions

What is the single most important data visualization best practice?

Matching the chart type to the question. Every other practice refines a chart that is already the right form, but no amount of colour discipline or annotation rescues a pie chart that should have been a sorted bar chart. Write the question in one sentence first, then choose the form that answers it directly.

Should bar charts always start at zero?

Yes, because the length of a bar is what encodes the value — truncating the baseline makes a small difference look like a large one. Line charts are the exception: they encode value by position, so a non-zero baseline is acceptable when the variation is the point, provided the axis is labelled clearly. If you truncate any axis, mark the break so the reader can see what you did.

How many colours should a chart use?

As few as carry meaning. Beyond roughly seven categorical colours, readers cannot reliably match legend to chart, and the usual fix is to group the small categories into "other" or switch to a different chart form. For most business charts a neutral base with one accent colour on the important series is more effective than a full palette.

When is a pie chart acceptable?

When you are showing parts of a single whole, the parts sum to 100%, and there are no more than about three or four of them — and even then a sorted bar chart is usually easier to read. The failure case is using a pie to compare categories that happen to be adjacent rather than genuinely componential. Our note on when to use a pie chart covers the edge cases.

Do these rules apply to AI-generated charts?

They apply more strictly, because generated charts scale faster than reviewed ones. The practical safeguards are to set defaults for chart type and palette in the tool so generation follows house style, to keep the chart bound to the query that produced it so the logic is inspectable, and to label which outputs are validated versus exploratory. A generated chart nobody can trace back to a query is a claim without a source, regardless of how good it looks.

Related reading

• Visualization First: The Best Data Analysis Tools for Stunning, Useful Charts