Data Visualization

When numbers only came as tables, the whole burden of reading them landed on whoever was looking. Twelve months of signups laid out cell by cell meant subtracting one cell from the next in your head, over and over, just to find the month where the trend broke. Past about twenty numbers most people gave up halfway and read only the last value.

Pagedeck's weekly review looked like that for a while. Mia would put fifteen metrics on screen as a table, about thirty seconds of silence would follow, and then someone would ask how it compared to last week. The answer was already in the table and nobody could find it. The silence wasn't caused by missing information — it was caused by a shape that didn't match how eyes work.

Data visualization moves that burden from the reader to the maker. Draw the same twelve months as a line and the break shows up first. It works because people are slow at comparing numbers and fast at comparing lengths and positions. Once the shift happens, meeting time moves from locating the value to deciding what to do about it.

Decide what you're saying before picking a shape. There are five steps.

1. Write the question this chart answers in one sentence. "Signup status" isn't a question; "when did signups turn" is. Without that sentence you end up loading every value onto the screen and asking the reader to go find the point themselves.
2. Work out what kind of comparison the question is. Change over time, sizes weighed against each other, share of a whole, or how values are spread out. What you land on here nearly determines the next step.
3. Pick the shape. Lines for change over time, bars for comparing items, a circle for share of a whole. Once a pie has more than four slices, nobody can tell by eye which one is bigger, so that's the point to switch to bars.
4. Set the axis and the colors. Vertical axes start at zero by default — start one at 9,800 and a one percent move looks like a cliff. Keep a single screen under five colors, and fix what each one means, with revenue always blue and errors always red. When the same color means different things on different screens, readers re-read the legend every time.
5. Check that it reads. Put the conclusion in the title, then show the screen to someone seeing it for the first time for five seconds and ask what they noticed. The person who made it already knows the answer and can't judge whether their own chart lands. Five seconds is the realistic budget, since that is roughly how long anyone spends on a screen during a meeting.

A chart doesn't stand on its own. After finding the month things turned, the reader needs to get to why, so build a path to break that value apart by channel or plan through drill-down at the same time.

It works best when there are several values and the relationship between them is the point: twelve months of movement, eight channels of different sizes, retention curves separating by plan. Comparison is what gives these their meaning; strip it away and the shape has nothing left to carry.

When there are only one or two values, a chart gets in the way. There's no reason to draw this month's revenue as a single bar — writing the number large is faster. The same goes for anywhere exact values matter. In a billing review where 3,418 and 3,420 have to be told apart, a table is correct, and a chart will render those two bars at what looks like the same height.

The biggest weakness of the method is that the same values can produce different impressions. Cut the axis and a small move looks large. Use a stacked bar and the total is visible while the movement in each segment is hidden. That doesn't make the values wrong, but it takes the reader to a wrong conclusion, which amounts to the same thing. Writing one line beside the metric name explaining what the chart shows is the cheap protection.

There are limits to the range of the method, too. A chart shows what changed, never why. And it does nothing at all while nobody is looking at it, so values you can't afford to miss — a payment failure rate, for instance — should reach people through anomaly detection first.

"This chart's axis starts at 9,800 so the drop looks bigger than it is. Can you redraw it from zero?"

The axis setting is exaggerating how far the value moved.

"Seven categories doesn't read as a pie. Let's switch to bars."

Too many slices to compare by eye, so change the shape.

"I can't tell what I'm supposed to decide from this screen. Put the conclusion in the title."

The values are present, but what to do with them isn't coming across.

At Pagedeck, Noa once reworked a retention screen Mia had built. The first version had retention for five plans as five overlapping lines in similar colors, so telling them apart meant consulting the legend. What Noa changed wasn't the chart type but how many things were competing for attention. Keeping the enterprise plan — the one needing a decision that quarter — as a dark line and dropping the other four to gray produced a screen drawn from identical values where the first question in the meeting was different. That is visual hierarchy at work.

The most common misreading is that visualization means making a screen look nice. The output is something you can see, and it sometimes gets made in design tools, which makes the assumption easy. In practice nearly every judgment in this work is structural rather than aesthetic: which comparison to show, where the axis starts, what to leave out. Miss that and hours go into colors and drop shadows while the question of which values the screen actually compares never gets settled.

The second is expecting the chart to hand over a conclusion. The break in the line jumps out, so it feels like an answer arrived. But a line turning down states what happened and says nothing about why. Stop there and the meeting ends at "signups are down," and the next step — splitting that line apart to see which channel drained — never gets taken. A chart earns its place by starting that second conversation, not by closing the first one.