5  Communicating Data Analysis

Learning Objectives

By the end of this module you should be able to:

  1. Structure a data analysis report so your audience can follow it.
  2. Use Quarto to create reproducible reports that combine text, code, and output.
  3. Apply principles of good writing to technical communication.
  4. Anticipate your audience’s questions and objections.
  5. Format Excel workbooks for handoff to a non-technical reader.

5.1 Why Communication Matters

Here is a secret: most data analysis never gets used, because nobody understood it. You can spend weeks producing the perfect analysis, and if the final product is a dense PDF that your boss glances at and shelves, you have accomplished nothing. Communication is not a bonus skill on top of the “real” work — it is half the job.

I am going to say some things in this module that might feel obvious. They are obvious, and yet the world is full of reports that violate them. Keep these in mind.

5.2 Sympathy for Your Audience

Every piece of analysis has a reader. Before you write a single sentence, ask yourself:

  • Who is this reader? Their job, their technical background, what they care about.
  • What do they already know? Don’t explain things they know. Do explain things they don’t.
  • What decision are they trying to make? Every report exists to inform some decision. Find it.
  • What will they do with the report? Read it front to back? Skim the executive summary? Search for a specific number?
  • How much time will they spend? Be ruthlessly respectful of it.

Good writers of technical reports develop what I call sympathy for the reader — the ability to imagine what it’s like to read the report with fresh eyes. It is hard, because you have been immersed in the problem for days and they have not. The more effort you put into imagining their experience, the better your report will be.

A practical tip: after you finish a draft, put it away for a day and come back to it. You will read it with fresher eyes and spot places where you assumed too much context.

5.3 Structure of a Data Analysis Report

A standard structure that works for almost any report:

  1. Executive summary (1 paragraph). The answer to the question, stated plainly. If your reader reads nothing else, they should get the punch line. Write this last, after you know what you found.
  2. Question and context (1-2 paragraphs). What question were you asked? Why does it matter? What do we already know?
  3. Data (1-2 paragraphs). What data did you use? Where did it come from? What did you do to clean it? What are its limitations?
  4. Methods (1-2 paragraphs). What did you do, in plain language. You don’t need to list every R function, but the reader should be able to understand conceptually what analysis you performed.
  5. Results (the main body). What you found, with charts and tables. Each chart or table should have a clear title and a short paragraph explaining what it shows. Do not make the reader figure it out themselves.
  6. Discussion (1-2 paragraphs). What do the results mean? What are the caveats? What would you do differently with more time or data?
  7. References and data sources. Every claim should be traceable.

A few guidelines:

  • Keep it short. A 3-page report that gets read is worth ten 30-page reports that don’t.
  • One chart, one point. If you can’t say what a chart shows in one sentence, split it into two charts.
  • Round your numbers. “47.3851%” is unreadable. “47%” is a human number. Round aggressively, unless decimals matter for the specific claim.
  • Flag uncertainty. If your estimate has a wide confidence interval, say so. Don’t hide it in a footnote.

5.4 Quarto: Reproducible Reports

One of the best innovations in data analysis in the last decade is the rise of literate programming tools that combine text, code, and output in a single document. The canonical tools in R are R Markdown and its successor, Quarto.

The idea: write a document where you can interleave prose and code. When you “render” the document, the code runs and its output (tables, charts, numbers) is inserted in place. The result is a report where the analysis and the writing are in the same file — and where the numbers in the text are guaranteed to match what the code produces, because they are generated by the code.

This textbook is written in Quarto. The chart in the Module 1 worked example could be generated by the same code that the students use in the exercise.

A minimal Quarto document looks like this:

---
title: "Canola Yields by Region"
author: "Your Name"
format: html
---

# Introduction

This report summarizes canola yields in Saskatchewan for 2025.


::: {.cell}

```{.r .cell-code}
library(tidyverse)
yields <- read_csv("canola_yields_2025.csv")
```
:::


## Mean yield by region


::: {.cell}

```{.r .cell-code}
yields |>
  group_by(region) |>
  summarise(mean_yield = mean(yield_bu_acre, na.rm = TRUE))
```
:::


The table above shows that the highest average yield was in...

When you render this file in Positron — click the Render button at the top of the editor, or press Ctrl+Shift+K — you get an HTML document with the prose, code, and output all inline.

Learn Quarto. It will change how you work.

5.5 Formatting Excel Workbooks for Handoff

Sometimes your deliverable is an Excel workbook. Here are habits that will make the difference between a workbook your colleague can use and one they’ll quietly throw away:

  • Start with a README sheet. What is this file? Who made it? When? What does each sheet contain? How often is it updated?
  • Separate raw, cleaned, and analyzed data. As discussed in Module 1. Lock the raw data sheet if you can, so nobody accidentally edits it.
  • Use named cells for assumptions. Every assumption in your model (discount rate, growth rate, cost per unit) should live in a labelled cell that is easy to find and change.
  • Label everything. Every column, every chart, every table header. “The reader should never have to ask ‘what is this?’”
  • Use conditional formatting sparingly. It can be powerful, but it can also make a workbook look like a Christmas tree. Use it to highlight things that need attention, not to decorate.
  • Freeze panes. If you have a large table, freeze the header row so it stays visible when you scroll.
  • Document your formulas. At the top of an analysis column, write a cell explaining what the formula computes.
  • Include the date you last updated it. In the README.

5.6 Test Bank Sample

  1. (Concept.) Why is “sympathy for the audience” a useful frame for writing a data analysis report?
  2. (Structure.) List the standard sections of a data analysis report in order.
  3. (Quarto.) What is the main advantage of Quarto over writing a report in Word with charts pasted in?
  4. (Excel handoff.) Name three things you should do to an Excel workbook before handing it off to a colleague.
  5. (Communication.) A chart with six decimal places of precision and no title. Name two things wrong with it.

5.7 Practice Exercises

  1. Write a one-page report on your Module 1 canola analysis, following the structure in Section 5.3.
  2. Convert the same report to a Quarto document with embedded code.
  3. Take an Excel workbook you have made earlier and add a README sheet, named assumptions, and proper formatting.
  4. Find a report online, critique it, and rewrite the executive summary.