Information & Data. Show the numbers so people see the answer.

Warm-up

Before you read, find out what you already believe about charts. Most people carry a few confident wrong rules (and a few right ones they can't explain).

This guide is organised in four parts. Part one is about the philosophy: software that informs, and the ink that carries information. Part two is about the eye: what people perceive accurately, and how to choose and craft a chart. Part three is about the product surfaces you will actually build: numbers in text, tables, dashboards and personal stats screens. Part four goes past charts to maps, timelines, calendars and explorable explanations.

Study it in four sittings, one per part. Do each chapter's exercise on your own product or on an app you open every day; the exercises are where the skill forms. If you only have twenty minutes, do the labs: each one is built so that playing with it teaches the idea faster than the prose.

If people open your software to learn something, it is information software, and its job is to show the answer with as little interaction as possible. Every question the user has to answer is a question you failed to infer.

In 2006 Bret Victor published a long essay called "Magic Ink: Information Software and the Graphical Interface". Its argument is simple and still under-used. He splits software by what the person is trying to do. Manipulation software is for creating and changing things: a text editor, Figma, a photo editor. The user is building a model in their head of the thing they're making, and direct manipulation (drag, resize, type) is the heart of it. Information software is for learning: a weather app, a train timetable, a bank balance, a flight tracker, a search result, a reading list. The user wants to answer a question, compare options and decide. Communication software (email, chat) sits between the two.

Victor's point is that most software is information software, yet it is designed like manipulation software: full of forms, menus, filters and buttons. That is backwards. For information software, the design problem is mainly a graphic design problem. What should be on screen, at what size, in what arrangement, so the answer is visible? Interaction is what you resort to when the graphic cannot know enough.

Interaction is a cost, not a feature

Victor titled one section of the essay "Interaction considered harmful". Not because interaction is bad, but because in information software every click, tap, field and menu is a toll the person pays before they see what they came for. Navigation means they have to know where the answer lives. A form means they have to phrase the question in your terms. A "Submit" button means they cannot see the effect of their choice until they commit to it. Each step also hides the comparison: if you can see only one result at a time, you have to hold the others in memory, which people are bad at (see The Human Mind on working memory).

The alternative is to infer the question from context. Victor names three sources:

1. Environment. What the device already knows: the time, the date, the location, the calendar, the connected network, the screen size, what's on the clipboard. A transit app that opens at 6:10 pm on a weekday near your office can guess you are going home.
2. History. What this person did before. If they checked the same route every weekday for a month, show that route first. If they always sort invoices by due date, remember it. History should make the software feel like it has learned, without making it unpredictable.
3. Interaction. Only what is left. When you do need input, make it reveal results immediately (no submit step), keep the previous answers visible for comparison, and let the input be graphical where the answer is graphical (drag a time slider, not type "18:30").

In the wild

• Dark Sky2012, acquired by Apple 2020
  Famous for its next-hour precipitation forecast: a sentence ("Light rain starting in 10 min") plus a small minute-by-minute chart. Apple later folded the same next-hour rain chart into its Weather app. Answer the likely question in words, then show the shape.
• Citymapper2011 onward
  Opens on what is near you: nearby stops and live departures, and a one-tap "get me home" style shortcut to a saved place. Environment plus history removes the trip-planning form for the most common trip.
• Google FlightsGoogle, 2011 onward
  The date grid and price graph show prices for many date combinations at once, so you see that leaving a day earlier saves money without running new searches. Show the neighbourhood of the answer, not just the answer.
• Apple Walletlaunched as Passbook, 2012
  Boarding passes and tickets can surface on the lock screen when you are near the relevant place or time. Time and place are context you get for free.
• Flighty2019 onward
  A flight tracker that puts your flight's status, gate and timing in one glanceable card (and in iOS Live Activities), with deep detail one tap away. Summary on the surface, analysis underneath.

Every mark on a chart should earn its place by carrying information. Remove what doesn't, and the data gets louder. But "minimal" is a means, not the goal: the goal is understanding, and sometimes memory.

In The Visual Display of Quantitative Information (1983, second edition 2001), Edward Tufte defined the data-ink ratio: the share of a graphic's ink that presents data and could not be erased without losing information. Gridlines, frames, background fills, shadows, 3D sides, decorative icons and repeated labels are non-data ink. His instructions are almost mechanical: above all else show the data; maximise the data-ink ratio, within reason; erase non-data ink; erase redundant data ink; revise and edit.

Why does this work? Because of how vision works. Your eye picks out differences before you consciously look (pre-attentive processing; see The Human Mind). Every heavy gridline, frame and gradient is a difference too, and it competes with the bars for that first glance. Removing it does not just look tidier: it lowers the number of things the eye has to reject before it reaches the data. On a phone, where a chart may be 320 pixels wide, every pixel of frame is a pixel taken from the data.

Chartjunk

Tufte's name for the worst non-data ink is chartjunk. He described three families: vibrating patterns (cross-hatching and stripes that shimmer, a moiré effect that makes the eye work); the grid (heavy, dark gridlines that compete with the data); and the duck (a graphic whose whole structure is decoration, named after a duck-shaped building on Long Island). The software equivalents are easy to find: gradients on bars, drop shadows, glossy 3D, icons stacked to make bars, a chart inside a decorative card inside a card, and animated count-ups that make you wait for a number.

Within reason: the honest critique

Tufte's rule is a superb default and a poor religion. Researchers tested it. In 2010 Scott Bateman and colleagues at the University of Saskatchewan published "Useful Junk?" at the CHI conference. They compared plain charts with heavily illustrated versions in the style of the illustrator Nigel Holmes (think a monster whose teeth are the bars). Interpretation accuracy was about the same for both. But two to three weeks later, people remembered the embellished charts' topic and message significantly better. In 2013 Michelle Borkin and colleagues found that charts with recognisable pictures and distinctive visual features were more memorable than plain, common chart types.

So the right question is not "how minimal can I go?" but "what is this chart for?":

Also note where pure erasing fails. Tufte's own "range-frame" and minimal box plots strip so much that many readers no longer recognise the form. Faint gridlines, when people need to read values off the chart, are not junk: they are data-adjacent ink that carries information. Erase what is redundant, not what is quiet.

In the wild

• Stripe DashboardStripe
  Small line charts with almost no axis furniture: a headline number, a faint comparison line for the previous period, and a few date ticks. Comparison line instead of gridlines: the context is itself data.
• Plausible Analytics2019 onward
  A deliberately simple one-page web analytics dashboard: a handful of top numbers, one main chart, then ranked lists with thin proportional bars behind each row. A bar behind a list row is maximum data-ink: the row is the label.
• Our World in DataGrapher charts
  Charts with insight-stating titles, direct line labels, faint gridlines and a source line under every chart. Faint gridlines plus sources: minimal, but not stripped of trust.
• Excel and Google Sheets defaults2000s–2010s
  For years, default charts came with grey backgrounds, legends for single series and 3D options one click away. Recent defaults are cleaner, but the 3D and gradient options remain. Defaults shape millions of charts; yours will shape every chart in your app.

A chart is honest when the size of an effect on screen matches the size of the effect in the data. Most dishonest charts aren't drawn by liars; they're drawn by defaults, cropped axes and convenient time windows.

Tufte gave this a number. The lie factor is the size of the effect shown in the graphic divided by the size of the effect in the data. A lie factor of 1 is honest. His famous example was a 1978 New York Times graphic of US fuel-economy standards, where a 53% increase in the data was drawn as a 783% increase in line length: a lie factor of about 14.8. Tufte suggested anything outside roughly 0.95 to 1.05 is a substantial distortion.

When the baseline must be zero

The rule depends on the encoding, and this is where most people go wrong in both directions.

• Bars, columns and areas must start at zero. Their length or area is the value. A truncated bar is a false statement about size. Dona Wong's The Wall Street Journal Guide to Information Graphics (2010) is blunt about this: bar charts start at zero.
• Lines and dots don't have to. Their position encodes the value, and what people read from a line is change and shape. Body temperature charted from 0 °C would flatten a fever into nothing; a chart of 36–41 °C is honest because that is the meaningful range. Stock prices, weight, response times: zoom the axis to the range where differences matter, and label it clearly.
• But "not required" doesn't mean "anything goes". Zooming a line until noise looks like a trend is the same lie by another route. Ask: would a domain expert call this change big? If not, don't draw it big. Cairo calls this showing the right amount of uncertainty and variation, not just the right numbers.

Other ways graphics mislead

Truncated bars are the famous one. Alberto Cairo's How Charts Lie (2019) catalogues the subtler ones you are more likely to commit by accident:

Cherry-picked window

Starting a time series at a low point makes any growth look heroic. Show a window that includes a normal period, or let people choose.

Cumulative charts

A cumulative total only goes up, so it hides that monthly sign-ups are falling. Fine for "progress towards a goal"; misleading for "how are we doing".

Missing denominators

"Most crashes on Android" may only mean most users are on Android. Show rates (per 1,000 sessions), not counts, when comparing groups of different sizes.

Unadjusted money

Revenue over ten years without inflation, or prices across countries without currency or purchasing-power context.

Aspect-ratio drama

Squash a chart horizontally and every line becomes a cliff. Chapter 8 covers choosing an aspect ratio deliberately.

Hidden uncertainty

A single forecast line implies a precision you don't have. Show a range band, or say "about".

In the wild

• New York Times fuel economy chart1978, critiqued by Tufte
  The textbook lie factor case: a 53% change drawn as 783%, a lie factor of about 14.8. Perspective drawings and shrinking lines distort without any wrong number.
• Stock appsApple Stocks, Robinhood, broker apps
  Intraday line charts zoom tightly to the day's range, so a 0.3% move fills the chart. That's a reasonable line-chart choice for traders, but the visual drama is real. The better apps show the percentage change prominently next to the line. If you zoom, state the size in numbers beside it.
• Our World in DataGrapher
  Many charts let you switch between linear and log axes, change the time range and switch to per-capita figures. When the honest framing depends on the question, let people change the frame and label it clearly.

Comparison is the heart of understanding numbers. Small multiples repeat one simple chart so the eye compares many; sparklines shrink a chart to the size of a word so data sits inside sentences and rows; layering makes context quiet so data can be loud.

Tufte's question for any graphic is "compared to what?". A single number or a single line rarely answers it. Two of his most practical answers are designs that put many comparisons in a small space.

Small multiples

A small multiple is a grid of the same little chart, one per category, with the same scales and the same design in every panel. Once you've understood one panel you've understood them all, so the eye spends all its effort on the differences. Tufte called them the best design solution for a wide range of problems in data presentation. They beat the alternative (one chart with eight overlapping coloured lines and a legend) because each series gets its own clean space and no colour lookup is needed.

Sparklines

In Beautiful Evidence (2006) Tufte introduced sparklines: small, intense, word-sized graphics with no axes, placed where the words and numbers are, in a sentence, a table cell or a list row. A sparkline answers "compared to what?" for a single number: "Revenue ₹4.2 lakh" says nothing; the same number with a tiny line of the last twelve months says whether that's a good month. Microsoft added sparklines to Excel in 2010, and they are now common in finance apps and dashboards.

Rules that keep them honest: show the same time window in every sparkline you place side by side; decide deliberately whether they share a vertical scale (shared to compare sizes, independent to compare shapes) and don't mix the two in one list; mark the last point (a small dot) and, if useful, the min and max; keep them about the height of a capital letter so line spacing isn't disturbed.

Layering and separation

In Envisioning Information (1990) Tufte describes layering and separation: put information on visually distinct layers using differences in value (lightness), weight and colour, so the reader can focus on one layer while the others stay quietly available. Gridlines, axes, context data and previous periods go on a pale back layer; the data you want read goes on a dark or saturated front layer. He borrows Josef Albers's observation that "1 + 1 = 3 or more": two strong marks create a third, unintended shape (the vibrating gap between them), so heavy context marks don't just add noise, they multiply it.

Micro and macro readings

Tufte's other idea from the same book: the best dense displays work at two distances. From afar (macro) you see the overall pattern; up close (micro) every detail is real data. The Vietnam Veterans Memorial is his example: from a distance, a wall of names; up close, one name. In software, a year calendar heatmap is the everyday case: the macro reading shows seasons and streaks, the micro reading shows a single day. Dense is fine when it is organised; what fails is clutter, which is density without structure.

In the wild

• GitHub contribution graphGitHub profile pages
  A year of activity as a grid of day squares shaded by count. Macro: busy months and quiet seasons. Micro: a single day. Micro/macro reading in a few hundred pixels.
• Apple Weather 10-day forecastredesigned in iOS 15, 2021
  Each day's low-to-high range is a bar on a scale shared across all ten days, so you can see at a glance that the weekend is cooler. Small multiples in rows: one shared scale turns a list into a chart.
• Stock watchlistsApple Stocks and most broker apps
  Each row pairs a ticker and price with a tiny line of the day. Sparklines in rows; but check whether each row is scaled independently, which shows shape but not size.
• Excel sparklinesMicrosoft, Excel 2010
  Word-sized line, column and win/loss charts inside cells, directly inspired by Tufte. The idea scaled from a book to millions of spreadsheets.

People judge quantities most accurately from position on a common scale, then length, then angle, then area, then colour shade. Put your most important comparison in the most accurate channel.

In 1984 William Cleveland and Robert McGill, statisticians at Bell Labs, published "Graphical Perception" in the Journal of the American Statistical Association. They showed people pairs of values encoded in different ways and asked them to judge what percentage the smaller was of the larger. The errors differed a lot by encoding. In 2010 Jeffrey Heer and Michael Bostock re-ran similar experiments with crowdsourced participants on Mechanical Turk and found the same general order. That makes it one of the most reliable findings in visualisation.

Why the order exists

Comparing two dots on the same axis is a straight distance judgement against a shared reference. Lengths are almost as good, but without a shared baseline you compare them by eye, which adds error. Angles are harder because our sensitivity varies with orientation (we're good near 0°, 90° and 180°, worse in between). Area is worse still: research on perceived magnitude (Stevens's power law) found people tend to underestimate differences in area, so a circle with twice the area looks less than twice as big. Colour shade is the weakest: lightness perception depends on what surrounds it, so the same grey looks different on different backgrounds.

The practical rule: put the comparison that matters most into position. Use length next. Use area and shade only for rough impressions (big vs small, hot vs cold), or when position is already taken (a map uses position for geography, so the data must go into shade or size).

Bertin's visual variables

Long before the experiments, the French cartographer Jacques Bertin set out the vocabulary in Sémiologie graphique (1967; English translation Semiology of Graphics, 1983). A mark on a page can vary in position (two dimensions), size, value (lightness), texture, colour (hue), orientation and shape. His key contribution was to ask which variables can express which kinds of data. Later, Jock Mackinlay (1986) ranked the channels separately for quantitative, ordered and categorical data.

In the wild

• Apple Screen TimeiOS 12, 2018 onward
  Daily use is shown as bars on a shared baseline, with a dashed line for the average and category colours stacked inside bars. The total (length) reads well; the stacked category segments, which float, are far harder to compare.
• Weather radar mapsmost weather apps
  Position is taken by geography, so rain intensity must go into colour. Good apps use an ordered light-to-dark scale; many still use rainbow scales. When position is used up, use lightness for order, and add a legend.
• Datawrapper2012 onward
  The chart tool's documentation and defaults steer users towards bars, dot plots and direct labels, and its blog regularly explains perceptual reasons for chart choices. A tool can teach good encoding through its defaults.

Pie charts are fine for one simple message about parts of a whole and poor for comparison. 3D adds distortion and nothing else. Dual axes let the designer invent any relationship they like.

Pie charts, fairly judged

Pies rank low on the ladder (angle and area), and Stephen Few's essay "Save the Pies for Dessert" (2007) laid out the case against them. Yet pies survive because they do one thing well: they say "these parts make a whole" instantly. That message is the best case for a pie. When the question is "roughly what share is this?", and there are two or three parts, a pie (or a single filled ring) is quick and familiar. When the question is "which is bigger?" or "how did shares change?", it fails.

Donut charts are a pie with the centre removed; readers then judge arc length rather than angle, which research by Robert Kosara and Drew Skau (2016) suggests is read about as accurately as a pie, not better. The centre hole is useful for a single label. A waffle chart (a 10×10 grid of squares) is often a better part-to-whole form for one share: "23 of 100 squares" can be counted.

3D charts

There is no data reason for 3D in a chart of two-dimensional data. Perspective makes near slices and bars larger than far ones, tilting a pie turns angles into ellipses that no one can judge, and 3D bars sit their visual top above or below the true value depending on the viewing angle. Occlusion hides some bars behind others. Dona Wong's advice is simply not to use it. The only reasonable 3D in data graphics is for genuinely three-dimensional data (terrain, a molecule, a building), usually with interaction to rotate it.

Dual axes

A dual-axis chart plots two series with different units on one chart, one scale on the left and one on the right. The problem: both scales are arbitrary choices, so the designer can make the lines cross, run parallel or diverge simply by adjusting either axis. Readers then see a relationship (correlation, crossing points, "revenue overtook costs") that the data doesn't contain. Few, Cairo and the Datawrapper team all advise against them in most cases.

In the wild

• iPhone and Mac storage barsApple
  Storage use is shown as one horizontal bar split into a few categories, with the largest named first and the free space shown. A segmented bar is a pie unrolled: easier to read and to fit on a narrow screen.
• Apple Activity ringsApple Watch, 2015
  Three rings, each one share of a personal goal (Move, Exercise, Stand), and rings can go past 100%. Each ring is "one share of one whole", the case where circular forms work; nobody compares the rings to each other.
• Google Sheets and Excelchart menus
  Both still offer 3D pie and 3D column options. Being available in a menu is not an endorsement.

Don't start from chart types; start from the question the reader is asking. Each question (compare, change, part-to-whole, distribution, relationship) has one or two forms that answer it well, and a few that look plausible and fail.

Most bad charts come from choosing a type first ("let's do a donut here") and pouring data into it. Reverse the order. Write the reader's question as a sentence. Then identify its shape. Nearly every question in product UI is one of a handful:

• Comparison: which is bigger, by how much? ("Which project took the most hours?")
• Ranking: what's the order? ("My top five apps.")
• Change over time: going up or down, how fast, any pattern? ("Am I reading more than last year?")
• Before and after: how did each item change between two moments?
• Part-to-whole: what share is this? ("How much of my storage is photos?")
• Distribution: what's typical, how spread out, any outliers? ("How long are my sessions usually?")
• Relationship: does one thing move with another? ("Do I sleep worse when I work late?")
• Pattern across two categories: when does it happen? ("Which hours of which days am I most productive?")

Always plot the distribution once

Averages hide shape. In 1973 the statistician Francis Anscombe published four small data sets, now called Anscombe's quartet, with nearly identical means, variances, correlations and regression lines. Plotted, they're completely different: a noisy line, a curve, a perfect line with one outlier, and a vertical cluster with one far point. In 2017 Justin Matejka and George Fitzmaurice extended the idea in "Same Stats, Different Graphs" with the "Datasaurus Dozen", a set that includes a dinosaur drawing (based on Alberto Cairo's original "Datasaurus") with the same summary statistics as the others.

In the wild

• Stravaactivity screens
  Uses a line (elevation, pace over distance) for change along a route, and bars for weekly totals. Two questions, two forms, both on the top rungs.
• The Financial Times"Visual Vocabulary" poster
  The FT's graphics team published a chart chooser poster organised by relationship type (deviation, correlation, ranking, distribution, change over time, part-to-whole, magnitude, spatial, flow). Organise chart choice by question, not by chart type.
• Time trackersToggl Track and similar
  Time-tracking reports commonly pair a bar chart of hours per day with a ranked list of projects. Time on a bar, composition as a ranked list, exact values in a table.

A good chart is designed like a good sentence: it has a point, it says it first, and everything else supports it. Title with the finding, label directly, use colour for one thing, sort with purpose, and choose the shape of the frame deliberately.

Cole Nussbaumer Knaflic's Storytelling with Data (2015) distils a practice that came from years of teaching analysts at Google: understand the context, choose an appropriate visual, eliminate clutter, focus attention where you want it, think like a designer, tell a story. The crafting steps below are where most of the improvement in a chart actually happens. Choosing the right type gets you to "acceptable"; craft gets you to "obvious".

1. Titles that state the finding

"Sign-ups by month" is a label. "Sign-ups doubled after the free tier launched" is a finding. An insight title tells the reader what to look for, so the chart confirms it in a glance instead of being decoded from scratch. Put the descriptive label (metric, units, period) in a smaller subtitle. In product UI, where the data changes, generate the title from the data: "You read 3 more books than last year" or "Spending is 12% below your monthly average". When there's no clear finding, say so honestly ("About the same as last month") rather than inventing drama.

2. Direct labels instead of legends

A legend asks the reader to hold a colour-to-name mapping in working memory and look back and forth. Put the name at the end of the line or on the bar. Datawrapper, Our World in Data and most newspaper graphics do this by default. A legend is acceptable only when lines are so tangled that labels would collide, and that's often a sign you need small multiples instead.

3. Colour with purpose

Start everything in grey. Then add one colour to the thing the title talks about. That single move does most of the work in Knaflic's "focus attention" step: pre-attentive processing finds the one coloured thing instantly. Use more colours only when categories genuinely need distinguishing, keep categorical palettes small (about six hues at most, distinguishable in colour-blind simulation), use a single-hue light-to-dark ramp for quantities, and a diverging ramp (two hues through a neutral middle) when there's a meaningful midpoint like zero or a target. Keep a colour's meaning consistent across every chart in your product. More on colour and accessibility in Visual Design and Accessible & Inclusive.

4. Sorting

Unless categories have a natural order (months, age bands, steps in a funnel, rating scales), sort bars by value. Alphabetical order is a database habit; it makes the reader do the ranking. For rating scales, keep the natural order and use a diverging layout. For small multiples, sort panels by the thing you want compared (largest change first), not by name.

5. Aspect ratio and banking

The shape of a line chart's frame changes how steep slopes look, and therefore how dramatic change feels. William Cleveland proposed banking to 45°: choose the aspect ratio so that the average absolute slope of the line segments is about 45°, where people judge slope differences best. You don't need to compute it. The practical version: if a line looks like a cliff, the chart is too narrow or too tall; if it looks like a flat wire, too wide or too short. Pick the frame where the meaningful changes are visible and no steeper. On phones this matters because charts get squeezed into tall narrow boxes, which turns every wobble into a spike.

6. Gridlines, ticks and axis numbers

Gridlines should be just visible: a light rule colour, thin, and only on the value axis. Three to five ticks is plenty for most product charts. Format tick labels for humans: "20k" not "20000.00", "Mar" not "2026-03-01", "₹2L" or "₹2 lakh" for Indian audiences. Drop the axis line on the value axis if gridlines exist; keep a darker baseline at zero for bars. Put units in the subtitle or on the top tick ("60 min") instead of an axis title rotated 90°, which nobody reads on a phone.

7. Annotation

An annotation is a sentence placed on the chart where the thing happened: "Free tier launched", "Server outage", "Started new job". It turns a shape into an explanation. In personal data products, letting users annotate their own charts ("moved city", "injury") is powerful: their context explains their data better than any algorithm can. Keep annotations in the muted colour, attached to the data with a thin line, and limit them to the two or three that explain the shape.

In the wild

• The Economist and the Financial Timesdaily charts
  Both use short, opinionated titles that state the finding, with a smaller descriptive subtitle, and a source line under every chart. Two-level headings: finding, then description.
• Our World in Dataline charts
  Country lines are labelled at their right end rather than in a legend, and readers can highlight one country to grey out the rest. Direct labels plus highlight-on-hover is the interactive form of "grey the rest".
• Apple HealthTrends and Highlights
  Highlights cards pair a short generated sentence comparing a recent period with an earlier one and a simple chart of the two periods. A data-generated insight title, in a consumer product.

A number should be shown with exactly the precision the reader's decision needs, in the grouping and units they read fluently, and with the comparison that tells them whether it's good.

Formatting looks like a detail. It isn't: a misplaced separator turns ₹12,34,567 into nonsense for an American reader and 1,234,567 into a puzzle for many Indian readers who count in lakhs. Too many decimals make numbers slow to read and imply false precision. Too few hide real differences. Every number in your product goes through this decision, so it's worth getting the rules into one formatting function.

Precision: significant figures, not decimal places

For overview screens, two or three significant figures are almost always enough. "4.2 lakh" or "420k" is read instantly; "4,23,817.46" has to be parsed digit by digit, and the extra digits rarely change a decision. Detail views, invoices, receipts and exports need exact values. A good rule: summary = rounded, detail = exact, money owed = exact to the paisa or cent. And keep decimals consistent within a column or a comparison: 4.0 next to 3.75 next to 12 is harder to compare than 4.00, 3.75, 12.00.

Beware false precision: "Your reading speed is 247.36 words per minute" claims an accuracy the measurement doesn't have. "About 250 wpm" is more honest. The precision you show is a claim about how much you know.

Grouping and locale

Digit grouping differs by locale, and the Unicode CLDR data (which powers Intl.NumberFormat in browsers, and the formatters in iOS and Android) handles it for you:

The Indian system: 1 lakh = 1,00,000 (one hundred thousand); 1 crore = 1,00,00,000 (ten million) = 100 lakh. An Indian reader seeing "₹45,23,817" reads "forty-five lakh" at a glance; "₹4,523,817" must be re-parsed. If your audience is Indian, use en-IN grouping, and consider writing large amounts in words ("₹45.2 lakh", "₹1.2 crore"), which is how prices of houses, cars and salaries are commonly discussed in India.

Units, signs and symbols

• Always show the unit, close to the number: "42 min", "3.2 km", "₹1,200". A bare number is a riddle. In tables, put the unit in the column header once.
• Use a real minus sign (−, U+2212) for negative values in display type; the hyphen is shorter and misaligns. Accounting contexts may use parentheses: (1,200).
• Keep the number and its unit together with a no-break space so "42" doesn't end one line and "min" start the next.
• Durations: "1 h 32 min" reads better than "1.53 hours" for people; "92 min" is good for comparison in a column.
• Times and dates: relative for the recent past ("4 min ago"), absolute for anything older than about a day ("12 Mar"), and always absolute on hover or in detail. Follow the user's 12/24-hour setting.
• No data is not zero. Show "No data" or a muted dash for missing values, so a gap isn't read as nothing happening.

Relative and absolute, percent and points

Two common traps. First, a relative change without the absolute base is easily misread: "risk doubled" might mean 1 in 10,000 became 2 in 10,000. "+200% sales" might mean 1 sale became 3. Show both: "3 sales (up from 1)". Second, percentages of percentages: if conversion goes from 10% to 12%, that's +2 percentage points or +20%. Both are true; "+2%" is wrong and common. Say "points" for differences between percentages.

In the wild

• Zerodha Kite and Indian banking appsIndia
  Indian broker and banking apps commonly show balances in Indian digit grouping, matching how users read amounts. Local grouping is not a nicety; it's how people parse money.
• YouTube and social appsview counts
  Counts are compacted ("1.2M views") in lists and shown in full on the detail page. Summary rounded, detail exact.
• Apple Healthunits
  Uses the units set in the user's region and preferences (km or miles, kg or lb, °C or °F) consistently across charts and summaries. Units are a locale setting too.

A big number on its own is a statement without a meaning. Give every headline number a period, a comparison and a judgement of good or bad, and let the typography keep it steady.

The "big number tile" (a large figure with a small label, often in a grid of four to eight) is the most common data element in software. It is also the most commonly misused. The failure is always the same: Tufte's "compared to what?". "1,284 users" doesn't tell you if that's good. "1,284 users this week, up 9% on last week, highest since March" does.

Deltas and trend indicators

Arrows and percentages are where most tiles go wrong:

1. Say the comparison. "+12%" against what? Previous day, same day last week, last month, last year? Weekly cycles are strong in almost any human activity, so "vs same day last week" is usually fairer than "vs yesterday" (Monday vs Sunday is not news).
2. Encode good and bad, not up and down. Costs going up is bad; error rate going down is good; screen time going down might be good. Green for up everywhere is a bug. And never rely on colour alone: the arrow and the word carry it too.
3. Mind the base. Small numbers swing wildly. +200% on a base of 2 is noise. Show the absolute change, and suppress percentages under a minimum base.
4. Show "about the same". Changes within the normal noise of the metric (say ±3%) should read as neutral, in grey, without an arrow. Otherwise users react to random wobble.
5. Prefer a trend over a single delta. One comparison can mislead; a sparkline of 8 to 12 periods shows whether this week is a blip or a direction.

Vanity and the cumulative trap

A vanity metric looks good and informs no decision. "Total users ever" only goes up; it can't tell you that the product is shrinking. "Total words written" is lovely for a celebration, useless for a weekly check. For anything people monitor, prefer active, per-period and per-user rates. Keep the cumulative totals for milestones and year-in-review moments, where celebration is the point.

Typography for numbers

Numbers that change, align or sit in columns need tabular figures: digits of equal width, set with font-variant-numeric: tabular-nums (if the font supports it). Without them, a timer or live counter shimmies left and right as digits change ("1" is narrower than "8" in proportional figures), and columns of numbers don't line up. In running prose, proportional figures look better. Use lining figures (all digits the height of capitals) in UI and tables; oldstyle figures (with ascenders and descenders) suit long-form reading. See Typography for the full treatment.

In the wild

• Stripe DashboardHome
  Headline figures like gross volume sit above a small chart, and can be compared with a previous period drawn as a fainter line. Comparison and trend built into the tile.
• Apple Screen Timeweekly report
  The weekly report shows daily average screen time with a percentage change from the previous week. The comparison is there; whether up is good or bad is left to the user, which is honest but can feel like judgement either way.
• Plausible Analyticstop stats
  A short row of top stats (visitors, pageviews, bounce rate, visit duration), each with a change against the previous period. Few tiles, each with comparison: restraint as a feature.

A table is for looking up and comparing exact values. Its design job is to make columns easy to scan down and rows easy to follow across, with the least ink that does it: aligned numbers, quiet separators, and emphasis on the column that matters.

Stephen Few's Show Me the Numbers (2004, second edition 2012) treats tables as seriously as charts, and argues that for lookup they're often better. Tables are linear: people scan a column to find a row, then read across. Every design decision should help those two motions.

Alignment is the whole game

• Numbers right-aligned, so units line up under units and tens under tens; magnitude is then visible from the length of the number alone. Use the same number of decimals in a column, and tabular figures.
• Text left-aligned, because we read from the left edge. Centred text gives every row a different starting point.
• Headers aligned like their column: a numeric column's header goes right too, so it sits above the numbers.
• Dates in a consistent, fixed-width format (12 Mar 2026, or 2026-03-12 for technical audiences), left-aligned or right-aligned consistently.
• Units in the header ("Amount (₹)", "Duration (min)"), not repeated in every cell.

Rows: separators and density

Readers need help following a row across, especially in wide tables. Three options, from lightest to heaviest: whitespace alone (works for short, narrow tables), thin horizontal rules (the best general default), and zebra striping (alternating subtle background tints; helpful for very wide tables with many columns, distracting for short ones). Avoid vertical rules: alignment already defines columns, and vertical lines create a grid of boxes that slows scanning. Few recommends using the lightest separation that works.

Density is a trade-off between scanning and seeing more at once. A comfortable row (about 44–48 px tall on desktop) is easy to read and click; a compact row (about 32 px) lets experts see more. Products for professionals (Linear, spreadsheets, finance tools) often offer a density setting. On touch screens, keep tap targets at least 44 pt even if the visual row is dense.

Emphasis inside tables

Tables have their own layering. Make the column people scan to find a row (usually a name) easy to read, and the key value column slightly heavier. Highlight exceptions with weight or a small marker plus colour, not by colouring entire rows, which shouts. Separate totals from data with a heavier rule above the total row and bold figures. Keep header text short and muted; it's a label, not the content.

A heatmap table (cells tinted by value with a single-hue scale) can add a pre-attentive layer to a dense table of comparable numbers, such as a cohort retention table. Use it only when every coloured cell is the same kind of quantity, and keep the numbers visible on top.

In the wild

• Linearissue lists
  Dense, quiet rows with very light separators, left-aligned titles and small right-side metadata, plus display options for grouping and ordering. Density works when separators are quiet and alignment is strict.
• Bank statements in banking appstransactions
  Good ones right-align amounts and distinguish debits and credits with a sign and colour, so a column of spending is scannable. Sign plus alignment plus colour, never colour alone.
• Wikipedia data tablessortable tables
  Many tables are sortable by clicking headers, with numbers right-aligned in the better-edited ones. Sorting turns a table into many tables.

In software, a table is a live object: it sorts, filters, truncates and has to survive a 400px screen. Make every one of those states visible, reversible and honest about what's hidden.

Sorting

• Choose a meaningful default sort (most recent, most urgent, largest), not database order. This is Magic Ink again: the default should answer the common question.
• Show the active sort with an arrow on the header, and make the whole header clickable. Clicking again reverses; consider a third click to return to default.
• Sort numbers as numbers, dates as dates (10 after 9, not before 2) and names with natural ordering (file2 before file10) and locale-aware collation.
• Sort sensibly by default direction: numbers usually descending first (largest is most interesting), text ascending.
• Keep sorts stable so equal items don't jump around, and remember the user's choice.

Filtering and search

Filtering hides data, which makes it dangerous: people forget a filter is on and conclude something is missing. Show active filters as removable chips above the table, show the count ("Showing 12 of 340"), and offer a single "Clear filters". Filters should apply live as they're changed, without an Apply button, when the data set is small enough (Victor's point about immediate feedback). For text search, highlight matched text in the results so people see why each row matched. An empty filtered result should say what filter caused it and offer to remove it, which is different from a truly empty table (see Structure & Interaction on empty states).

Truncation

When text doesn't fit, truncate with an ellipsis and give access to the full value (a tooltip on desktop, the detail view on mobile). Truncate in the right place: titles at the end, file names and email addresses in the middle (so "Invoice-2026-…-final.pdf" keeps the distinguishing ending), and never truncate numbers: a number cut short is a different number. Give the most important text column the flexible width and let other columns stay fixed.

Tables on a phone

At 400px a five-column table doesn't fit. Luke Wroblewski's "mobile first" argument (his 2011 book Mobile First) applies directly: the constraint forces you to decide what matters. There are five honest strategies; pick by what people do with the table.

In the wild

• Gmail and Apple Mailmobile lists
  On phones, the desktop columns (sender, subject, date) become a two-line row: sender and time on the first line, subject and snippet below. A table reflowed into a list row is the most common responsive table of all.
• Airtable and Notiondatabase views
  The same data can be shown as a grid, a list, cards (gallery) or a calendar, with view-specific sorts and filters shown in a toolbar. Separating data from its view lets each task get the right layout.
• macOS Finderlist view
  Long file names are truncated in the middle in some views, keeping the ending and extension visible. Truncate where the least information is.

A dashboard is a single screen that lets someone check, at a glance, whether things are as they should be. Decide whether it's for monitoring or analysis, put the summary first, keep normal quiet, and make every element lead to a decision.

Stephen Few's Information Dashboard Design (2006) defined a dashboard, roughly, as a visual display of the most important information needed to achieve one or more objectives, fitted on a single screen so it can be monitored at a glance. Each part of that definition is a design constraint: most important (so choose), objectives (so tie each element to a goal), single screen (so no scrolling to find problems), at a glance (so pre-attentive encoding of what's wrong).

