Data Visualization Techniques

01Purpose and scope

• This manual supports the course Data Visualization Techniques. It is a reference for analysts, researchers, program staff, and other professionals who turn tables of figures into charts, dashboards, and briefing graphics that other people will read and act on.
• The manual covers how to pick a chart type for a specific question, encode values so they can be read accurately, lay out and label a graphic, choose color and text that others can perceive, review a draft before release, and check whether the finished visual actually helps readers. It does not cover statistical modeling, database design, or the full craft of presentation storytelling, although those topics touch the work at several points.
• Practice changes with context. An exploratory chart that only you will see can be rough and fast. A chart in a published report, a grant application, a board packet, or a patient or customer communication needs more care with labels, sources, uncertainty, and privacy. The same technique can be right in one setting and too risky or too dense in another.

02Core principles

• The chart should answer one question at a time. A bar chart comparing five regional totals answers a comparison question. A line chart of the same totals over twelve periods answers a trend question. Mixing both into one graphic usually forces the reader to guess what the designer wanted them to see.
• Encodings should match the data. Position along a common scale is the most accurate way for people to compare quantities, so bars and dots aligned to a shared baseline usually beat areas, angles, and volumes. Use length for totals, slope for change over time, and position for distributions. Use size or color intensity only as secondary cues because readers judge them less precisely.
• Scales must be honest. Bar charts should start at zero because bar length is read as a quantity. Line charts can use a non-zero baseline when the question is about change, but the axis must be labeled clearly. Sorting categories by value, rather than alphabetically, usually makes comparisons faster, unless the category order carries meaning such as age bands or months.
• Clutter has a cost. Every gridline, border, legend entry, and decorative element competes with the data. Remove what does not help the reader decide, and label values directly where that is practical. Direct labels are easier to read than a legend that requires eye travel back and forth.
• Uncertainty and missing data belong in the graphic. If a value is estimated, sampled, revised, or incomplete, show that with intervals, hatching, a footnote, or a separate marker. A clean line that hides a gap in the source is a misleading line even if every plotted point is correct.

03Planning and preparation

• Start by writing down the decision or question the visual should support. Ask the requester what they will do differently after seeing it. If the answer is vague, the chart will likely be vague too. Record the intended audience, the setting where the graphic will appear, and whether it will be printed, projected, embedded in a dashboard, or read on a phone.
• Confirm the data before drawing anything. Identify the source table, the grain of each row, the time range, the units, the denominator for any rate or percentage, and how missing values were handled upstream. Many visualization errors come from mismatched grain, such as plotting patient visits when the question is about patients, or plotting totals when the question is about per-capita rates.
• Identify stakeholders and their roles. The requester defines the question. The data owner confirms definitions and access. A reviewer checks accuracy and clarity. The audience defines what must be understood at a glance. In many organizations, a privacy or compliance contact must also approve any output containing individual-level or small-group information.
• Choose tools based on the deliverable. Spreadsheet software is adequate for simple bar, line, and pie charts in a single report. Code-based plotting libraries such as matplotlib in Python or ggplot2 in R give repeatable output and better control over labels and layout. Business intelligence dashboards suit recurring reports with filters, but they make default settings matter more, because many readers will never change them. Whichever tool you use, decide early which file format and resolution the final product needs.
• Prepare a short chart specification before building. Note the chart type, the x and y variables, the sort order, the axis range, the color rule, the title that states the finding, and the source line. This specification becomes the basis for review and for future updates.

04Recommended workflow

1. 1
   : Restate the question in one sentence and confirm it with the requester. Write the finding you expect the chart to show, then check whether the data can support it. If it cannot, return to the requester before building anything.
2. 2
   : Profile the data. Check row counts, duplicates, missing values, outliers, and category labels with inconsistent spelling. Compare summary totals with a trusted figure from another source. Record every cleaning step so it can be reproduced.
3. 3
   : Select the chart type. Match the question to a form: comparison among categories suggests bars, change over an ordered sequence suggests lines, relationship between two continuous variables suggests a scatter plot, and parts of a whole with few categories may suit a stacked bar or a simple table. Avoid pie charts when there are more than four or five slices or when the slices are close in size.
4. 4
   : Build a rough version without styling. Plot the raw encodings first. Verify that the rough chart shows the same pattern you saw in the summary numbers. Many errors appear here, such as a date field read as text or a category order that hides the trend.
5. 5
   : Apply design decisions. Set the axis range and baseline, sort categories, remove unnecessary gridlines and borders, label units, and place direct labels. Choose a palette with enough contrast and with a limited number of hues. Use one accent color to highlight the finding rather than coloring every series differently.
6. 6
   : Write the title, subtitle, annotations, and source line. The title should state the main finding in plain words, such as Enrollment in the north campus grew faster than in the south campus over three semesters, rather than a generic label like Enrollment by Campus. Include the time range, units, data version, and any exclusions in the source line.
7. 7
   : Test the final graphic. View it at the size and in the medium where it will be used. Print it in grayscale if it may be printed. Check it with a color vision simulation tool, and confirm that a reader who is unfamiliar with the project can state the main point within a short time. Hand off the specification, the cleaned data, and the code or steps used to build it.

05Quality checks, risk controls and compliance

