Blog / Research

How to Write a UX Research Report That Drives Action

By Vadim Glazkov July 8, 2026 13 min read

Learn how to write a UX research report that persuades, not just informs. A practitioner guide covering structure, decisions, and the failure modes that kill

On this page

A UX Research Report Is a Persuasion Document, Not a Data Dump

Most UX research reports fail before anyone reads them. Not because the research was weak, but because the report was built to document rather than to persuade.

That distinction matters more than it sounds. A research repository stores everything — transcripts, themes, stimulus materials — so the organisation can find it later. A report has a different job: move a specific person toward a specific decision. Conflate the two and you end up with a document that opens with a three-page methodology section and buries the insight around page six. By then, most stakeholders have stopped reading.

The antidote is a throughline: one central claim or recommendation that every section serves. Think of it as the verdict the reader should be able to state after two minutes with the document. Everything else — evidence, method, context — exists to support that verdict, not to demonstrate how thorough the study was.

What follows is a complete approach: audience mapping, a six-section structure, guidance on writing findings and recommendations, the failure modes we see most often, and a lightweight template you can use immediately. The logic connects to our broader Insight to Impact pillar for teams who want to take this further.

Know Your Audience Before You Write a Single Section

Before you open a blank document, answer one question: who has to make a decision based on this report, and what is that decision?

That person is your primary reader. Everyone else — the product squad who will implement the changes, the researcher who will archive the study — is a secondary reader. Secondary readers matter, but they should not determine the report’s structure. Write for the decision-maker; serve the others through the appendix and supplementary sections.

Once you know the primary reader, map what they need to decide. Start there, not from your study design. A research director running a steering committee needs a clear recommendation and enough evidence to defend it in the room. A product squad planning a sprint needs the same recommendation plus the granular findings that will inform their backlog. Same study, different calibration.

Two further questions shape the format significantly. Will the report be read asynchronously — forwarded as a PDF on a Friday afternoon — or walked through live in a presentation? An async document needs to work without you in the room: clearer signposting, more explicit transitions, no reliance on verbal context. A live walk-through can be leaner because you supply the connective tissue in real time.

Prior beliefs also count. A sceptical stakeholder who doubts the research question was worth asking needs more evidence scaffolding — more explicit methodology, more participant context — than a champion who already trusts the process. For more on adapting delivery to different stakeholder types, see our guide to communicating research findings to stakeholders.

The Six-Section Structure That Works

This structure mirrors how persuasion actually works: conclusion first, evidence second. Readers who know what you are arguing can evaluate evidence as they encounter it. Readers who have to infer the conclusion from a sequence of observations often reach the wrong one.

Section 1 — Executive summary. One short paragraph, three bullets at most, key recommendation stated plainly. This is the verdict. If a stakeholder reads nothing else, they should know what you found and what you recommend. Write this section last, but place it first.

Section 2 — Context and research question. Explain what decision this study was designed to inform. Not a full brief recap; a single paragraph that orients the reader. “This study investigated why users abandon the checkout flow before payment confirmation, to inform the Q3 redesign prioritisation decision.”

Section 3 — Method snapshot. One short paragraph — enough for credibility, not enough to distract. State the method, the number of participants, and the recruitment criteria. Link to your user research plan template or the full research plan in the appendix rather than reprinting it. If a stakeholder wants the detail, it is there; if they do not, they have not lost a page to it. For guidance on choosing the right method in the first place, the UX research methods comparison is a useful reference.

Section 4 — Key findings. Three to five findings, each named as a declarative insight rather than a topic label, each supported by one strong evidence anchor. More on this in the next section.

Section 5 — Implications and recommendations. Explicitly connect each finding to an action or a prioritised open question. Every finding should lead somewhere. If it does not, it probably belongs in the appendix.

Section 6 — Appendix. Participant profiles, raw themes, extended methodology, additional quotes. Available for those who want it; not in the critical path for those who do not.

Writing Findings That Actually Land

The single most common problem in research reports is findings named as topics rather than stated as insights.

