warning3d-chart-distortion
What it is
A chart adds a third dimension or perspective effect — 3D pie, 3D bars, tilted/extruded views — that distorts the very encodings the reader must judge. Perspective foreshortening changes apparent sizes, near slices/bars look bigger than far ones, and occlusion hides data behind other marks — all for decoration that adds no information. This extends the domain's encoding-distortion theme but is not a specific sub-pitfall in the book.
How to spot it
In code and charts, flag 3D or perspective chart options — 3D pie/bar/area in spreadsheet tools, `projection='3d'` used purely for a 2D relationship, extrusion/bevel/shadow effects — where the third dimension encodes nothing. Be suspicious when foreground marks look larger than equal background ones, when slices/bars are occluded, or when a rotation angle changes which value looks biggest.
Pitfall
A 3D pie chart tilts the disc so the front slice looks substantially larger than an equal-sized slice at the back, and a deep bevel makes precise comparison impossible — the perspective changes the apparent shares even though the underlying numbers are identical.
Done well
The data is shown in a flat 2D chart (a plain pie/bar, or better a bar chart for precise comparison) where each mark's size encodes its value honestly, with no perspective, extrusion, or occlusion distorting the comparison.
How to fix it
Drop gratuitous 3D and perspective effects; use flat 2D encodings so size and length map directly to value. Reserve a true third spatial dimension only for data that genuinely has three continuous dimensions, and never tilt or extrude a chart for decoration.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6: Graphical Gaffes (domain extension — not a specific sub-pitfall example in the book) · Edward Tufte, The Visual Display of Quantitative Information (2nd ed., Graphics Press, 2001) — the lie factor
warningchart-omits-key-context
What it is
A chart is accurate as far as it goes but omits something more important — a "sin of omission." A static snapshot can be technically true yet miss the real story (a category's share is growing over time), and presenting data without its known caveats and exclusions (reported vs actual, excluded categories) leaves the audience with a false sense of completeness.
How to spot it
In prose and charts, flag a single snapshot used to make a point that a time trend or breakdown would materially change (a share shown as static when it's rising), and charts presented without the data's documented caveats — exclusions, "reported not actual," definition or coverage changes over time. Be suspicious when the most important fact about the data isn't shown, or when known disclaimers are left off the visual.
Pitfall
A pie chart shows theft as ~half of reported crimes (2010–2017) and stops there — omitting that theft's share climbed from 45% in 2010 to over 55% by 2017, the more important story, and omitting that the data is reported (not actual) crime with whole categories excluded.
Done well
Alongside the share snapshot, a timeline shows theft's growing proportion over the period, and the data's caveats (reported-not-actual, excluded crime categories, possible reporting-policy changes) are stated on or near the chart — so the audience gets the fuller, fairer picture.
How to fix it
Ask what the most important fact about the data is and make sure the visual conveys it, not just a true-but-incomplete snapshot; add the trend or breakdown that changes the interpretation. Always present the data's known caveats and exclusions with the chart rather than omitting them.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6A: Challenging Charts
infochart-type-dogmatism
What it is
Chart types are judged by blanket rules — "pie charts are bad," "word clouds are evil" — and banished from consideration, rather than evaluated by fit to the objective, audience, and context. Eliminating options up front shrinks the solution space and can rule out the choice that would actually work best for a given task.
How to spot it
This is mostly a mindset/process pitfall, visible in prose and review comments. Flag absolute claims that a chart type "never works" or "should never be used," critiques of a visualization made without knowing its objective/audience/context, and style guides that ban chart types outright. Be suspicious of dismissals based on chart type alone rather than on whether it serves the specific task.
Pitfall
A reviewer dismisses a word cloud as "always wrong" — but in the scenario (flashing the handful of most common, absurd passwords to a large room, including the back rows) the word cloud conveys the gist at a glance better than a bar chart that shows only 17 of 100 and needs scrolling.
Done well
The chart type is judged on fit to the task: the word cloud is accepted for the at-a-glance-gist scenario where precise comparison isn't needed, while a bar chart is chosen when precise magnitude matters — keeping all types in the toolkit and selecting by context.
How to fix it
Treat chart types as a toolkit, not a list of sanctioned and forbidden options. Judge a visualization by how well it serves its objective, audience, and context, keep less-common types available for the cases where they fit, and avoid blanket "good/bad" verdicts when critiquing others' work.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6B: Data Dogmatism
warningchart-type-message-mismatch
What it is
The chart type doesn't support the comparison the message requires. Part-to-whole points (a few categories make up three-quarters of the total) read clearly from a pie or treemap that forms a single cohesive whole, but get lost in separated bars or bubbles; conversely, treating a set as a "whole" when it isn't (heavy data caveats) makes a part-to-whole chart misleading.
How to spot it
In prose and charts, flag a mismatch between the claim and the encoding — a part-to-whole message shown with separated marks (bars, packed bubbles) that don't convey a unified whole, or a part-to-whole chart (pie/treemap) used when the data isn't a legitimate complete whole. Be suspicious when the audience can't see the stated relationship at a glance because the mark arrangement doesn't match the comparison.
Pitfall
To show that theft, burglary, and assault together are three of every four reported crimes, an analyst uses a bar chart and a packed bubble chart — but the separated marks don't form a cohesive whole, so the 75% share doesn't pop the way it does in a pie or treemap.
Done well
The part-to-whole point is shown with a pie or treemap whose three highlighted segments visibly reach ~75% of the whole — and only if the data is a legitimate whole; if heavy caveats mean it isn't, a non-part-to-whole encoding (like a bar chart) is used and the caveats are stated.
How to fix it
Match the encoding to the comparison: use a unified part-to-whole form (pie, treemap, stacked bar) for share-of-total messages, and separated marks for part-to-part. First confirm the data is a legitimate whole; if it isn't, avoid part-to-whole encodings or disclose what's excluded.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6A: Challenging Charts
warningcherry-picked-chart-window
What it is
A chart shows a narrow slice of the data — a short time window or restricted range — that creates an impression the full data would contradict or reverse. Whether by oversight or intent, presenting the slice as the story leaves the audience with a conclusion the broader context doesn't support.
How to spot it
In code and charts, flag time series or ranges filtered to a sub-window (a recent N weeks, a clipped axis domain) presented as a trend, with no view of or reference to the longer history. Be suspicious when the chosen window's slope or message reverses if extended, when start/end points look hand-picked, or when no rationale is given for the range. Compare the windowed view against the full series.
Pitfall
A 40-week window of reported narcotics cases trends sharply upward and is used to claim narcotics crime is rising — but the full 8-year series shows that window was a local bump within an overall decline, so the chart leaves the opposite of the true impression.
Done well
The trend is shown over the full available period (with the window of interest highlighted if needed), so the audience sees the recent movement in the context of the long-run trend and isn't misled by a cherry-picked slice.
How to fix it
Show data over a range justified by the question, and check whether the message survives when the window is extended. Disclose why a particular window was chosen, highlight rather than crop the broader context, and stay alert that a short slice can reverse a long-run trend.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6A: Challenging Charts
errordisproportionate-encoding
What it is
The size of a mark — a bar's length, a wedge's angle, a bubble's area — does not match the value it represents under any consistent scale. Equal values render at different sizes, or unequal values render at nearly the same size, so the picture misstates the magnitudes it claims to show. This is Tufte's "lie factor" departing from 1: the effect shown in the graphic is not proportional to the effect in the data. It extends the domain's encoding-integrity theme and is distinct from a merely truncated baseline (where bars are still ordered and consistent with one another) and from 3D/perspective distortion (where the misreading comes from a tilt or extrusion).
How to spot it
Where values are labeled, compare the ratios of the rendered sizes to the ratios of the labels. Flag when the geometry cannot be reconciled with the numbers under one linear scale: two equal labels drawn at different sizes, a value twice another shown at near-equal size, or a mark whose size implies a value far from its label. Rule out innocent explanations first — a clearly stated non-linear (log) axis, or a non-zero baseline that still preserves the ordering — and only flag when no single consistent scale fits. In code, watch for bar lengths, heights, or widths set from a constant or from something other than the plotted value. When the marks are pictographs (icons, human silhouettes, unit-shaped figures) that scale in two dimensions, check for a truncated baseline *first*: a nonzero value axis is often the root cause and the 2-D area amplification only the visible symptom sitting on top of it. If the smallest value renders at roughly zero size (a figure that shrinks to nothing or is absent), treat truncated-y-axis as the primary finding and disproportionate encoding as the compounding one, rather than the reverse.
Pitfall
A bar chart labels four models 74.9, 52.8, 69.1, and 30.8, but the 69.1 and 30.8 bars are drawn at almost the same height while the 74.9 bar towers over both — no single scale maps these heights to those numbers, so the chart's lengths simply do not encode the data.
Done well
Every bar's height is set by the same linear scale from a zero baseline, so a value twice as large is drawn twice as tall and two equal values are exactly the same height — the rendered lengths are proportional to the numbers they represent.
How to fix it
Drive every mark's size from the data through one consistent scale, and check the rendered sizes against the labels (a value twice another should look twice as big). Keep the lie factor at 1: don't hand-size marks, don't start a length-based axis off zero, and if a non-linear scale is genuinely needed, label it clearly so readers can decode the sizes.
Edward Tufte, The Visual Display of Quantitative Information (2nd ed., Graphics Press, 2001) — the lie factor and graphical integrity · Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6: Graphical Gaffes (domain extension — not a specific sub-pitfall example in the book)
warningdual-axis-distortion
What it is
A chart plots two series against two independent y-axes with different scales, so their apparent relationship — crossovers, which line is "higher," how closely they track — is an artifact of the arbitrarily chosen scales rather than the data. By sliding the two axes, almost any visual correlation or dominance can be manufactured. This extends the domain's encoding-distortion theme but is not a specific sub-pitfall in the book.
How to spot it
In code and charts, flag dual-axis (secondary-axis) plots — `twinx()` in matplotlib, a secondary axis in Excel/Tableau, two `y`/`y2` encodings — especially where the two scales are set independently with no principled alignment, where series in different units are overlaid to suggest they move together, or where a crossover point carries the message. Be suspicious when shifting either axis would change the apparent story.
Pitfall
A chart overlays revenue (left axis) and complaints (right axis) on independent scales chosen so the two lines cross dramatically mid-year, implying complaints "overtook" revenue — but the crossover is purely a function of where each axis was set, not a real relationship.
Done well
The relationship is shown without scale trickery — indexing both series to a common base (e.g. % change from the start), using small multiples, or plotting one against the other in a scatterplot — so any co-movement reflects the data. If a dual axis is unavoidable, the scales are aligned on a principled basis and labeled clearly.
How to fix it
Avoid dual axes when the message is about how two series relate; prefer indexing to a common baseline, small multiples, or a scatterplot. If a secondary axis is truly necessary, fix the scales on a principled, disclosed basis and don't let arbitrary scaling manufacture crossovers or co-movement.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6: Graphical Gaffes (domain extension — not a specific sub-pitfall example in the book) · Alberto Cairo, How Charts Lie (Norton, 2019) — dual axes and scale manipulation
warningeda-noise-mistaken-for-signal
What it is
During fast exploratory analysis, a pattern is taken as real without pausing to check whether it's signal or noise. Dragging a trendline onto a series and declaring it "rising" can mislead when a method that accounts for variation (such as a control chart) shows the movement is within normal noise.
How to spot it
In code and prose, flag conclusions drawn from a quick visual impression — a fitted trendline, an eyeballed slope — with no test that the variation exceeds noise (control chart, control limits, significance test). Be suspicious of rapid "explore many charts, publish the striking one" workflows, of trend claims over series with large month-to-month variation, and of no run/limit analysis before asserting a change.
Pitfall
An analyst drags a trendline over monthly reported thefts, sees it slope upward, and concludes theft is rising every month — but an individuals control chart shows 35 straight months of statistical noise since early 2015, with no significant change.
Done well
Before claiming a trend, the analyst views the series on a control chart (or runs a signal-vs-noise test), distinguishing genuine signals (runs, shifts, points beyond the limits) from noise — and tempers the "rising" claim to what the data actually supports.
How to fix it
Slow down in exploration: before treating a visual pattern as real, check it against a method that separates signal from noise (control chart, run rules, significance test). Don't publish the first striking chart; confirm the pattern exceeds normal variation.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6A: Challenging Charts
warningencoding-order-mismatch
What it is
An encoding choice expresses an order that is not in the data. Ordered data is shown with a visual channel whose perceived order — most often the lightness or intensity of a color ramp — disagrees with the data's order: a binned palette whose colors get lighter and then darker as values rise, a top class drawn in a less intense color than the class below it, or a pattern fill dropped into the middle of an otherwise ordered ramp. Readers rank values from the encoding preattentively, before they ever consult the legend, so the chart teaches them a ranking the numbers don't support. This extends the domain's encoding theme but is not a specific sub-pitfall in the book.
How to spot it
Read the legend in data order and check that perceived intensity follows it: for sequential or binned scales, lightness (or saturation) should change monotonically from the lowest class to the highest. Flag ramps that reverse direction partway, a most-extreme class that is not drawn in the most extreme color, hue changes that scramble the lightness sequence, and pattern or hatch fills mixed into an ordered color ramp. In code, flag hand-assembled palettes for ordered data whose lightness sequence is non-monotonic. A chart whose most visually dominant color does not mark its most extreme class deserves particular suspicion.
Pitfall
A map of confirmed cases by state uses light red for "1,000,000+", dark red for "500,000+", orange for "100,000+", and yellow for "1,000+". The darkest, most alarming color marks the second-highest class, so viewers read half-million-case states as worse than million-case states — the perceived color order contradicts the data order.
Done well
The same map uses a single-hue sequential ramp from pale yellow to deep red in which each higher class is strictly darker, so the states viewers perceive as most intense are exactly the states with the most cases — with or without reading the legend.
How to fix it
Make the perceived order of the encoding match the data's order. Use a single-hue or perceptually uniform sequential ramp for ordered data, keep lightness strictly monotonic across bins, keep pattern fills out of color ramps, and give the most extreme class the most extreme color. Before publishing, read the legend top-to-bottom against the data order and squint-test the chart: the values that should dominate visually are the values that dominate numerically.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6: Graphical Gaffes (domain extension — not a specific sub-pitfall example in the book) · Munzner (2014), Visualization Analysis and Design, ch. 5 — channel effectiveness for ordered attributes
warningincoherent-axis-scale
What it is
An axis's tick labels are internally contradictory, so no consistent scale exists and no reader can map a position to a value. Adjacent ticks repeat the same label, the labels don't run monotonically (a smaller value sits where a larger one should, or the sequence reverses partway), or the same value appears on ticks that should be distinct. This is distinct from a truncated baseline (the scale is real, just not zero-based) and from an unevenly spaced axis (the labels are correct and ordered, only their spacing is disproportionate) — here the labels themselves are broken, so the axis lies about its own scale before any mark is even read. It extends the domain's encoding-integrity theme and is not a specific sub-pitfall in the book.
How to spot it
Read the tick labels in order along the axis and check that they form one coherent scale: flag when adjacent ticks carry the same label, when the labels don't increase (or decrease) monotonically, when a smaller value is positioned above/beyond a larger one, or when a value is duplicated across ticks that should be distinct. Separate this from `unevenly-spaced-axis` (labels are valid and monotonic but the gaps aren't proportional) — reach for this rule only when the labels are self-contradictory, so no single scale can fit them. In code, watch for hand-set tick text overriding computed positions, a formatter that over-rounds distinct values to the same string (e.g. two ticks both rendering "5'6\""), or categorical labels reused across positions.
Pitfall
A height chart's right-hand axis reads, top to bottom, 5'0", 5'9", 5'7", 5'6", 5'6", 5'6", 5'6", 5'5", 5'5", 5'5": the same label repeats on adjacent ticks and 5'0" sits above 5'9", so the axis contradicts itself — a reader cannot decode any mark's height from it because the ruler itself is not a valid scale.
Done well
The ticks carry distinct, monotonically ordered labels at a consistent interval — 5'5", 5'6", 5'7", 5'8", 5'9", 5'10" — so every gridline maps unambiguously to one value. If rounding would collapse distinct values to the same label, precision is increased or the interval widened so each tick stays unique.
How to fix it
Let the plotting library derive ticks from the scale rather than hand-labeling them, and keep the tick formatter precise enough that adjacent labels stay distinct. Before publishing, read the axis top to bottom (or left to right) and confirm the labels are unique where they should be and run monotonically — an axis a reader can't decode is worse than no axis at all.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6: Graphical Gaffes (domain extension — not a specific sub-pitfall example in the book) · Alberto Cairo, How Charts Lie (Norton, 2019) — dubious and self-contradictory chart scales
warninginconsistent-scales-across-charts
What it is
Several charts that invite comparison — small multiples, a dashboard's panels, a before/after pair — use different axis scales, ranges, or units for the same measure, so equal visual heights or lengths stand for different values. Readers naturally compare the marks across panels and draw conclusions the numbers don't support. It extends the domain's encoding-integrity theme to the relationships *between* charts, which a single-chart review can't catch.
How to spot it
Only applies when more than one chart is shown together. For charts that plot the same (or a comparable) quantity, compare their axes: differing y-axis ranges or maxima, one panel truncated while another starts at zero, different units or transforms (counts vs. percentages, linear vs. log), or mismatched bin widths. Flag when a reader comparing marks across the charts would be misled because the scales don't match; name the charts involved. Do not flag charts that legitimately measure different things.
Pitfall
A dashboard shows four regional sales bar charts side by side; three use a 0–100 y-axis but the fourth uses 0–500, so its tall-looking bar actually represents a smaller share — yet at a glance it appears to be the biggest performer.
Done well
All four regional charts share one fixed y-axis (0–500) and the same units, so bar heights are directly comparable across panels and the largest bar really is the largest value.
How to fix it
Put charts meant to be compared on a single shared scale — same axis range, units, and transform — ideally as true small multiples. If a panel genuinely needs its own scale, make that unmistakable (clear per-panel axis labels, or don't place it where readers will compare it directly).
Edward Tufte, The Visual Display of Quantitative Information (2nd ed., Graphics Press, 2001) — small multiples and consistent scales · Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6: Graphical Gaffes (domain extension — not a specific sub-pitfall example in the book)
warninginsufficient-precision-comparison
What it is
A chart is asked to convey a fine distinction (one value just edges out another) using an encoding that can't show it precisely. Encodings without a common baseline — pies, bubbles, treemaps, disconnected marks — let the audience see "roughly equal" but not which is larger, so the intended point doesn't land without labels.
How to spot it
In prose and charts, flag a claim about a small or close difference paired with an encoding that lacks a shared baseline or precise scale (area/angle encodings, packed bubbles, side-by-side pies) and no data labels. Be suspicious when the message hinges on which of two near-equal values is larger but the chart can only show approximate magnitude. Length on a common baseline (bars) or explicit labels are needed for precise comparison.
Pitfall
To show that assault just barely outpaced narcotics from 2010–2017, the analyst uses pies, bubbles, and treemaps — none of which share a baseline — so the audience can see the two are close but cannot tell which is larger without labels.
Done well
A bar chart with a common baseline (optionally with value labels and gridlines) is used, so the slightly longer assault bar makes the precise comparison immediately clear — the encoding affords the precision the message requires.
How to fix it
When the message depends on a precise or close comparison, use a position/length encoding with a common baseline (bar chart), and add data labels or gridlines if even finer precision is needed. Reserve area/angle encodings for cases where approximate magnitude is enough.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6A: Challenging Charts
infooptimize-satisfice-false-dichotomy
What it is
Visualization choice is framed as either finding the one "best" chart or settling for any "good enough" one — and success is often judged on comprehensibility alone. In reality both optimizing and satisficing have their place depending on tractability, available information, and time, and a visualization's payoff includes more than comprehension: attention, impact, aesthetics, memorability, and resulting behavior.
How to spot it
This is a mindset/process pitfall, visible in prose and review. Flag claims that there is exactly one correct visualization, or that "good enough" is never acceptable, and evaluations that score a visualization solely on comprehension/precision while ignoring whether it drew attention, was remembered, or drove action. Be suspicious of a single-criterion payoff function and of demands for optimization when time or information don't allow it.
Pitfall
A critic insists the only valid measure of a chart is how precisely the audience can read the values, and rejects a more memorable, attention-grabbing design that was "good enough" on comprehension and far better on impact — even though the goal was to get a busy board to care and act.
Done well
The team weighs the payoff across the factors that matter for the goal (comprehension plus attention, impact, aesthetics, memorability, behavior), optimizes when the problem is tractable and time allows, and otherwise satisfices to a stated acceptability threshold — acknowledging both approaches are legitimate.
How to fix it
Don't treat optimize versus satisfice as either/or, and don't judge visualizations on comprehensibility alone. Define the payoff factors that matter for the specific goal and audience, optimize when tractable and time permits, satisfice to an explicit threshold otherwise, and accept that more than one design can be fit for purpose.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6C: The Optimize/Satisfice False Dichotomy
warningoverloaded-confusing-chart
What it is
A chart crams in so much that the audience can't extract the intended message — too many overlapping series ("spaghetti"), a color palette recycled across more categories than it has colors, and the series of interest left in a low-salience default. The viewer doesn't walk away with the wrong idea; they walk away with no idea, and give up.
How to spot it
In code and charts, flag many overlapping series in one view (a dozen-plus lines), categorical color scales applied to more categories than the palette has distinct colors (so hues repeat), the key series left a default low-contrast color, and charts that require interaction (hover/click) to read in a static context. Be suspicious of legends longer than the palette and of no visual hierarchy distinguishing the focus series.
Pitfall
A line chart shows 24 crime categories at once; the 20-color palette recycles hues so two lines share a color, the "shoplifting" series of interest is a faint default beige lost in the tangle, and you must hover to tell which line is which.
Done well
The focus series (shoplifting) is given a bold, unique color while the rest are de-emphasized with transparency or gray, the number of fully-colored series is kept within the palette, and the chart reads clearly in static form without requiring interaction.
How to fix it
Reduce what's in the view and build a visual hierarchy: emphasize the focus series with a distinct color, mute or aggregate the rest, and keep the number of distinctly-colored categories within the palette's size. Ensure the chart conveys its point statically, without relying on hover or click.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6A: Challenging Charts
warningrainbow-color-scale
What it is
A rainbow (jet) color scale is used to encode an ordered, continuous variable. Because the rainbow's perceived brightness isn't monotonic and its hue bands aren't evenly spaced, it introduces false boundaries where colors change sharply, hides real gradients where they don't, and misranks values — and it's largely unreadable for colorblind viewers. A perceptually uniform scale represents the data far more faithfully. This extends the domain's encoding theme but is not a specific sub-pitfall in the book.
How to spot it
In code and charts, flag sequential/continuous data encoded with a rainbow/jet palette — `cmap='jet'`/`'rainbow'`/`'hsv'` in matplotlib, default rainbow ramps in older tools, multi-hue spectral scales used for magnitude. Be suspicious of heatmaps, choropleths, and contour plots that show sharp color bands not present in the data, and of palettes that aren't colorblind-safe. Continuous magnitude should use a perceptually uniform or single-hue sequential scale.
Pitfall
A heatmap of temperature uses the jet rainbow scale; viewers perceive a hard boundary at the green-to-yellow transition that isn't in the data and miss the real gradient in the blue region, while red-green colorblind readers can't order the colors at all.
Done well
The same heatmap uses a perceptually uniform sequential scale (e.g. viridis), so equal steps in value look like equal steps in color, no false boundaries appear, the gradient is visible throughout, and the palette stays legible to colorblind viewers.
How to fix it
Encode ordered/continuous data with a perceptually uniform or single-hue sequential scale (viridis, cividis, ColorBrewer sequential), and reserve hue for categorical distinctions. Check palettes for colorblind safety, and avoid rainbow/jet ramps for magnitude.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6: Graphical Gaffes (domain extension — not a specific sub-pitfall example in the book) · Borland & Taylor (2007), 'Rainbow Color Map (Still) Considered Harmful,' IEEE Computer Graphics & Applications 27(2)
warningtask-mismatched-visualization
What it is
A chart is technically fine but doesn't help the user accomplish their actual task, because the wrong variable is mapped to an axis (or the wrong encoding/aggregation is chosen) for the question at hand. The chart-type debate misses the point; what matters is whether the user can get their job done with the view.
How to spot it
In prose, specs, and code, flag visualizations built without a clear statement of the user's task and the question it must answer — dashboards reused for a purpose they weren't designed for, an axis showing distance when the task needs time, summaries at the wrong grain. Be suspicious when no one has defined user, task, data, and performance requirements, or when answering the real question requires mental math the chart should have done.
Pitfall
A hiker needs to know how long it takes to reach a summit, but the fitness dashboard plots elevation against distance with no time axis — so "two hours to the top" can't be read off directly, and pace varies up versus down, defeating back-of-envelope estimates.
Done well
A chart is added with time on the x-axis (altitude or cumulative distance on the y-axis), making the ascent time directly readable — the encoding is chosen to fit the specific question rather than defaulting to whatever the tool produced.
How to fix it
Start from the user and their task: define who will use the view, what question it must answer, the relevant data, and the performance needs, then choose the encoding (especially which variable goes on each axis) that lets them read the answer directly. Validate the chart against real usage, not a chart-chooser checklist.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6A: Challenging Charts
warningtruncated-y-axis
What it is
A bar or column chart's value axis doesn't start at zero, so the bar lengths no longer encode the values proportionally. Because length is the visual encoding, a truncated baseline exaggerates the differences between bars and can make a small change look dramatic. Line charts and some non-length encodings may legitimately omit zero, so the problem is specific to length-encoded marks. The book mentions axis truncation only in passing; this captures it as a standalone rule.
How to spot it
In code and charts, flag bar/column/area charts whose value axis starts above zero — explicit axis limits or scale domains excluding zero (matplotlib `set_ylim`, ggplot `coord_cartesian`/`ylim`, Vega-Lite `scale: {zero: false}`, an Excel minimum bound). Be suspicious of bar charts where a tiny percentage change fills most of the plot, and of a y-axis minimum set just below the smallest value. Scope the check to length-encoded marks, not line/dot charts where omitting zero can be fine — but note that pictorial or pictograph bars (icons, silhouettes, "unit-shaped" marks whose height carries the value) are length-encoded too and can be truncated just like plain rectangles. A strong tell is a missing or vanishing smallest mark: when the row with the lowest value renders at (or near) zero height — e.g. the shortest human silhouette is absent entirely — the baseline has been parked at that smallest value, which is textbook truncation. The pictograph costume hides it, because a zero-height figure reads as "they forgot to draw it" rather than as a cut-off axis.
Pitfall
A column chart of quarterly revenue ($1.02M, $1.04M, $1.05M) with a y-axis running $1.00M–$1.06M makes a ~3% change look like a near-tripling, because the truncated baseline stretches tiny differences across the whole plot.
Done well
The same bars are drawn with the value axis starting at zero, so their lengths reflect the true proportional differences — or, if the small change is the real story, it's shown with a line chart, a dot plot, or an explicit percentage-change label that doesn't rely on bar length.
How to fix it
Start the value axis at zero for bar/column/area charts so length encodes value honestly. If small differences are the point, switch to an encoding that doesn't rely on length (line, dot plot, or a stated delta) rather than truncating the baseline of bars.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6: Graphical Gaffes (domain extension — the chapter mentions y-axis truncation only in passing, not as a sub-pitfall) · Darrell Huff, How to Lie with Statistics (Norton, 1954); Alberto Cairo, How Charts Lie (Norton, 2019)
warningunevenly-spaced-axis
What it is
A quantitative axis gives each labeled tick an equal-width slot even though the numeric intervals between labels are unequal, so position along the axis no longer encodes the value proportionally. The most common case is time plotted on a categorical axis — a ten-year gap occupying the same distance as a one-year gap — but the same distortion happens on any numeric axis whose labels jump irregularly at even spacing (e.g. a height axis running 5'5", 5'6", 5'7", 5'9" across evenly spaced ticks). Because equal distance no longer means equal difference, slopes and gaps are misread: irregular sampling reads as steady progression, change over wide gaps looks abrupt, and change across narrow gaps looks gradual. This extends the domain's encoding-distortion theme but is not a specific sub-pitfall in the book.
How to spot it
Read the axis tick labels as numbers or dates and check whether their numeric gaps match their visual spacing — equally spaced ticks whose labels jump irregularly (1969, 1972, 1973, 1977, ... 1985, 1995, 2000; or 5'5", 5'6", 5'7", 5'9") are the giveaway, especially on line charts where slope carries the message. The classic and most frequent form is a time axis: in code, flag temporal values plotted as strings or categories — years cast with `.astype(str)`, matplotlib or pandas plots over string-typed date columns, Vega-Lite `ordinal`/`nominal` (or Tableau discrete, Excel "text axis") encodings on a temporal field, and bar-style categorical axes used for a time series. But apply it to any quantitative axis: a numeric field placed on a categorical/ordinal scale, or hand-placed ticks at even intervals whose labels are not evenly spaced in value. Distinct from `misleading-interpolation` (even if connecting sparse points is acceptable, the axis itself must still give each interval its proportional width) and from `incoherent-axis-scale` (there the labels are broken or non-monotonic; here they are valid and ordered, only spaced disproportionately).
Pitfall
A line chart of poll results plots survey years 1969-2020 as equally spaced category labels. The decade with no surveys (1985-1995) gets the same width as single-year gaps, so a rise that took 51 years with long quiet stretches reads as one smooth, near-linear climb — the slope between any two points is an artifact of slot spacing, not time.
Done well
The same series is plotted on a continuous (quantitative or date-typed) axis, so the 1985-1995 gap is ten slots wide and the annual surveys cluster tightly; markers show where measurements actually occurred, and the varying steepness between them now honestly reflects change per unit of the axis variable.
How to fix it
Plot the axis variable on a continuous (quantitative or date-typed) scale so distance is proportional to difference — for time that means keeping dates as dates rather than strings, or switching the axis from categorical/discrete to continuous; for any other numeric field, use a linear scale rather than one evenly spaced tick per observation. Mark the observed points so sparse coverage stays visible, and if the gaps are large, consider annotating them rather than letting equal spacing paper over them.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 6: Graphical Gaffes (domain extension — not a specific sub-pitfall example in the book) · Alberto Cairo, How Charts Lie (Norton, 2019) — distorted and dubious chart scales
Data Pitfalls