Monitoring or analysis?

Most product dashboards fail by being half of each: too many controls to glance at, too little depth to analyse. Build the monitoring view first, and link from each element into a dedicated analysis view. That's Ben Shneiderman's "visual information-seeking mantra" (1996): overview first, zoom and filter, then details on demand.

Normal is quiet, exceptions are loud

A dashboard where everything is coloured has nothing highlighted. Encode status by exception: normal values in neutral ink, attention values with a warm colour plus a symbol, critical with a strong colour plus a symbol and text. Never rely on red and green alone (about 1 in 12 men has some form of colour-vision deficiency). Few criticised the traffic-light habit, where every metric gets a red, amber or green dot: when twenty dots are green the one amber is lost, and the dot says nothing about how far off target a value is.

Few also designed the bullet graph as a compact replacement for dashboard gauges and meters. A gauge spends a large circle of space to show one value on an angle (a low rung). A bullet graph is a single bar (length, a high rung) over a few shaded bands for qualitative ranges (poor, OK, good), with a short line for the target. It fits in a table row.

Density done right

Calm is not the same as sparse. A good dashboard can be dense, because it's organised: aligned grid, consistent chart forms, shared scales, quiet chrome, and a clear reading order. Few lists common dashboard mistakes, including exceeding a single screen, giving inadequate context for the numbers, excessive detail or precision, choosing poor measures, meaningless variety of chart types, cluttering with decoration, and misusing colour. Notice that "too much data" isn't the problem; "too little thought about which data" is.

