How to Write a User Research Report People Can Act On

The short answer

A user research report is not a stack of interview summaries or a slide deck decorated with memorable quotations. Its job is to help someone who did not attend the sessions understand what the team observed, which evidence supports that interpretation, where it may not hold, and what should happen next.

Treat it as an evidence-backed decision record. Open with the decision and the two or three findings that matter most. Keep every important claim connected to source material. Close with recommendations, unresolved questions, and limitations. Detailed coding work belongs in an appendix or research repository, not necessarily in the main narrative.

A polished document can still rest on weak evidence. If the study has not produced defensible findings, do not ask an AI writing tool to disguise that gap with fluent prose.

Decide what the report must help someone do

The same interviews can support different reports. A product manager may need to choose between fixing onboarding and improving permissions guidance. A sales lead may care about buying friction. A researcher may need to plan the next round.

Before drafting, answer four questions:

• Who will read the report, and who owns the decision?
• What might they start, stop, or choose after reading it?
• Which research questions directly affect that choice?
• Which interesting material does not belong in this report?

“Summarize eight onboarding interviews” describes an activity. “Help the product team decide whether to revise invitations or permission guidance next quarter” gives the report an editorial rule.

GOV.UK recommends sharing research early enough for teams to use it in design, prioritization, and roadmap decisions. A short, self-contained briefing is often more useful than a formal report that arrives after the decision has already been made.

A report structure that is usually enough

Executive summary

In a page or less, state the context, the most consequential findings, the current recommendation, and the main unresolved risk. This is not a table of contents. A reader who stops here should still understand the decision at hand.

Objective and research questions

Explain what decision the study was intended to inform and what the interview material could answer. Do not quietly rewrite the objective as proof that the team’s original idea was right.

Participants and method

Record dates, session count, recruitment criteria, relevant role differences, session format, and analysis method. Participants need not be named, but readers need to understand the scope behind the claims. Mention incomplete sessions, missing recordings, or recruitment bias.

Key findings

This is the main body. Each finding needs a direct headline, explanation, scope, supporting evidence, and relevant counter-evidence. Order findings by their importance to the decision rather than the sequence of the interview guide.

Recommendations and open questions

Separate low-risk actions, directions that need design testing, and questions that need more research or quantitative data. Research can narrow the solution space without pretending there is only one answer.

Limitations and appendix

State sampling and method boundaries. Keep the plan, discussion guide, terminology, and detailed evidence index available for review without burying the main message.

Write only as broadly as the evidence allows

The most common reporting error is not a finding that is too short. It is a finding that is too large.

Suppose four of six first-time operations users paused before inviting a teammate because they wanted to check permissions. A bounded finding could say:

In this round, the invitation step prompted operations users to check permission risk. Several paused setup and consulted a manager or IT colleague.

Do not turn that into “Users do not trust our permission model” or “The invitation flow causes 67% of new-user churn.” The first claim invents a universal attitude. The second turns a small qualitative sample into a churn estimate.

A defensible finding explains what happened, among whom or under which conditions, why it matters to the decision, and what the evidence cannot establish. Counts can describe this study’s material, but they do not replace a scope statement.

Nielsen Norman Group distinguishes raw data, findings, and insights: quotations are data; findings describe patterns; insights interpret those patterns using user and business context. Keeping these layers separate makes overclaiming easier to spot.

Use quotations as traceable evidence, not decoration

A vivid quotation can take over a meeting. It may also describe one unusual case or mean something different when returned to its surrounding conversation. Quotations should help the reader understand a finding, not stand in for the finding.

For each important claim, preserve the anonymous participant or session, exact transcript passage, recording timestamp, review status, and whether the item is supporting evidence, counter-evidence, or a researcher note.

The transcript records what the participant said. A researcher note may contain observation and interpretation. Do not merge them into a generic “user feedback” statement. NN/g’s evaluation of AI research tools found that conclusions without session-level references, timestamps, or source links were difficult to validate and could blur participant data with researcher notes.

Do not silently rewrite a quotation for effect. Mark omissions, retain enough context, and remove personal or client information before sharing it.

