Data Visualization

Data visualization maps data values to visible marks such as bars, points, lines, shapes, and color. The chart is not decoration added after analysis. It is an interface between data and a question.

A useful visualization helps you compare values, find a pattern, or communicate a result. It can also mislead you when the chart type, scale, aggregation, or labels hide what the data actually say.

The central habit is simple: start with the comparison the reader needs to make. Then choose the clearest visual form for that comparison.

Why visualization exists

A table preserves exact values. A chart exposes relationships among those values. Position, length, direction, and grouping let you notice patterns that are slow to find row by row.

Visualization supports two different jobs:

• Exploration helps you inspect data, test questions, and discover patterns.
• Communication helps you guide an audience toward a finding they need to understand.

An exploratory chart can be dense, provisional, and built for one analyst. A communicative chart needs a clear purpose, enough context, and an honest path from evidence to conclusion. The same dataset may need different charts for those jobs.

Start with a question and a comparison

Do not begin with a chart gallery. Write the question first. Identify the audience, the decision, and the comparison that would answer the question.

Common relationships include:

• Magnitude: How large is each value?
• Ranking: Which values are highest or lowest?
• Change over time: How does a measure move across time?
• Distribution: Where do observations cluster, and how much do they vary?
• Relationship: How do two quantitative variables move together?
• Part to whole: How much does each component contribute to a total?
• Deviation: How far is each value from a target or reference?
• Geography: How does a measure vary by location?

One dataset can support several relationships. Choose the one that serves the question. If you need two comparisons, two simple charts often work better than one overloaded chart.

The grammar of a chart

Most charts combine five parts:

1. Data contains observations and fields.
2. Transformations filter, aggregate, calculate, bin, or reshape those observations.
3. Marks are visible objects such as bars, points, and lines.
4. Encoding channels map fields to position, length, color, size, shape, or another visual property.
5. Scales and guides translate data values into visual values and explain the translation through axes or legends.

For example, a scatter plot uses one point mark per observation. It maps one quantitative field to horizontal position and another to vertical position. A color channel may identify a category. The axes reveal the position scales, while a legend explains the color scale.

This model separates meaning from appearance. A blue point means nothing until you know which field and scale produced blue.

Match the chart to the relationship

Use a bar chart for comparisons among discrete categories. A shared zero baseline makes bar lengths comparable. Sort bars when rank matters. Keep a meaningful order when categories already have one.

Use a line chart for change across continuous time. The line connects observations and suggests continuity between them, so do not use it for unrelated categories.

Use a scatter plot for the relationship between two quantitative variables. Each point represents an observation. A pattern can show association, clusters, gaps, or unusual observations. It does not prove that one variable causes the other.

Use a histogram to show a distribution. Bins divide a continuous field into intervals, and bar height shows the count or proportion in each interval. Changing bin width can change the visible pattern, so inspect more than one defensible choice.

Use a box plot when you need a compact comparison of distributions. It summarizes location and spread but hides the distribution's detailed shape. Pair it with points or another distribution view when that shape matters.

Use a stacked bar chart when the total and broad composition matter more than precise comparison among every segment. Only the segments sharing a baseline are easy to compare.

Use a map only when spatial pattern is part of the question. In a choropleth map, color encodes a value for each area. Counts often reflect area population or size, so rates or normalized measures are usually the relevant comparison when exposure differs.

Preserve the meaning of the data

Before drawing, confirm what one row represents. Check units, time periods, missing values, category definitions, and the denominator behind every rate.

Aggregation changes the question. A monthly mean is not a daily distribution. A national total can hide regional differences. A chart can calculate correctly and still answer the wrong question.

Treat missing data as unknown unless the domain gives you a justified replacement rule. Turning missing values into zero invents observations. Connecting across gaps in a line can imply continuity that the source does not establish.

Show uncertainty when it could change the interpretation. Confidence or prediction intervals can prevent readers from treating estimates as exact. State what an interval represents, because different intervals answer different questions.

Use scales honestly

A scale maps a data domain to a visual range. The domain contains source values. The range contains positions, lengths, colors, or sizes on the chart.

Bar length is measured from a baseline, so a bar chart should start at zero. Cutting the axis exaggerates small differences in length. A line chart does not encode value through filled length, so a nonzero baseline can be defensible when it is clearly labeled and needed to show variation.

Use the same scale across small multiples when you want direct comparison. Different scales can make unequal patterns look similar.

Linear scales are the default for additive differences. A logarithmic scale can make multiplicative change easier to compare across a wide range. It also demands explicit labeling and an audience that can interpret it. Never use a log scale to rescue a chart without explaining what distance means.

Write the chart, not just the picture

A chart needs enough text to stand on its own:

• a title that states the finding or question;
• a subtitle with measure, population, place, and time when needed;
• clear axis labels and units;
• direct labels or a compact legend;
• annotations for relevant events or thresholds;
• the data source and necessary notes.

Use annotations to add context, not to repeat every value. Put the annotation close to the evidence it explains.

Remove visual elements that do not support reading. Decoration, heavy borders, redundant legends, dense gridlines, and unnecessary three-dimensional effects compete with the data.

Design for access

Do not use color as the only way to distinguish information. Add labels, shapes, line styles, or position. Check contrast between meaningful graphical objects and adjacent colors.

Give a complex chart a short text alternative that identifies it and a longer description that conveys its essential information. Provide the underlying data as a table or download when practical. Interactive charts also need keyboard operation, visible focus, and instructions that do not depend on hover.

Accessibility improves the analytical design. A chart that still works without color alone usually has clearer grouping and labeling for everyone.

Know the limits

A chart shows only the fields, records, transformations, and ranges you include. It does not repair poor data quality. It does not establish causation. It cannot tell the reader which definitions were omitted.

Interactivity can help a reader filter or inspect details, but it adds state and testing work. Start with a useful default view. Do not hide the main finding behind a required click or hover.

A dashboard is useful for monitoring a set of recurring indicators. It is less useful when the audience needs a specific explanation. More charts do not create more insight.

A repeatable workflow

Use this sequence for most visualization work:

1. State the audience, question, and intended comparison.
2. Audit grain, field types, units, missingness, and definitions.
3. Transform only what the question requires.
4. Sketch more than one chart type.
5. Choose marks and encodings that make the comparison direct.
6. Set honest scales, labels, ordering, and color.
7. Add context, source notes, uncertainty, and accessible alternatives.
8. Test with someone who did not build the chart.
9. Check the rendered chart across its real display sizes.
10. Preserve the data and transformation steps so the result can be reproduced.

Tools change, but this reasoning transfers. Once you can explain the data, mark, encoding, scale, and comparison, you can evaluate a chart in a spreadsheet, a business intelligence tool, a programming library, or a declarative grammar.