A few months ago, I sat in front of three spreadsheets, two exported survey reports, and a folder of client interview notes that collectively represented weeks of research work. The problem? None of it meant anything yet. The data existed, but the insight didn't. And the deliverable was due in 48 hours.
That pressure-cooker moment forced me to develop a repeatable process for turning raw data into documents that actually move people to action. I've since refined it across dozens of client projects here at Helion 360, and I want to walk you through exactly how it works.
Why Raw Data Fails to Communicate
The first thing I had to accept is that data doesn't speak for itself — ever. A 400-row spreadsheet doesn't tell a story. A pile of verbatim quotes doesn't reveal a pattern. The gap between raw data and a useful document isn't a formatting problem; it's a thinking problem. Once I understood that, the process got a lot cleaner.
Most raw data fails to communicate for three reasons:
- No narrative frame: The reader doesn't know why the numbers matter.
- No hierarchy: Everything looks equally important, so nothing stands out.
- No next step: The document ends when the data runs out, leaving the reader to figure out what to do with it.
My process directly addresses all three.
Step 1: Define the Decision Before You Touch the Data
Before I open a single file, I write one sentence at the top of a blank document: "This document exists to help [audience] decide [specific decision]."
That sentence is the north star for everything that follows. It tells me which data points are relevant and which ones, no matter how interesting, are noise. In a recent brand strategy project, we had rich demographic data on six customer segments. But our client needed to choose which two to prioritize for a product launch. That decision meant four of those segments were essentially irrelevant to the document I was building — not to the business, but to this particular document's purpose.
Clarity about the decision makes the data selection process dramatically faster and produces a sharper final product.
Step 2: Sort Data Into Three Buckets
Once I know the decision I'm serving, I go through all raw data sources and sort every data point into one of three buckets:
- Must-have: Directly answers or informs the core decision.
- Supporting: Adds context or credibility to the must-have findings.
- Archive: Interesting but not relevant to this document's purpose.
I do this pass quickly and without overthinking. The goal isn't perfection — it's momentum. You can always move things between buckets later. What you can't recover easily is the time lost trying to make every data point earn its place in real-time as you write.
For qualitative data like interview notes or open-ended survey responses, I use affinity mapping. I paste quotes and observations into sticky notes (digitally, in FigJam or Miro) and cluster them by theme. The clusters that appear most frequently across sources almost always end up in the must-have bucket.
Step 3: Build the Argument, Not the Report
Here's where most data documents go wrong: they present findings chronologically or categorically — essentially mimicking the structure of the data collection process itself. That's a report. What I build is an argument.
An argument has a claim, evidence, and a conclusion. For example:
- Claim: Your current onboarding flow is losing users at the account setup stage.
- Evidence: Drop-off analytics show 61% of users exit before completing profile setup; exit survey data shows 43% cite "too many required fields" as the reason.
- Conclusion: Reducing required fields at setup to three or fewer is the highest-leverage UX change available right now.
When I structure a document this way, the reader doesn't have to work to understand what the data means. The meaning is already extracted. Their cognitive load goes entirely toward evaluating the recommendation — which is exactly where you want it.
Step 4: Design for Scannability
The best insight in the world gets ignored if the document is a wall of text. I apply a few non-negotiable formatting principles to every document I produce:
- Lead with the headline finding, not the methodology. Nobody reads the methodology section first. Put your most important conclusion at the top.
- Use callout boxes or pull quotes for the one or two statistics that do the heavy lifting.
- Keep paragraphs to three sentences or fewer. This isn't dumbing it down — it's respecting the reader's time.
- Include a one-page executive summary for anything over five pages. Decision-makers will often read only this.
At Helion 360, we treat document design as part of the research deliverable, not an afterthought. A well-designed document signals credibility and makes the content easier to act on. Those aren't soft benefits — they directly affect whether your recommendations get implemented.
Step 5: End Every Document With a Clear Action Layer
The final section of every document I write is what I call the Action Layer. It contains three things:
- Prioritized recommendations: What should happen first, second, and third — with brief rationale tied back to the data.
- Decision points: Any choices that require stakeholder input before action can begin.
- Success metrics: How you'll know whether the recommended actions worked.
This section is often shorter than people expect. Sometimes it's a single page. But it transforms the document from an information artifact into a working tool. The reader leaves knowing what to do Monday morning — and that's the whole point.
What This Process Actually Produces
When I ran this process on that original pile of spreadsheets and interview notes, what came out the other side was a 14-page strategy document with a 1-page executive summary, three core findings, and five prioritized recommendations with owners and timelines assigned. The client's leadership team approved the strategy in their first review meeting — no revision rounds.
That's not luck. That's what happens when you stop presenting data and start serving decisions.
If your team is sitting on research that hasn't become action yet, the bottleneck is almost never the data itself. It's the process of transforming it. Get that process right, and everything downstream moves faster.