The "so what?" test: for each element, finish the sentence "If this changes, I will…". If there's no action, it belongs in an analysis view or nowhere.

In the wild

• Status pagesStatuspage-style, e.g. GitHub Status
  A one-line verdict at the top ("All Systems Operational"), components listed with quiet normal states, and incidents called out with text. The verdict sentence is the dashboard's first line.
• Plausible Analyticssingle-page dashboard
  Everything for a site on one scrolling page: top stats, one main chart, then ranked lists (sources, pages, countries), each clickable to filter the whole page. Overview first, filter by clicking the data itself.
• Vercel and other deploy dashboardsdeveloper tools
  Recent deployments are listed with status in words and a symbol, with failures standing out and successes quiet. Exception-based status in a list.

When the data is about the person looking at it, every chart is also a judgement of them. Design personal stats to inform and encourage, show what's normal for them, treat gaps kindly, and never use the mirror to manipulate.

Small apps often have one data screen: the stats page. A writing app shows words per day; a reading app shows books per year; a habit app shows streaks; a fitness app shows weekly distance. These are dashboards with a twist: the subject is the user, and they have feelings about it. The same bar chart can motivate or shame depending on framing.

Compare to themselves, not to strangers

The most useful comparison for personal data is the person's own baseline: "more than your usual Tuesday", "your longest run this year", "within your normal range". Comparison with others (leaderboards, percentiles) motivates a competitive few and discourages most. Strava handles this by making social comparison opt-in by context (segment leaderboards, clubs) while personal progress (weekly totals, personal records, a year-in-sport summary) is the default view.

