Data visualization design: the judgment calls behind every chart

On the Medi-Cal work for the California Department of Health Care Services, we built three visualizations from one dataset: a choropleth map for county-level distribution, a bubble plot for ethnicity and language, and a Sankey diagram for how age groups moved across time. The data never changed. Data visualization design is the work of choosing which representation an audience needs, and four decisions carry it: chart type, scale, color encoding, and omission.

What data visualization design covers

Data visualization design covers every choice standing between a dataset and the person reading it: which relationship the visual argues for, what form carries that relationship, how scale and color encode value, what context a reader needs to interpret it correctly, and what belongs in a table rather than a chart. It draws on data modeling, visual communication, interaction design, and accessibility.

In most organizations, the shortage is not data. It is a decision about which relationships inside that data deserve a reader’s attention, and that decision doesn’t arrive with the export. Someone has to make it. If a designer does not, the reporting tool’s default chart makes it instead, and nobody revisits the choice because the screen looks finished.

Digital.gov’s introduction to data visualization does not reach the chart until step four of seven. The research question comes first, then data sourcing, then cleaning and exploration, and a bias review and an accessibility review follow once the visual exists. Three decisions constrain the chart before anyone picks a form, and two more can send it back.

Chart type: the decision that constrains everyone after it

Hand the same quarterly dataset to two analysts, and one reaches for a bar chart while the other reaches for a line graph. Neither is wrong. The bar chart argues that these categories differ from each other, and the line chart argues that something is moving. Both readings use the same numbers, and only one matches the question the reader arrived with.

Nielsen Norman Group’s guidance on choosing chart types rests on two variables: the type of data and the comparison the reader is meant to make. People often skip the second variable. A chart type chosen from what the data permits can produce a technically valid graphic that answers a question nobody asked. In other words, it may be harder for some audiences to interpret.

That same guidance lists Sankey diagrams among the forms to avoid, because they ask a reader to judge angle and area rather than length. The reservation holds for most explanatory charts. It does not hold when the relationship is movement between categories across time, which no bar or line can adequately display. Knowing which case is in front of you is the kind of judgment that relies on the user’s knowledge, and no guidance can make it for you.

The difficulty arrives when one dataset holds several relationships at once. Totals, change over time, geographic concentration, and segmentation can all be plotted, and a single view can carry all four. Giving them equal visual weight is where the failure is rooted. The reader gets a complete picture, with no instruction on which part to read first.

A practical test is to write the question and the visual answers in one sentence before choosing a form. If that sentence needs an “and,” the view is probably carrying two arguments, and there should be two views if you are doing your best on behalf of all users. If different people write different sentences after looking at the finished screen, you chose the form before you chose the question.

Scale, and where accurate data starts misleading

Scale decides how far apart two values look, which is not the same as how far apart they are. A truncated axis, a compressed interval, or a logarithmic transformation can make a three-point difference look like a collapse or a rounding error. A misleading data visualization usually works this way: every plotted number is correct, and the emphasis was manufactured rather than found.

A bar chart whose axis starts at ninety rather than zero is common, and it is common precisely because the truncated one looks more informative. The differences become visible. The reader has no way to tell whether those differences came from the data or from a decision about where to start counting.

USWDS guidance recommends that line chart origins start at zero unless the departure is clearly noted. That puts the burden on the designer to declare the choice rather than on the reader to detect it, which is where it belongs. Unless your designer is a novice, then you’ve got a whole other problem to deal with!

Logarithmic scales run the other way and hide magnitude from anyone who doesn’t read the axis labels closely. They suit datasets spanning several orders of magnitude where the shape of growth matters more than its size. They are a poor fit on a public-facing screen, where most readers will read plotted distance literally unless the axis is labeled prominently.

Color encodes a variable, whether or not you meant it to

Color in a visualization is a data channel, not a finish. A sequential ramp tells a reader the values have an order, a diverging scheme tells them a meaningful midpoint exists, and a categorical palette tells them the groups are unrelated. Applying a sequential ramp to unordered categories asserts an order the dataset does not contain.

The U.S. Web Design System data visualization guidance is direct about the failure that follows: do not reuse colors across different variables, or across different values within one variable. Readers assume color stays consistent within a screen. When the same blue means “approved” in one panel and “West region” in another, they infer a relationship nobody built.

A useful check is to render the view in grayscale. If it still communicates, color is decorative and can be reduced. If it collapses, color is carrying essential information. That information then needs a second channel too: a label, a shape, a pattern, or a text summary for anyone who cannot separate the hues. No one talks much about the fact that 5% of people are color blind, which is not a huge number, but it’s worth keeping in mind.

What gets left out

The hardest review conversation on a visualization project is rarely about what to add. Every reviewer has a dimension they want on the screen; every dimension is defensible on its own, and the aggregate view answers everything and directs no one.

