Data Visualization Tips for Content Creators: 8 Rules

A chart in a blog post, a newsletter or a report has a harder job than a chart in a dashboard. Nobody asked for it. The reader is scrolling on a phone, and the chart has a few seconds to say something before they move on. It will often be screenshotted and shared without the article around it, so it has to make sense on its own.

That is the brief for every tip below. Each one comes with a before-and-after example: the version most of us make first, and the version that does the job. The examples are generic so you can apply them to your own data.

What makes a good chart in content?

A good chart in content makes one point that a reader can grasp in about five seconds, on a small screen, without the surrounding text. Everything else follows from that: the chart type, the title, the labels, the colour and the size are all chosen to make that one point clear and honest.

Three questions help before you open any charting tool:

• What is the one thing the reader should take away? Write it as a sentence. If you can’t, you don’t have a chart yet, you have a dataset.
• Who is reading, and how much do they already know? A chart for engineers can carry more detail than one for a general newsletter.
• Where will it be seen? In the article, in a social feed, in an email, or printed in a report. Each one changes what works.

1. Choose the chart for the comparison

Choose the chart by the comparison you want the reader to make, not by what looks fresh. Most content charts make one of a handful of comparisons, and each has a chart that suits it.

Before: a pie chart of website traffic by source, with nine slices in nine colours and a legend underneath. Readers can’t compare slice sizes that are close to each other, and they spend their few seconds matching colours to the legend.

After: a horizontal bar chart, sorted from the largest source to the smallest, with each bar labelled. The ranking is visible at a glance, and the long source names fit beside the bars.

If you are new to chart types, our basic guide to data visualization walks through each one in more detail.

2. Give each chart one message, and put it in the title

Give each chart one message and write that message as the title, so the reader knows what to look for before they look. A descriptive label tells the reader what the data is. A message title tells them what it means.

Before: “Newsletter signups by month.”

After: “Signups rose after the form moved above the fold”, with a smaller subtitle underneath: “Newsletter signups per month, January to June.”

If a chart seems to need two messages, it is usually two charts. Splitting it is almost always clearer than adding a second axis or a second set of colours.

A message title also keeps you honest. If you can’t write a true sentence about the chart, the data may not support the point you hoped to make, and it is better to find that out before you publish.

3. Label the point directly and cut the clutter

Put labels on the chart itself, next to the lines and bars they describe, and remove anything that doesn’t help the reader read the values. Legends force the eye to travel back and forth; direct labels don’t.

Before: a line chart with four lines, a legend in the corner, heavy gridlines, a border, a background colour and every value printed on every point.

After: the same chart with each line labelled at its right-hand end, light or no gridlines, no border, and one annotation on the moment that matters: “Price change, 1 March”.

Things you can usually remove:

• borders, backgrounds and shadows;
• 3D effects, which distort the values;
• most gridlines, or all of them when values are labelled;
• decimal places nobody needs;
• a legend, when direct labels do the same job.

Edward Tufte called this the data-ink ratio in The Visual Display of Quantitative Information (1983): spend the ink on the data, not the decoration. The idea still holds for pixels.

4. Use colour that everyone can read

Use colour to point at the message, not to decorate, and make sure the chart still works for readers with colour vision deficiency. A simple rule: grey for context, one strong colour for the thing you are talking about.

Before: a bar chart with every bar a different colour, and the key comparison shown in red against green.

After: every bar grey except the one the title is about, which is in your accent colour. Where two groups must be told apart, they differ in lightness as well as hue, and each is labelled by name.

Practical checks:

• Don’t rely on red against green. Red-green colour vision deficiency is the most common type. Add labels, or use a pair that also differs in lightness, such as dark blue and light orange.
• Check contrast. The Web Content Accessibility Guidelines (WCAG 2.2) ask for a contrast ratio of at least 3:1 for graphical parts a reader needs to understand the chart, and 4.5:1 for normal-size text. Any contrast checker will give you the ratio.
• Simulate it. Chrome DevTools can emulate colour vision deficiencies (in the Rendering panel), so you can see your chart the way some readers will.
• Use a tested palette. ColorBrewer offers palettes designed for maps and charts, including ones marked as safe for colour-blind readers.

5. Design for the phone first

Design the chart at phone width first, then let it grow, because that is where most shared content is read and where small charts fail. A chart that works at 360 pixels wide will work on a laptop; the reverse is rarely true.

Before: a wide landscape chart exported from a spreadsheet, with twelve months along the bottom and axis labels that shrink to an unreadable size on a phone.

After: a taller, narrower layout with horizontal bars, a large title, text that stays readable without zooming, and only the categories the message needs. The full table sits below it for readers who want every number.

Also:

• export charts as SVG, or as an image large enough to stay sharp on high-density screens;
• write alt text that states the message and the key values, not “chart”;
• add a sentence of plain text under the chart that says the same thing, so the point survives if the image doesn’t load.