Compare these two:

  • Topic label: “Pricing page behaviour”
  • Declarative insight: “Users abandon at the pricing step because they cannot compare plans without navigating away from the page”

The first tells the reader where to look. The second tells them what is true. Write every finding as a declarative statement. Subject, verb, implication.

Each finding then needs one evidence anchor — a single quote or data point that makes the finding tangible. Not a list of all supporting data, which disperses attention, but the one piece of evidence most likely to make a stakeholder feel the problem rather than just understand it.

Severity and frequency framing signal priority without hiding it in a sortable appendix. “Seven of nine participants could not complete this task without assistance” is a finding with clear weight. “Some users struggled with this step” gives every stakeholder an exit — they can decide the “some” does not apply to their users and move on.

We saw this pattern recently on a study involving a multi-step onboarding flow, where participants were failing at the same step consistently. The draft report read: “Several participants experienced confusion during account verification.” We rewrote it as: “Eight of ten participants stopped at the identity verification step, with six explicitly stating they did not understand why the information was needed.” The rewritten version produced an immediate prioritisation decision in the readout session. The original had not.

Avoid hedge language for findings you are confident in. Use it precisely and explicitly for findings where confidence is genuinely lower — and say so plainly rather than burying it in passive voice.

Recommendations: The Section Most Reports Get Wrong

Every recommendation should map directly to a finding. When recommendations appear without a corresponding finding — or findings appear without a recommendation — stakeholders lose confidence in both.

Write recommendations in plain action language: subject + verb + object. “Redesign the comparison table so users can evaluate plans without leaving the pricing page.” Not “Consider improving the pricing experience.”

We find it useful to distinguish three tiers:

  • Must-do — blocks a decision or represents a significant barrier to the primary outcome
  • Should-do — improves the outcome but does not block progress
  • Explore further — an open question that requires additional research before a recommendation is warranted

Acknowledging trade-offs or constraints where you know them is not a sign of weakness. It signals that you understand the operational context and are not making recommendations in a vacuum. “This would require reworking the current CMS template, which the engineering team has estimated at three weeks” is more useful than a recommendation that ignores that constraint entirely.

Where possible, tie recommendations to measurable outcomes. “If users can compare plans in a single view, we expect to see a reduction in drop-off at this step, which we can validate against existing funnel analytics.” That sets up the ROI conversation naturally. See our post on how to measure UX research ROI for a fuller treatment.

Common Failure Modes and How to Avoid Them

Failure mode 1 — The methodology marathon. Three pages of method before a single finding. Fix: method snapshot in the body, full detail in the appendix. Methodology establishes credibility; it does not need three pages to do it.

Failure mode 2 — Finding inflation. Fifteen findings dilute priority. If everything is a finding, nothing is. Ruthless synthesis to three to five findings — with the rest moved to the appendix — forces you to decide what actually matters, which is exactly the judgment stakeholders are paying you to provide.

Failure mode 3 — The neutral narrator. Writers avoid asserting recommendations for fear of overstepping. The result is a report full of passive observations and no clear direction. Own the interpretation. Flag genuine uncertainty explicitly — “we are less confident in this finding given the small sample at this stage” — rather than hiding it in vague language that makes every finding seem provisional.

Failure mode 4 — Format mismatch. A 40-slide deck sent as an async email attachment. A two-page summary presented in a 90-minute session. Match the format to how the report will actually be consumed. This connects to the broader challenge of research democratisation and quality guardrails — as more people produce research outputs, format discipline tends to slip.

Failure mode 5 — No next step. The report ends with findings and recommendations, then nothing. Close every report with an explicit decision prompt: “A go/no-go decision on the pricing page redesign is needed before sprint planning on [date]” or “We recommend a follow-up conversation with the engineering lead to assess feasibility of recommendation two.”

Formatting and Accessibility Choices That Improve Uptake

Formatting is not cosmetic. A well-structured page reduces cognitive load and increases the chance that a busy stakeholder actually reaches the recommendation.

Use a scannable hierarchy within each finding: H2 finding name, supporting paragraph, quote callout, implication bullet — in that order. A reader skimming the document gets the insight from the heading, the context from the paragraph, and the action from the bullet. They do not have to read every word to navigate the report.