Streaks and their dark side

A streak counts consecutive days. It's simple and motivating, and it has a cliff: one missed day resets it to zero, often after weeks of effort, and the user's feeling of the product turns from pride to loss. Products have softened this with streak freezes and repairs (Duolingo is the best-known example). A calmer alternative is a rolling consistency measure ("5 of the last 7 days", "18 of 30") or a calendar of done days, which records effort without a cliff.

Scores, rings and composite numbers

Composite scores (a "readiness" of 74, a "health score" of B+) are attractive because they're one number. They're also opaque: the user can't tell what moved it or what to do. If you use one, show its contributors and how each changed, use plain labels for ranges, and never let the score be the only view of the data. Apple's Activity rings work well because each ring is a single, understandable quantity against a goal the user set, and the goal can be changed.

Quantified-self ethics

• Missing data is not a bad day. A watch left on the charger, a phone left at home, a day the app wasn't opened: show gaps as gaps.
• Rest is part of progress. Fitness apps increasingly show rest and recovery as positive. Habit apps can allow planned days off.
• Let people choose what they see. Weight, calories and some health metrics can be harmful for some users. Offer to hide them, and don't push them in notifications.
• Notifications about data are interruptions: send summaries at a predictable time, and let users turn them off. See Honest & Calm.
• The data is theirs. Personal data deserves export, deletion, and care about what you collect at all. Amber Case's Calm Technology (2015) argues that technology should require the smallest possible amount of attention; for a stats screen, that means informing when asked and staying quiet otherwise.