6. Add interactivity only when it helps

Add interactivity only when the reader genuinely needs to explore, for example to find their own city or year. For most content, a static chart that makes one point is clearer, faster and easier to share.

Before: an embedded dashboard with eight filters dropped into a blog post, where the main finding only appears after the reader picks the right combination.

After: a static chart showing the main finding in the article, with a link underneath: “Explore the data for your state”. The interactive version is there for the readers who want it, and everyone else still gets the point.

When you do use interactivity:

• Don’t hide the key number behind a hover. Phones have no hover, so tooltips can’t be the only place a value appears.
• Have a static fallback. Embeds often don’t show in email, RSS readers or social previews. Publish an image of the default view as well.
• Keep it light. A heavy embed slows the page for every reader, including the ones who never touch it.

7. Show the source and date on every chart

Put the source, the date and the units on the chart image itself, because charts travel without their articles. A screenshot with no source is a claim nobody can check, and readers have learned to distrust those.

Before: a chart with a title and nothing else. The source is in a footnote at the end of the post.

After: a single line under the chart: “Source: name of the publisher, name of the dataset, year. Figures are monthly totals in thousands.” Your site name or logo sits small in a corner.

Honesty belongs here too:

• Start bar charts at zero. A cut-off axis makes small differences look large. Line charts can start elsewhere when the change is the point, but say so.
• Keep time intervals even. Missing months look like smooth trends if you skip them silently.
• Compare like with like. Totals for places of very different sizes usually need to be per person, per household or per square kilometre.
• Avoid dual axes. Two scales on one chart let you make almost any two lines look related.

8. Test with real readers before you publish

Show the chart to three to five people who haven’t seen the data, give them five seconds, and ask what it says. If their answers don’t match your title, change the chart, not the readers.

Before: the chart is checked by the person who made it, on the large monitor they made it on.

After: the chart is checked by a colleague on their phone, in dark mode if your site supports it, and once printed in black and white. The colleague says the message back in their own words.

Questions to ask the testers:

• What is this chart telling you?
• What did you look at first?
• Is anything confusing or missing?
• Would you trust it enough to share it?

Common mistakes to avoid

Most weak charts in content fail in the same few ways. Watch for these before you publish:

• Too much in one chart. More than five or six lines or categories is usually too many for a phone. Group the small ones into “other”, or split the chart.
• Misleading scales. Truncated bar axes, uneven intervals and stretched aspect ratios all change what the reader sees.
• Decoration over accuracy. Pictograms, 3D and novelty shapes make values harder to read. Use them only when the values stay exact.
• Rainbow palettes. A rainbow implies an order that categories don’t have, and its bright bands draw the eye to the wrong places.
• Charts with no point. A chart added to break up the text, with no message, costs the reader time and gives nothing back.

Tools that suit content creators

You don’t need a data team to make good charts. A few tools that content teams use:

• Spreadsheet charts (Excel, Google Sheets). Fine for simple bars and lines, once you remove the defaults you don’t need.
• Datawrapper and Flourish. Browser-based tools built for charts in articles, with responsive embeds and image exports.
• RAWGraphs. An open-source tool for less common chart types.
• Vega-Lite or Observable Plot. For people comfortable with a little code who want charts they can rebuild when the data changes.
• A design tool such as Figma. For final polish on a chart exported as SVG.

Pick one and learn it well. A consistent style across your charts builds recognition faster than any single clever chart.

What public dashboards ask of a chart

Tailwebs built the dashboards for CEEW’s Green Finance Centre (GFC): the EV dashboard and Renewables India with the CEA. Public dashboards face the same test as a chart in a blog post: a reader arrives from a search or a shared link with a question, and the page has to answer it quickly, on whatever screen they have.

If you publish research and want charts or dashboards readers can explore, our page on public dashboards for research explains how we approach them.

When a chart should become a dashboard

A chart should become a dashboard when readers keep asking the same question with different inputs: their region, their product, their date range. One chart answers one question; a dashboard lets each reader answer their own. If you are publishing the same chart every month with new numbers, or getting requests for “the version for my state”, that is the signal.

At that point the work changes from design to data: where the numbers come from, how often they refresh, and who checks them. Our data visualisation services cover that build, from connecting the sources to the dashboard itself. For turning a set of charts into a story readers follow from start to finish, see our data storytelling best practices.

The short version

• Write the chart’s one message as a sentence before you start, and use it as the title.
• Choose the chart by the comparison: lines for time, sorted bars for ranking.
• Label directly, cut the clutter and annotate the moment that matters.
• Grey for context, one accent colour for the point, and never red against green alone.
• Design at phone width first, with alt text and a plain-text summary.
• Keep interactivity for real exploration, with a static fallback.
• Put the source, date and units on the image, and keep the scales honest.
• Test with three to five real readers before you publish.