Limit colour coding to two or three semantic values — risk, opportunity, open question, for instance — and explain them once at the top of the document. More than three colours stops being a system and starts being decoration.

PDFs and living documents each have a place. PDFs preserve a version cleanly and travel well across organisations, but they cannot be updated when a decision changes and they kill collaboration. Notion or Confluence pages stay live and editable, but they can sprawl without active maintenance. Choose based on your team’s actual norms, not on what feels more professional in the abstract.

Version and date every report clearly. Stakeholders surface reports months after they were written, often without the original context. “V1.2 — approved for distribution — 14 June 2025” costs nothing and prevents significant confusion.

Accessibility basics: alt text on any screenshots that carry meaning, sufficient contrast on highlight colours, and no embedding of key data only inside images. If someone is using a screen reader or a printed monochrome copy, the core findings should still be legible.

A Lightweight UX Research Report Template to Start From

Before writing a single word of the report body, complete three fields:

  1. Decision context: What specific decision will this report inform, and who will make it?
  2. Primary audience: Who is the decision-maker, and what do they already know about this study?
  3. Central recommendation: What is the one thing you want the reader to do or decide after reading this?

If you cannot answer all three, you are not ready to write.

The section skeleton then follows:

## Executive summary
[One paragraph. Key recommendation in the first sentence. Three bullets: top finding, primary recommendation, decision needed.]

## Context and research question
[One paragraph. The decision this study was designed to inform.]

## Method snapshot
[One paragraph. Method, participant count, recruitment criteria. Link to full plan.]

## Key findings
[Finding 1 — declarative statement]
[Evidence anchor]
[Implication]

[Repeat for findings 2–5]

## Recommendations
[Recommendation 1 — must-do/should-do/explore-further]
[Maps to: Finding X]
[Measurable outcome]

## Appendix
[Participant profiles, extended methodology, full theme list, raw quotes]

Teams at earlier stages of UX maturity may need to expand the method snapshot and provide more participant context — stakeholders who are less familiar with research methods often need more scaffolding to trust the findings. Teams with established research practice can usually compress the context and method sections significantly and spend more space on the implications. The UX maturity model for product teams offers a framework for calibrating this.

The upstream input for the context section is your research plan. If that plan was written clearly, the decision context and research question should transfer almost directly.

Frequently Asked Questions

How long should a UX research report be?

It depends on audience and decision complexity. An exec-facing report often needs only two to four pages plus appendix. A full findings document for a product squad can run to ten pages. Default to shorter: if a section does not serve the decision, move it to the appendix.

What is the difference between a UX research report and a research presentation?

A report is an asynchronous artefact designed to be read and referenced independently. A presentation is a facilitated event where you supply context in real time. They serve different jobs, and a presentation deck sent as a standalone document is usually a poor version of both. If the primary delivery is a live session, follow it with a written summary so stakeholders have something to reference later.

Do I need a UX research report template?

A template is useful as a starting constraint, not a final form. The six-section structure above works for most studies. Adapt the depth of each section to your audience and the complexity of the decision, rather than filling every section to a fixed length regardless of what the study produced.

What should go in the appendix?

Participant profiles and recruitment criteria, the full methodology, extended theme lists, additional quotes that support findings but were not the strongest anchor, and any stimulus materials. The appendix is a reference layer — it supports the argument without cluttering it.

How do I write UX research findings without overstating what the data shows?

State the finding as a declarative claim, then immediately specify its basis: “Eight of ten participants could not locate the cancellation option without prompting.” Use hedged language only when confidence is genuinely lower, and be explicit about why: “This finding is based on five participants and warrants validation with a larger group before acting on it.” The goal is precision, not caution for its own sake.

About Glasgow Research — Glasgow Research helps B2B SaaS teams turn customer and market research into product decisions. Work with us.

Author

About Vadim Glazkov

Vadim Glazkov is the founder of Glasgow Research and a product research expert working with founders and B2B SaaS teams on customer interviews, JTBD, market validation, and decision-ready research.

View author page