In the wild

• Stravaweekly progress and Year in Sport
  The weekly view compares the current week with recent weeks; the annual Year in Sport recap is the celebratory, shareable moment, where illustration and big totals belong. Monitoring and celebration are different surfaces with different rules.
• Apple Activity ringsApple Watch, 2015
  Three rings against personal goals, which the user can change, with awards for milestones. A simple, legible goal beats an opaque score.
• Apple Screen TimeiOS 12, 2018
  The weekly report shows a percentage change against the previous week without saying what's normal or good for you, so the same notification can read as praise or reproach. A comparison with no personal baseline invites guilt.
• Duolingostreaks
  The streak is central, with streak freezes and repairs to soften breaks. Effective at engagement; also a clear example of how much power a single number can have over behaviour.

Maps, timelines and calendars are charts whose axes are place and time. Use geography only when location is the question, keep time proportional when duration matters, and always show "you are here" and "now".

Maps: is location the question?

A map is irresistible and often wrong. If the question is "which states have the most users?", a sorted bar chart answers it better: maps put the comparison into colour (low on the ladder) and give visual weight to land area, not to people. A large, empty region dominates a choropleth (a map with regions shaded by value) while a small, dense city disappears. Map when the question is genuinely spatial: where is it, what's near me, how does this spread, what's the route. And when you shade regions, use rates (per 1,000 people), not counts, or every map becomes a population map.

