warningcolorblind-unsafe-palette
What it is
A color encoding relies on hue distinctions that color-vision-deficient viewers can't perceive — most notoriously red-green, which is indistinguishable to the most common forms of colorblindness (roughly 1 in 12 men). The encoding works for some of the audience and silently fails for the rest, who can't read the chart's meaning at all.
How to spot it
In code and charts, flag palettes that distinguish categories or good/bad by red versus green, or other hue pairs that collapse under common color-vision deficiencies, with no redundant cue (shape, position, label, lightness). Be suspicious of traffic-light (red/amber/green) status encodings, diverging red-green scales, and any palette not checked against a colorblind simulator. Color should not be the sole channel carrying meaning.
Pitfall
A status dashboard marks accounts "red" for at-risk and "green" for healthy with no other cue, so a red-green colorblind manager sees two near-identical muddy tones and cannot tell which accounts need attention.
Done well
The encoding uses a colorblind-safe palette (e.g. blue/orange) and adds a redundant channel — an icon, label, or position — so the at-risk/healthy distinction is legible to everyone, and the palette is verified with a colorblind simulator.
How to fix it
Choose colorblind-safe palettes (avoid red-green for meaningful distinctions), and never let color be the only channel carrying information — add shape, text, position, or lightness as a redundant cue. Test palettes with a color-vision- deficiency simulator before shipping.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 7A: Confusing Colors
warningdesign-induced-user-error
What it is
When users misread or misuse a visualization, the design blames the user instead of treating the error as a design flaw to fix. People make slips (meaning one thing, doing another) and mistakes (the wrong goal or plan); a visualization that lets or induces these errors is badly designed. If someone draws a wrong conclusion from your chart, that's at least as much your problem as theirs.
How to spot it
In process and prose, flag visualizations shipped with no usability testing — no watching real users interact, no iteration on observed errors — and a posture of explaining away user confusion ("they should've known better") rather than redesigning. In UI, be suspicious of designs that make wrong actions easy (mis-tappable adjacent controls, misleading default filters) or invite misinterpretation, with no guardrails.
Pitfall
Users keep filtering a dashboard to a subset that introduces selection bias and reach wrong conclusions; the designer dismisses it as user error and adds an instruction, rather than recognizing the design induced the mistake and changing it.
Done well
The team watches real users interact, writes down every slip and mistake instead of blaming the tester, and iterates the design to prevent those errors — assuming that if one tester erred, many real users will, and the only chance to fix it is to prevent it.
How to fix it
Treat user errors as design defects: build, test with real users, watch where they slip or misinterpret, and iterate to prevent it rather than explaining it away. Design out easy wrong actions and misleading defaults, and remember you won't be there to correct users later.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 7C: Usability Uh-Ohs
warninginaccessible-contrast
What it is
Text or marks are rendered with too little contrast against their background — light gray on white, thin colored text, faint labels — so they're hard or impossible to read for users with low vision, on poor displays, or in bright light. The chart may look sleek to the designer but excludes part of the audience. This extends the domain's accessibility theme but is not a specific sub-pitfall example in the book.
How to spot it
In code, charts, and CSS, flag foreground/background color pairs whose contrast ratio falls below accessibility thresholds (WCAG 2.1 AA: 4.5:1 for normal text, 3:1 for large text and meaningful graphics), light-gray-on-white body text, thin or low-weight colored text, and axis labels/annotations in faint tones. Be suspicious of palettes chosen for looks with no contrast check, and of color on small text. Verify ratios with a contrast checker.
Pitfall
A dashboard renders axis labels and footnotes in #BBBBBB light gray on a white background (about a 1.9:1 contrast ratio), so low-vision users and anyone on a glary laptop screen outdoors simply can't read the numbers.
Done well
The same labels are darkened to meet at least WCAG AA (4.5:1 for normal text) — e.g. dark gray on white — and contrast is verified with a checker, so the text is legible across vision levels, displays, and lighting.
How to fix it
Check every text/background and meaningful mark/background pair against WCAG contrast minimums (4.5:1 normal text, 3:1 large text and graphical objects), and darken or adjust until they pass. Don't trade legibility for a low-contrast aesthetic; verify with a contrast tool.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 7: Design Dangers (domain extension — not a specific sub-pitfall example in the book) · W3C Web Content Accessibility Guidelines (WCAG) 2.1, Success Criterion 1.4.3 Contrast (Minimum)
warninginconsistent-color-encoding
What it is
Across a multi-view dashboard, the same color (or the same hue at a given saturation) is used to mean different things — encoding one variable in one chart and an unrelated variable in another, or serving as two separate sequential scales for different measures. Viewers infer a connection between marks that share a color when none exists, or read the wrong legend, and are misled.
How to spot it
In code and charts, flag dashboards where a color palette or hue is reused across views that encode different fields — the same categorical colors applied to two different dimensions, or two sequential legends built on the same hue for different measures/aggregations. Be suspicious when two charts sit side by side with overlapping colors that mean different things, when there are multiple color legends, or when color is applied redundantly (a bar chart already encoding magnitude by length also colored by the same measure).
Pitfall
A marathon dashboard places a finish-time histogram next to a finisher-origin treemap that share a palette, so the same red encodes both "Chicago/Portland" and "4–5 hour finishers" — implying a link that doesn't exist; elsewhere one turquoise sequential scale means county road-miles in a map and road-type miles in a bar chart at once.
Done well
Each variable gets its own distinct, non-overlapping color treatment (or the conflicting charts are separated), and redundant color is removed — e.g. the bar chart, which already encodes magnitude by length, drops its color scale so the dashboard's one sequential hue means only one thing.
How to fix it
Make every color mean exactly one thing across the whole dashboard. Don't reuse a hue or palette for unrelated variables or as two different scales; remove redundant color encodings, and if two charts genuinely need different color meanings, separate them or use clearly distinct schemes.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 7A: Confusing Colors
warninginconsistent-encoding-across-charts
What it is
Across a set of charts — a dashboard, a slide sequence, a report's figures — the same visual channel means different things, or the same thing is shown different ways. A color that marks one category here marks another there; a series is blue in one chart and orange in the next; legends or orderings shift between panels. Readers build a mental key from the first chart and the later ones quietly break it, so they misread the data. Unlike inconsistent encoding *within* one chart, this only shows up when the charts are reviewed together.
How to spot it
Only applies when more than one chart is shown together. Check whether the encoding is stable across the set: does each category/series keep the same color, shape, and size meaning in every chart? Are legends, category orderings, and units consistent? Flag a reused hue that means different things across charts, a single entity drawn in different colors, or a legend that changes between panels — and name the charts involved.
Pitfall
In a quarterly dashboard, "Revenue" is the green line in the first chart but green marks "Costs" in the second, while Revenue switches to blue — a reader tracking the green line across panels follows two different metrics.
Done well
One shared legend governs the whole dashboard: Revenue is always blue, Costs always red, in the same order, with the same units, so a color means exactly one thing across every chart.
How to fix it
Define one encoding for the whole set and apply it everywhere: fix each category/series to a single color (and shape/size meaning), keep legend, ordering, and units identical across charts, and surface a shared legend. If two charts genuinely need different encodings, make the schemes visibly distinct so readers don't carry the wrong key over.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 7: Design Dangers (domain extension — not a specific sub-pitfall example in the book)
warninginconsistent-formatting
What it is
Numbers, dates, units, labels, and styling are formatted inconsistently across a chart or dashboard — mixed date formats, varying decimal places, currency sometimes shown and sometimes not, different capitalization or terminology for the same thing. The inconsistency forces the reader to constantly re-orient, erodes trust, and invites misreading. This extends the domain's clarity theme but is not a specific sub-pitfall example in the book.
How to spot it
In code and charts, flag the same quantity formatted differently across views (decimal places, thousands separators, units, currency symbols, percent vs proportion), mixed date formats (MM/DD/YY vs DD-Mon-YYYY), inconsistent capitalization or naming for the same field/category, and ad-hoc per-chart styling instead of a shared format. Be suspicious when no formatting standard is applied across a dashboard.
Pitfall
One panel shows revenue as "$1.2M," another as "1200000," and a third as "1,200 (k)"; dates appear as "01/02/25" in one chart and "2 Jan 2025" in another, and the same category is "N. America" here and "North America" there — the reader must keep re-deciphering.
Done well
A single formatting standard is applied throughout — consistent units and decimal places for each measure, one date format, one name per category, shared number/currency formatting — so values are directly comparable at a glance and nothing has to be re-interpreted.
How to fix it
Define and apply consistent formatting across the whole deliverable: one date format, fixed decimal places and units per measure, consistent currency/percent display, and one canonical label per field or category. Centralize formatting rather than styling each chart ad hoc.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 7: Design Dangers (domain extension — not a specific sub-pitfall example in the book) · Jakob Nielsen (1994), '10 Usability Heuristics for User Interface Design' — consistency and standards
warningmobile-responsiveness-neglect
What it is
A visualization or dashboard is designed only for a large desktop screen and breaks on the small screens where much of the audience actually views it — tiny unreadable labels, controls that fall off-screen or can't be tapped, horizontal scrolling, a dense multi-panel layout crammed onto a phone. Richness that worked on a monitor becomes a confusing, unusable experience on mobile. This extends the chapter's mobile-interaction discussion but isn't developed as its own sub-pitfall.
How to spot it
In code and UI, flag fixed-width dashboards and charts with no responsive layout, no breakpoints, tap targets too small for a finger, text sized for desktop only, and dense multi-panel views never tested at phone width. Be suspicious of visualizations published to a broad web audience with no mobile rendering check, and of interactions (hover-only tooltips) that don't work on touch.
Pitfall
A four-panel interactive dashboard built at 1400px renders on a phone as a sliver of unreadable text, with hover-only tooltips that touch can't trigger and filters pushed off the edge — most of the mobile audience can't use it at all.
Done well
The visualization adapts to screen size — reflowing or simplifying panels for small screens, sizing text and tap targets for touch, and replacing hover-only interactions with tap-friendly ones — so it stays usable from phone to desktop, and it's tested at multiple widths.
How to fix it
Design and test for the screens the audience actually uses: add responsive breakpoints, size text and tap targets for touch, ensure controls and tooltips work without a mouse, and simplify or reflow dense layouts for small screens rather than shrinking them. Verify on real devices.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 7C: Usability Uh-Ohs (domain extension — generalizes the mobile-interaction discussion in the book) · Ethan Marcotte, Responsive Web Design (A Book Apart, 2011)
infoomitted-aesthetic-opportunity
What it is
A chart is clear and correct but purely utilitarian, missing the chance to engage the audience and evoke the subject — a "sin of omission" on the aesthetic side. Because cognition and emotion are linked, an unengaging visual can fail to capture attention or stick in memory even when it's accurate. The flip side matters too: aesthetic flourishes must not be added at the expense of clarity, and some audiences and contexts don't want them.
How to spot it
This is a mostly aspirational, context-dependent pitfall, visible in design review. In prose and charts, consider whether a visualization meant to engage a broad or public audience does anything to draw attention, fit its subject, or be memorable, or whether it's a default-styled chart where engagement is a stated goal. Conversely, flag decorative elements that reduce clarity or could mislead. Weigh the audience: utilitarian operational reports may rightly want no flourish.
Pitfall
A timeline of Edgar Allan Poe's works is a plain bright-blue column chart — accurate, but evoking nothing of his moody, haunting subject matter, missing an easy chance to engage readers who would connect with the topic.
Done well
The same data is rendered to fit the subject — columns stacked downward in blood-red with the author's public-domain portrait and signature filling a natural gap — adding engagement and meaning without distorting the values, while staying ready to drop the flourish for audiences that don't want it.
How to fix it
For visualizations meant to engage, ask what aesthetic choices would draw attention and fit the subject, and use them where they add (not subtract) meaning. Guard the clarity/aesthetics trade-off: test flourishes with real audience members, and omit them for contexts or audiences that prefer plain, utilitarian visuals.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 7B: Omitted Opportunities
warningtoo-many-color-encodings
What it is
A single dashboard carries multiple independent color schemes at once — several legends, conflicting red-green scales, categorical hues layered on top of sequential ones — so the viewer has to keep track of what color means in each view and quickly loses the thread. More color schemes mean more cognitive load and more chances to misread.
How to spot it
In code and charts, flag dashboards with multiple distinct color legends/encodings — two or more sequential scales, a categorical scheme plus a diverging one, the same red-green applied to different measures, color piled onto views that don't need it. Be suspicious when stakeholders have asked for "everything in one view," when no single variable is clearly the focus of color, and when removing a color encoding would lose no information.
Pitfall
A sales dashboard uses two separate red-green profit scales with different extremes, then red and green again for two regions in a scatterplot, and a blue bar chart whose blue matches a third region — several color systems competing in one view, none clearly primary.
Done well
The dashboard is limited to a single color encoding, assigned to the one variable most tied to the user's primary task (e.g. Region for a regional sales review); other measures are shown without color or moved to a separate view, so color carries one clear meaning.
How to fix it
Aim for one color encoding per dashboard, given to the variable most central to the user's task. Drop or relocate competing schemes, show secondary measures without color (or in a separate view), and resist cramming every possible measure into one over-colored view.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 7A: Confusing Colors
warningunclear-interaction-affordances
What it is
An interactive visualization doesn't make it discoverable what actions are possible or understandable what the controls and marks mean, and its controls aren't naturally mapped to the views they affect. Users can't tell what they can do or how, so the interactivity goes unused or is used wrongly — like a stovetop whose knobs don't line up with its burners.
How to spot it
In code and UI, flag interactive dashboards where filters/controls (dropdowns, sliders, legends, buttons) are placed far from or in a different spatial arrangement than the views they control, where it isn't visually obvious a mark is clickable/filterable, or where controls lack clear signifiers/labels. Be suspicious of default control placement (all on the right) when multiple views need different controls, and of interactions a first-time user couldn't discover unaided.
Pitfall
A four-panel dashboard puts all its filters in a single column on the right, so it's unclear which filter drives which panel — a user changes a control expecting panel A to update, but panel C changes instead, mirroring a stovetop with knobs in a row over a 2x2 burner grid.
Done well
Controls are mapped to the views they affect — mounted on or beside each panel, or arranged in the same spatial layout as the panels — with clear labels and signifiers, so it's obvious what each control does and how to use it.
How to fix it
Make interactivity discoverable and understandable: place each control on or adjacent to the view it affects (or mirror the views' spatial layout), label controls clearly, and signal which marks are interactive. Invest the effort to make complex interactions obvious.
Avoiding Data Pitfalls (Wiley, 2020), Pitfall 7C: Usability Uh-Ohs
Data Pitfalls