A chart that is technically excellent and aimed at the wrong audience accomplishes nothing. The most common failure in data communication is not a badly drawn chart; it is a well-drawn chart built for the person who made it.

This article is about the step before design: working out who will read this, what they need to decide, and what form that answer should take. Sometimes the answer is not a chart at all.

When someone asks for a chart, they rarely describe what they need. They describe a chart they imagine. "Can you show revenue by region as a bar chart" is a solution, not a requirement, and it is usually not the best solution.

Ask what decision the chart supports and what they would do differently depending on what it shows. The answers reshape the request. "Show revenue by region" might really mean "I need to know whether to move headcount to the underperforming region," which requires the trend and a comparison against target, not a snapshot of current totals.

This is not pedantry. Building the requested chart instead of the needed one produces a cycle of revisions where each version is fine and none of them answer the question.

Most audiences fall into one of three modes, and the same underlying data serves them very differently.

The analyst is exploring. They want density, detail, and the ability to slice. They benefit from interactivity, multiple series, access to raw values, and the option to export. They are comfortable with a chart that requires study. For them, more information is better, and a filtered exploration view is the right deliverable.

The decision-maker is deciding. They have limited time and are looking for a signal and a recommendation. They need the headline, a comparison that makes it judgeable, and enough context to trust it. Density works against you here. One chart with a clear message beats six charts covering all angles, and a chart with an explicit annotation stating the conclusion beats a chart that leaves the conclusion to be inferred.

The general audience is learning. They may not read charts fluently, and they have not seen this data before. They need simpler chart types, generous labelling, no jargon, and an explicit statement of the takeaway. Assume no familiarity with your metrics and define them.

The mistake is building one artefact for all three. An exploration tool shown to an executive reads as unfinished. An executive summary handed to an analyst reads as withholding.

This distinction is worth making explicit because it drives almost every design decision.

An exploration visualization is a tool. Its job is to let someone ask questions you did not anticipate. It should be flexible, comprehensive, and neutral, presenting the data without steering. Filters, drill-down, and access to detail are features.

An explanation visualization is an argument. Its job is to communicate one specific finding. It should be focused, annotated, and deliberately opinionated, guiding the reader to a conclusion you have already reached. Removing options is a feature.

Both are valid. Confusing them is not. Most requests for a dashboard are actually requests for an explanation, and most delivered dashboards are explorations, which is why so many go unused. People do not want a tool; they want an answer.

Analysts tend to present the way they worked: here is the data, here is the method, here is what I found. Audiences need the reverse: here is what I found, here is the evidence, here is the method if you want it.

In practice this means the conclusion goes in the title. A chart titled "Revenue by Channel" makes the reader do the work. A chart titled "Paid search now drives more revenue than all other channels combined" delivers the finding and lets the chart serve as evidence. The second title is not less rigorous; it is the same rigour, stated.

This feels presumptuous to people trained to let data speak for itself. But data does not speak for itself. If you do not state the conclusion, each reader invents one, and yours was better informed.

Decision-makers want certainty and data rarely provides it. The temptation is to present a single line and omit the caveats, because caveats invite doubt.

That trade is bad in the long run. A confident chart that turns out to be wrong costs far more credibility than a hedged one that turns out to be right.

The honest approach is to make uncertainty visual rather than textual. A forecast drawn as a range rather than a line communicates uncertainty without undermining the message. A sample size shown on the chart lets the reader calibrate. A distinction between actual and projected periods, marked with a dashed line, prevents a projection from being quoted as a measurement.

Where uncertainty is too large to support the decision, say so directly. "This data cannot answer that question" is a valid and valuable finding, and far better than a chart that implies an answer it cannot support.

Not every question needs a chart. Choosing the wrong format is a common and easily avoided waste.

Use a sentence when the answer is a single fact. "Churn was 3.1 percent last month, up from 2.8 percent" needs no chart, and drawing one adds ceremony without information.

Use a table when people need to look up precise values, when there are many dimensions and no dominant pattern, or when the values will be copied elsewhere. Tables are underrated; they are the right answer more often than dashboards suggest.

Use a chart when the message is a pattern: a trend, a comparison, a distribution, a relationship, an outlier. Patterns are what visual encoding is for, and a chart will beat a table every time the answer is a shape rather than a number.

Use a combination when both matter: the chart carries the pattern, an adjacent table carries the exact figures. This is often the most useful deliverable and is skipped because it feels like indecision.

Every good visualization triggers questions. Anticipating the obvious ones is what separates a presentation that lands from one that stalls.

If you show a decline, someone will ask when it started and whether it is still ongoing. If you show a regional comparison, someone will ask about the largest region's composition. If you show an improvement, someone will ask whether it is seasonal.

You do not need to put these answers in the main chart. You need to have them ready. A single well-chosen backup view answers most follow-ups, and having it available converts a meeting that ends in "come back with more detail" into one that ends in a decision.

The measure of a visualization is not whether it was praised; it is whether a decision changed. Follow up. Ask what was decided and whether the chart helped. Ask what was missing.

That feedback is the only reliable signal about whether you are building explanations or just producing charts, and it is the fastest way to get better at the part of this work that no amount of design skill can substitute for: knowing what the person in front of you actually needs.