Topology over geography

In 1933 London Underground began issuing Harry Beck's diagram, which threw away accurate geography for a cleaner truth: what connects to what, and in what order. Lines run horizontal, vertical or at 45°; stations are evenly spaced; the crowded centre is enlarged. Riders don't need distances underground; they need sequence and interchanges. Massimo Vignelli's 1972 New York subway diagram took the same approach and was replaced in 1979, partly because New Yorkers, who walk between stations above ground, found its geographic distortions confusing. The lesson for software: choose the abstraction that matches the user's task, and know what you're sacrificing.

Minard and the multivariate map

Tufte's most famous example is Charles Joseph Minard's 1869 graphic of Napoleon's 1812 Russian campaign. A band whose width is the size of the army flows from the Polish border to Moscow and back, shrinking from about 422,000 men to 10,000, with a temperature chart along the bottom tied to the retreat. Tufte counts six variables in one picture: army size, two dimensions of location, direction, temperature and dates. Tufte wrote that it may well be the best statistical graphic ever drawn. Its lesson isn't "draw more variables"; it's that when the story is a relationship between variables, show them together on one shared frame so the causes are visible.

Timelines: time proportional, now visible

A list of times ("14:05, 14:40, 16:10") makes people compute gaps. A timeline makes gaps visible. When duration and gaps matter (travel, schedules, deliveries, build pipelines), draw time to scale, mark "now" with a line, and style the past differently from the future (muted vs full). Flight trackers and food-delivery apps use exactly this: a progress line along a sequence of stages, with the current stage emphasised and an estimated time to the next.