• Accuracy checks should happen before any reviewer sees the graphic. Recompute at least one headline figure from the source independently. Confirm that bars sum to the stated total, that percentages add to the expected base, and that the axis maximum does not clip the largest value. Check that a dashboard filter does not silently exclude a category that the static version includes.
• Accessibility is part of quality. Text should meet the contrast guidance in the Web Content Accessibility Guidelines, which is a widely used standard for digital content, and readers should not need color perception to decode the chart. Pair color with shape, pattern, or direct labels. Provide alternative text or a data table for online graphics, and avoid tiny fonts in exported images. Where your organization must meet a specific legal accessibility requirement, the applicable rule depends on jurisdiction and sector, so confirm it with your accessibility office or the current authoritative source.
• Privacy and disclosure controls matter whenever the data describe people or small groups. Small cell counts can allow re-identification even when names are removed. Common controls include suppressing cells below a threshold, aggregating categories, rounding values, and reviewing filter combinations that could isolate one person. The thresholds and legal obligations depend on jurisdiction, data type, and agreements with data providers, so check the current policy and the authoritative regulation that applies to your data.
• Regulated and high-risk fields need extra caution. Charts used for clinical decisions, legal evidence, financial reporting, tax filings, or safety communications carry consequences beyond a poor design. This manual does not replace qualified professional judgment, approved procedures, or required authorization. In those settings, the chart must follow the controlled template, the validation steps, and the sign-off chain defined by the responsible function.
• Version control and reproducibility are basic controls. Keep the source extract, the cleaning script or steps, the chart code, and the final image or dashboard version together. When a number changes in a later release, you should be able to explain why the chart changed.

06Collaboration and documentation

• Visualization work is rarely solitary. The requester, data owner, designer, reviewer, and audience each see different risks. Schedule a short review once a draft exists and another after major revisions. Ask reviewers to state in their own words what the chart shows before they comment on its appearance. Their summary reveals whether the title and encoding are doing their job.
• Document definitions in a short data note attached to the graphic. The note should give the metric definition, the calculation, the population included, the exclusions, the source system, the refresh timing, and the known limitations. A reader who finds the chart later should not need to contact the author to interpret it.
• Keep a change log for recurring outputs. Record what changed, who approved it, and why. When a dashboard is updated, note any changes to axis ranges, category groupings, or default filters, since readers often compare the new chart with old screenshots.
• Handoffs need clear ownership. Name the person who maintains the template, the person who refreshes the data, and the person who answers questions from readers. Shared drives and folders with generic names create confusion, so use consistent file names that include the subject, the data version, and the owner.

07Measures and continuous improvement

• Useful indicators include the number of revision rounds before approval, the number of reviewer misreadings captured in review, the share of charts that pass an accessibility check on first review, the number of corrections issued after release, and the time from request to approved output. Track these over several projects rather than reading too much into one result.
• Usage metrics such as page views or downloads show exposure, not comprehension. A dashboard that receives many visits may still be misread. Where the decision matters, run a short comprehension check with two or three readers who represent the audience. Ask them to state the main finding and any number they would quote. Record where they hesitate, because those points usually indicate a labeling or scale problem.
• Improve the process with a simple retrospective after each significant graphic. Note which steps caused rework, which tools slowed the team, and which design choices readers found confusing. Update the specification template and the review checklist when a pattern repeats.
• Recognize the limits of measurement. Some valuable charts serve exploration, where the goal is to surprise the analyst rather than to inform a stable audience. Their success is harder to measure and should be judged by whether they lead to a better question or a verified finding.

08Common mistakes and how to prevent them

• Truncated bar axes exaggerate differences. Prevent this by starting bar charts at zero and reviewing any non-zero baseline on line charts against the question being asked.
• Dual axes with different scales can make unrelated series appear to move together. Prevent this by using separate small panels with shared time ranges, or by indexing both series to a common base value and stating the method in the note.
• Pie charts with many slices or near-equal shares are hard to read. Prevent this by switching to sorted bars, which allow precise comparison.
• Rainbow palettes and similar sequential schemes can distort the perceived order of values and fail for readers with color vision differences. Prevent this by choosing a palette designed for the data type, limiting the number of hues, and checking the result in grayscale.
• Three-dimensional effects, shadows, and heavy gradients distort lengths and angles. Prevent this by using flat styling and reserving emphasis for the finding.
• Unlabeled units, missing denominators, and vague titles leave readers to guess. Prevent this by adding units to the axis, the denominator to rate labels, and a finding-based title.
• Interactive filters can hide defaults that change the meaning of a chart. Prevent this by setting a sensible default view, documenting it, and testing the most common filter combinations before release.

09Practical checklist

• Write the question and the decision the chart should support before building it.
• Confirm the grain, time range, units, and denominator of the source data.
• Profile the data for duplicates, missing values, outliers, and inconsistent labels.
• Choose a chart type that matches the comparison, trend, relationship, or composition being shown.
• Start bars at zero and label any non-zero baseline on other chart types.
• Sort categories by value unless the category order carries meaning.
• Label values and units directly where practical, and remove unneeded gridlines and borders.
• Use one accent color for the finding and limit the total number of hues.
• Confirm contrast meets the accessibility guidance and that color is not the only cue.
• Check small counts and filter combinations for privacy risk under the applicable policy.
• Write a title that states the finding, plus a source line with the data version and exclusions.
• Recompute at least one headline figure independently from the source.
• Review the graphic at final size and in grayscale if it may be printed.
• Attach a data note with definitions, calculations, and limitations.
• Store the source extract, cleaning steps, chart code, and final version together.
• Confirm that a reviewer who did not build the chart can state the main point correctly.

★Learning sources

• Micro Degree: Data Visualization Techniques
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics