data.day

Test the Report on the One Person Who Knows Nothing: A 15-Minute Sanity Check

You are too close to the data. You assume the client understands your acronyms. They don't. Here is how to fix it before you hit send.

The Acronym That Almost Got Us Fired

I once reviewed a report that contained the phrase: “The MOM churn is static due to high ARPU in the SME segment.”

I asked the analyst, “Does the client know what ARPU means?” He looked at me with genuine confusion. “Of course. Everyone knows Average Revenue Per User.”

We sent the report. The client replied: “Why are we talking about the SME segment? I thought we were targeting Enterprise?”

They had completely missed the point about churn because they got stuck on the acronym. The meeting was a disaster. We spent the whole time arguing about definitions instead of strategy.

It was tragic. We were speaking fluent Geek, and the client was listening in Human.

The Drag: The Bias of Immersion

When you work on a project for weeks, you lose your perspective. You forget that “Session Duration” is not a term normal people use at the dinner table. You start to think that a complex scatter plot is “intuitive.”

It isn’t. You have just developed Stockholm Syndrome with your own data.

This bias drags down the quality of our work. We produce reports that make perfect sense to us and zero sense to the person signing the cheque. We think we are being precise; they think we are being exclusionary.

If the font size is 8 and the acronyms are obscure, you aren’t reporting; you are code-switching.

The Answer: The “Intern Test”

I implemented a protocol at my last agency. Before any major strategic report went out, it had to pass The Intern Test.

We would grab a junior staff member—or sometimes the office manager—someone who had zero context on the account. We would put the report in front of them for 60 seconds.

Then we took it away and asked three questions:

  1. What is the main news? (Good or bad?)
  2. What do we need to do?
  3. Was anything confusing?

If they couldn’t answer question 1 instantly, the report failed. Back to the drawing board.

[TO EDITOR: A flowchart diagram. Box 1: “Draft Report”. Arrow to Box 2: “The Naive User (No Context)”. Arrow to Diamond: “Did they get the headline in <60s?”. Path Yes: “Send it”. Path No: “Rewrite Title & Simplify”.]

It was brutal, but brilliant. We found that 90% of our charts were too complicated. We found that our titles were vague.

“I didn’t know what ‘Attribution’ meant,” the intern would say. “Right,” I’d reply. “Change it to ‘Where sales came from’.”

Sorted.

It takes fifteen minutes. It saves hours of awkward phone calls. Stop designing for yourself. Design for the person who hasn’t slept, hasn’t read the previous email, and just wants to know if they are winning.

FAQs

But I don't have time for user testing.

Do you have time to explain the report three times in follow-up emails? I didn't think so.

Who should I test it on?

The receptionist. The intern. Your mum. Anyone who isn't in the data team.

What if they don't understand the technical terms?

Then the technical terms are the problem. Rewrite them.