Calendars are information design

A calendar's day and week views are charts with time on one axis and days on the other. Good ones draw events with heights proportional to duration, so free time is visible as empty space, and show a "now" line so you know where you are. The month view is a different tool: it's for spotting busy and free days, so it summarises (dots, counts or shading) rather than listing everything. A month grid of shaded days is also the best form for habit and activity data, which is why the GitHub contribution graph and many habit apps use it.

In the wild

• London Underground diagramHarry Beck, 1933
  Topology over geography, still the model for transit maps worldwide. Abstraction is a design decision fitted to the task.
• Google Calendar and Fantasticalday and week views
  Events drawn with height proportional to duration and a horizontal line for the current time. Free time becomes visible empty space.
• Food delivery and ride appsorder tracking
  A stage timeline (ordered, preparing, on the way, delivered) with the current stage emphasised and an estimate, often alongside a live map. A timeline answers "how long?"; the map answers "where?".

Interactivity earns its place when it lets people ask "what if?" and see the answer immediately. Make the default view tell the story, let interaction deepen it, and never hide the main point behind a hover.

Chapter 1 argued that interaction is a cost in information software. Bret Victor's 2011 essay "Explorable Explanations" is the other side of the coin. He describes reactive documents, where the numbers in a text can be adjusted (by dragging them) and the conclusions update, so the reader can test the author's assumptions instead of trusting them. He built a small JavaScript library, Tangle, for exactly this. In "Up and Down the Ladder of Abstraction" (also 2011) he showed how controlling a parameter and seeing a whole family of results builds intuition that a single example can't.

