Pictures That Show Data

Why Most Data Visualization Fails Before It Starts

I've spent years watching people present charts that look fine in isolation but collapse the moment anyone asks a follow-up question. The problem usually isn't the software. It's that they picked a visualization type before they understood what question the picture needed to answer. I saw this happen last month with a team that had 40,000 rows of server latency logs. They immediately jumped to a scatter plot because they wanted it to look good in a slide deck. The scatter plot was unreadable at that scale. I had them switch to a hexbin heatmap and a simple percentile table instead, and the actual insight they were looking for showed up in about ten minutes. The scatter plot would have taken another two hours of tweaking. Before you open any tool, write down one sentence: what decision will someone make after looking at this picture? If you can't answer that, you don't have a visualization problem, you have a thinking problem. I learned this the hard way on a project where I spent three days building an interactive dashboard that nobody used. The stakeholders had already made their decision internally. The dashboard was just theater. Once I started asking "who is the audience" and "what do they need to do differently after seeing this," the work got shorter and more useful. The core workflow is simpler than most tutorials make it. You take raw data, you choose a visual encoding that matches the relationship you're trying to show, you apply that encoding, and then you check whether the picture distorts or preserves the underlying numbers. The encoding step is where most people go wrong. Bar lengths are easy to read because human vision compares linear distances accurately. Area and volume are harder. A pie chart with six slices is fine for a quick glance. Eight slices and you're asking people to do geometry in their heads.

Tools That Actually Work for This Stuff

For straightforward Pictures That Show Data work, Tableau Public and Flourish are the ones I reach for first. Tableau handles messy data better than almost anything else I've tried. It forces you to deal with data types and relationships before you can plot anything, which catches errors early. Flourish is faster for templates and animating transitions between states. If you're doing code-based work, Plotly and Altair are the most honest about what they're showing you. They don't hide the data pipeline behind magic. For Excel users who just need to get something out quickly, the built-in chart tools are adequate for basic bar, line, and column work. Don't use 3D charts. They distort perception without adding information. Don't use donut charts when a bar chart would do the same job in half the time to read. I've audited enough internal reports to know these habits are everywhere.

Common Pitfalls I See Repeatedly

Axis truncation is the most common manipulation, intentional or not. A y-axis that starts at 48 instead of zero makes a change from 50 to 55 look dramatic. It's not dramatic. It's a ten percent change presented like a crisis. Always check the baseline. If a chart doesn't label its zero point or starts arbitrarily close to the data range, flag it. Multivariate overload is the second mistake. When a single chart tries to show seven dimensions at once using color, size, shape, and position, it stops being a picture and becomes a puzzle nobody wants to solve. I once reviewed a chart with six different colored lines, each representing a different region, overlaid on a dual-axis setup with a secondary metric in the background. It took four people twenty minutes to agree on what the chart was claiming. A pair of small multiples would have answered the question in thirty seconds. A third issue is aggregation hiding distribution. A bar showing the average revenue by product category is not the same thing as understanding whether revenue is concentrated in a few outliers or spread evenly across SKUs. I dealt with a client who couldn't explain why their "average" retention rate dropped when every segment individually improved. The problem was a shift in mix. New low-retention cohorts arrived in volume, dragging the average down even though no individual group performed worse. Pictures That Show Data that only display aggregated metrics will miss this entirely. You need a distribution view alongside the aggregate.

When Visualization Fails Completely

Sometimes the honest answer is that a picture cannot show this data well. High-dimensional data with more than five or six meaningful variables resists clean visualization without significant abstraction. Correlation does not equal causation, and no chart type changes that. You can make a nice-looking network graph, but if the edges are inferred rather than measured, the picture is speculation dressed up as evidence. I've seen teams treat correlation matrices and heatmaps as proof of causal relationships because the colors looked convincing. They weren't. The right move in those cases is to state the limitation in the caption and pair the visualization with a method section that explains what the data can and cannot support. Another hard limit is temporal granularity. When you aggregate daily data into monthly buckets to reduce noise, you lose events that happened within a month. An outbreak, a spike in traffic, a anomaly—gone. If your question depends on timing, don't smooth it away. Use a daily line with a moving average overlay instead of replacing the daily view entirely.

A Practical Workflow That Cuts Rework in Half

Start with a table. Not a chart, a spreadsheet or a plain data view. Sort it, filter it, calculate the summary statistics you actually need. If you can't find the insight in the table, the chart won't create it. Then pick the simplest chart that preserves the pattern you found. Bar for comparison. Line for trend. Scatter for relationship. Hexbin or heatmap for density. Avoid combining more than two of those in a single image unless the audience is trained to read compound charts. Label directly on the visual whenever possible. Legends force the eye to jump back and forth. I prefer annotating the line or bar with the value or the label next to it. It takes slightly more space but reduces reading time and misreads significantly. For a deck of twelve slides, that usually saves the presenter from spending three minutes re-explaining what each color meant. Finally, run a quick sanity check. Pick three data points and verify they land where you expect on the axes. Check the scale direction. Make sure the units are stated. This takes about two minutes and catches more errors than any automated tool I've used.

Where to Get Started

If you want something free to try immediately, go to Tableau Public and import a CSV. Their template gallery has enough examples to learn from, and the public gallery lets you reverse-engineer charts you like. For code-based work, the Altair documentation is one of the few places where the examples actually match the API without hand-waving. The Flourish template library is useful when you need to produce a standard chart type quickly and don't want to build it from scratch. The best resource I found for avoiding the common traps was a short internal guide my team wrote after we stopped caring about making things look impressive and started caring about making them honest. It's not publicly hosted anywhere specific, but the principles are the same: show the numbers, admit the limits, and don't let the picture outrun the data.