Elimination carries the same design weight as inclusion. Which values are essential to the question, which context a reader needs to interpret them, and which detail belongs one interaction deeper are three separate calls. Answering them well looks more like editorial judgment than layout. The work is deciding what earns attention.

Detail removed from a chart does not have to leave the product. A filter, a drill-down, an appended table, or a plain-text summary all keep it reachable without forcing it into the primary view. Most of our data visualization work spends more time on that tiering than on the charts themselves.

What a wrong representation costs

The cost of a wrong representation is not aesthetic. When a form obscures the relationship a reader came for, the pattern is still in the data and the screen is still accurate. The person looking at it walks away with no conclusion, or with the opposite one. These two versions account for most of what shows up in review.

Choropleth maps are the clearest case. Readers judge area before they judge hue, and a choropleth encodes its value in hue, so region size competes with the encoding and usually wins. A sparsely populated county covering a large area dominates a screen it should barely register on, while a dense urban county carrying most of the actual volume shrinks to a few pixels.

Heat maps distort in the other direction. Color intensity implies a smooth gradient, so readers infer gradations between values the underlying numbers cannot support, which gets worse as the sample behind each cell shrinks. Our heat map data visualization guide works through where that breaks and what to use instead.

Both cases share one structure: a visual property the reader processes automatically- area in the first and intensity in the second- is doing work the data never authorized. Catching that before it ships means knowing what a form does to a reader before you choose it, which makes the choice analytical rather than stylistic. Long story short here, it’s always a good idea to rely on data over personal preference.

Where data visualization design ends and dashboard design begins

A visualization is a single view that makes one argument about a relationship in data. A dashboard is a system of views with navigation, filters, and actions built around an ongoing task. The distinction matters because well-designed individual charts routinely assemble into unusable dashboards, and when they do, the failure sits in the layer above the charts.

The practical consequence is that fixing a weak dashboard by improving its charts rarely works. When the layout establishes no reading order and the filters narrow to questions nobody has, better charts produce a better-looking version of the same problem. The fuller comparison of dashboard design and data visualization covers where each discipline owns the decision.

When interaction hides what the reader needs

On the COVID-19 spending tracker we built for the Project on Government Oversight, the design problem was never any single chart. It was that a nationwide picture and a county-level research question had to share one interface. A big lift for any design shop, to say the very least. The eventual map answers the first, filters narrow the dataset, and a table view carries side-by-side comparison and a spreadsheet download for anyone doing the second.

This type of tiering addresses the most common interaction failure: putting information behind a click before a reader knows the click exists. Filters and hover states serve exploration well, but they work against the reader when they withhold something needed to know what is worth exploring.

USWDS puts it plainly: an audience should not be required to interact with a visualization to understand its message. Presuming the ability to hover with a mouse removes part of that audience from the full experience.

Accessible Visualization Requirements: COVID-19 Spending Tracker

An accessible data visualization needs three separate components, not one. A tabular representation gives a screen reader user access to the underlying values. A text description states what the chart is showing. A plain-language summary of the pattern carries the narrative the visual was built to deliver. A hidden table supplies the first of those and none of the rest.

USWDS separates those two obligations. It asks for a tabular representation of the data, and separately for the information the visualization communicates, meaning trends and statistical summaries, in plain text. It also notes that a hidden table stops being a sufficient alternative once the dataset grows complex.

The test that catches most of this is whether a reader can reach the important conclusion without depending on the exact visual channel the design was built around. If the answer is no, the visualization has one route in, and a meaningful share of its audience can’t access that route.

Whether any of this is a legal obligation or a design preference depends on who is buying. Federal agencies fall under Section 508 directly, and states adopt equivalent standards through their own statutes. For state and local entities, the Department of Justice has set WCAG 2.1 Level AA under ADA Title II. Compliance is due in April 2027 for populations of 50,000 or more, and April 2028 for everyone else.

Anything designed for a public entity now is being designed into that deadline, which moves the accessible equivalent from a remediation ticket to a scope item at kickoff.

What changes when a system picks the chart

Generated visualizations move the decision rather than removing it. Chart type, scale, and color encoding still get chosen. A default inside the tool chooses them at speed, with nobody present to notice it was wrong for this question.

The second shift is less obvious and more interesting. A generated view can respond to the question being asked, surfacing different relationships, contexts, or levels of detail for different readers of the same dataset. That makes the design object a set of rules about how a visualization should behave rather than a fixed screen.

Both directions raise the value of the judgment rather than lowering it. Deciding what a system should render, under which conditions, and what it should refuse to render is the same set of calls described above. They are made once and applied at volume rather than made per screen.

What to settle before the first chart

Everything above reduces to a process: a sequence, not a checklist. Name the relationship a reader needs, choose the form that carries it, set scale and color so they encode rather than decorate, and decide what leaves the primary view without leaving the product. A team that can produce that sequence for a given screen can defend the screen. A team that starts with the chart type cannot.