The interaction here isn't navigation or querying. It's direct manipulation of the model: change an input, see every consequence at once. That's the kind of interactivity that teaches.

Examples worth studying

Nicky Case and Vi Hart's Parable of the Polygons (2014) turns Thomas Schelling's segregation model into a playable story: you move shapes, and see how small individual biases produce large-scale segregation. The New York Times Upshot's "You Draw It" (2015) asked readers to draw their guess of a trend before revealing the real data, so the gap between belief and fact was felt, not just read. Hans Rosling's Gapminder talks (his 2006 TED talk is the famous one) animated bubble charts of income and life expectancy over time, with Rosling narrating the story the motion showed. Bartosz Ciechanowski's long interactive articles (on mechanical watches, GPS, cameras) let you rotate and adjust working models of each idea.

Restraint: rules for interactive data

1. The default view tells the story. Most people won't interact. Analytics on news graphics have repeatedly suggested that only a minority of readers touch the controls, so anything hidden behind interaction is missed by most.
2. Tooltips are not labels. If a value matters, label it. Use tooltips (or taps) for the secondary details.
3. Hover doesn't exist on touch. Every hover interaction needs a tap equivalent, and a tap shouldn't be the only way to read critical information.
4. Immediate feedback. Inputs update the view as they change, with no Apply button, so cause and effect stay connected.
5. Keep the reference visible. When a parameter changes, show the original (a ghost line, the default value) so people see the difference, not just the new state.
6. Make state shareable and resettable. A reset button and, on the web, the state in the URL.
7. Accessible by keyboard and screen reader. Sliders with labels and values, and a text summary that updates (see Accessible & Inclusive).

In the wild

• Parable of the PolygonsNicky Case & Vi Hart, 2014
  A playable explanation of how small biases add up to segregation. Manipulating the model teaches a counter-intuitive result better than any chart.
• "You Draw It"The Upshot, New York Times, 2015
  Readers draw their guess of a trend line before the real data is revealed. Asking for a prediction makes the true answer memorable.
• GapminderHans Rosling, TED 2006
  Animated bubble charts of countries' income and life expectancy over two centuries, narrated live. Animation works for change over time when someone tells you what to watch.
• Bartosz Ciechanowskiinteractive essays
  Long-form articles with dozens of small manipulable models, each controlling one idea. Many small, focused interactions beat one big dashboard of controls.

Wrap-up

Practice assignment for the next two weeks

The goal: every number in your product is honest, formatted and in context, and you have one data surface you're proud of.

1. Days 1–2: Audit. Run the data display audit checklist (chapter 13) on your whole product. Screenshot every number, chart and table. Rank the problems by how often users see them.
2. Days 3–4: Foundations in code. Build the number formatter (Exercise 9.1), the base table CSS (Exercise 11.1) and a chart wrapper with clean defaults and a zero baseline for bars (Exercises 2.1 and 3.1).
3. Days 5–6: Context. Add a sparkline component and put context next to three numbers (Exercise 4.1). Redesign your stat tiles (Exercise 10.1).
4. Days 7–9: The main data screen. Redesign your stats page or dashboard: question first, the right chart for each question, crafted with the eight details, a generated title and verdict, and the bad-week copy written first (Exercises 7.1, 8.1, 13.1, 14.1).
5. Days 10–11: Small screens and time. Give your most-used table a 400px strategy (Exercise 12.1) and give one dated list a timeline or month view (Exercise 15.1).
6. Days 12–13: One what-if. Build a reactive sentence for one real user question (Exercise 16.1).
7. Day 14: Review. Show the before and after of your main data screen to two people for five seconds each and ask what it says. Write a short note on what you changed and what you learned, and file it with your portfolio (see The Solo Practice).

Reading list

• The Visual Display of Quantitative Information
  Edward Tufte, 1983 (2nd ed. 2001) · The source of data-ink, chartjunk, lie factor and small multiples. Read it with the critique from chapter 2 in mind.
• Envisioning Information and Beautiful Evidence
  Edward Tufte, 1990 and 2006 · Layering and separation, micro/macro readings, and sparklines. Visual Explanations (1997) completes the set.
• Magic Ink: Information Software and the Graphical Interface
  Bret Victor, 2006 (essay, worrydream.com) · The case for designing information software as graphics, with context replacing interaction. The most important essay in this guide for a software designer.
• Explorable Explanations and Up and Down the Ladder of Abstraction
  Bret Victor, 2011 (essays) · Reactive documents and building intuition by manipulating models.
• Graphical Perception
  William Cleveland & Robert McGill, Journal of the American Statistical Association, 1984 · The experiments behind the perceptual ranking. Pair with Heer & Bostock's 2010 CHI replication.
• Semiology of Graphics
  Jacques Bertin, 1967 (English 1983) · The original vocabulary of visual variables. Dense; skim for the variables and their properties.
• Show Me the Numbers and Information Dashboard Design
  Stephen Few, 2004/2012 and 2006/2013 · The most practical books on tables, graphs and dashboards; bullet graphs come from here.
• The Functional Art and How Charts Lie
  Alberto Cairo, 2012 and 2019 · Design thinking for graphics, and a calm guide to how charts mislead (and how to read them).
• The Wall Street Journal Guide to Information Graphics
  Dona Wong, 2010 · Short, rule-based and practical: what to do with bars, lines, pies, tables and numbers. Good desk reference.
• Storytelling with Data
  Cole Nussbaumer Knaflic, 2015 · Declutter, focus attention, and title with the point. The fastest route to better everyday charts.
• Useful Junk? The Effects of Visual Embellishment on Comprehension and Memorability of Charts
  Scott Bateman et al., CHI 2010 · The study that complicates "maximise data-ink". Read the abstract and results.
• Fundamentals of Data Visualization
  Claus O. Wilke, 2019 (free online) · A modern, well-illustrated survey of chart forms, colour and common pitfalls, with examples labelled "ugly", "bad" and "wrong" next to better versions.
• Visual Vocabulary
  Financial Times graphics team · A one-page chart chooser organised by the relationship you want to show. Print it.