Keep counter-evidence in the report

Four participants getting stuck at the same point makes a neat story. The two who did not get stuck may reveal the condition that matters.

For example:

Four participants checked permissions before inviting a teammate. The other two continued without pausing; both had received an administrator’s permission checklist before the session. The present evidence suggests missing information may contribute to the friction, rather than the interaction alone.

That qualification makes the next step clearer: test whether earlier permission guidance reduces hesitation before committing to a full redesign.

Look for silent gaps as well. Missing roles, aborted sessions, unasked questions, and cases that resist the dominant theme all affect the boundary of a finding.

Keep recommendations separate from findings

“People could not find the permission guidance” is a finding. “Move the guidance above the Invite button” is a solution hypothesis. They are related, but they are not the same claim.

Separating them lets the team accept the problem while proposing a better solution. It also means a failed design test does not erase the underlying research.

Group recommendations into actions that are low-risk now, ideas that need design and usability testing, and questions that still need research or analytics. Give each recommendation an owner, intended effect, and a way to check it. “Improve guidance” is not testable. “Test two placements in five task-based sessions and observe whether participants can decide whom to invite without help” is.

State limitations and privacy boundaries plainly

Limitations tell readers where the report is safe to use. Mention whether recruitment favored active customers, whether an important role is absent, whether the study relied on self-report, whether translation may have changed nuance, and which prevalence or causal questions this round cannot answer.

Review privacy again before sharing. GOV.UK recommends using fully anonymized extracts where possible and removing names, contact details, and other direct identifiers. Material that cannot be adequately anonymized should only go to people who need it and whom participants were told could receive it.

Replacing a name with “Participant A” may not be enough. A rare role, company size, city, and distinctive story can identify someone in combination.

Build and check the report in ScribeFlash

ScribeFlash starts the reporting workflow from reviewed findings rather than an empty document:

1. In Analysis, open each suggested finding. Check its wording, supporting evidence, counter-evidence, and citations before confirming or rejecting it. AI-generated text is not a final fact.
2. After confirming at least one reliable finding, open Report and generate the report. A draft can be created without confirmed findings for editing, but a draft cannot be exported.
3. Review the generated objective, method, participant overview, findings, evidence, limitations, recommendations, and appendix. Edit them for the actual audience and decision.
4. Edit section titles and text. Add, duplicate, reorder, hide, or delete sections. Hidden sections are excluded from export.
5. Open report references and check the linked finding, participant, interview, source passage, and timestamp. Resolve citations that became invalid after source changes.
6. Run the quality check to review finding, supporting-evidence, counter-evidence, and valid-citation counts. Resolve critical citation errors before marking the report ready.
7. Mark the reviewed report ready, then export TXT, CSV, DOCX, or PDF. Download the file after the export job finishes.
8. If transcripts, evidence, or findings change later, create a new report version and review it again instead of circulating an outdated export.

See the research report guide for the interface workflow and the finding review guide if the upstream analysis is not ready.

A five-minute check before sharing

• Does the summary name the decision this research informs?
• Is every major finding scoped to the relevant people and context?
• Can each quotation be traced to a session, transcript passage, and timestamp?
• Does counter-evidence that changes the finding’s boundary remain visible?
• Are recommendations separated from findings and written as checkable next steps?
• Are the limitations specific and the privacy treatment consistent with participant consent?
• Are hidden sections, stale versions, and invalid citations excluded from the final export?

After sending the report, schedule a discussion. Ask the people responsible for the decision what they believe the evidence says, what action they intend to take, and what they still doubt. Delivery is not the file itself. It is the point at which the team can make a clearer decision from the same body of evidence.

Sources

• GOV.UK Service Manual: Sharing user research findings
• GOV.UK Service Manual: Analyse a research session
• GOV.UK Service Manual: Managing user research data and participant privacy
• Nielsen Norman Group: Data vs. Findings vs. Insights
• Nielsen Norman Group: Making Usability Findings Actionable
• Nielsen Norman Group: AI-Powered Tools for UX Research: Issues and Limitations