A useful user research report does five things: records the decision or decision status, describes the study, states the findings, links them to evidence, and names the next action and remaining uncertainty.
For a small exploratory study, that can fit on one page. The aim is not to prove that the research was rigorous by making the document long. It is to let you or a teammate return weeks later and understand what the study can support without reconstructing it from memory.
This guide gives you a copyable template, a filled example, and rules for writing findings without turning a small qualitative sample into a false statistic.
Copy this one-page user research report template
**Study:** [Study name] **Decision or status:** [What changed? If no decision was made, say what evidence is still needed.] **Research question:** [The question this study was designed to inform.] ## What I did - Dates: [Start–end] - Method: [Interview, usability test, concept test, or other method] - Participants: [Number and relevant segments] - Recruitment and incentive: [Source and amount, if any] - Not represented: [Important people, behaviours, or contexts outside this sample] - Source material: [Link to transcripts, recordings, notes, or repository] ## What I found ### 1. [Specific finding] - Evidence: [Observed behaviour or what participants described] - Study count: [For example, 7 of 12 participants in this study] - Representative quote: “[Verbatim quote]” - Counterevidence: [Contradictory case, outlier, or “none observed”] - Sources: [Links to the relevant sessions or excerpts] - Interpretation: [What you think the evidence means, clearly labelled as interpretation] [Repeat for the two to four other findings that matter to the research question.] ## What happens next - [Action, owner, and timing] - [What will be tested or measured] - [What evidence would change the decision] ## What I still do not know - [Gap caused by the sample, method, missing data, or conflicting evidence] - [The next question worth answering]
The template is deliberately plain. Put it in the tool your team already uses and link it to the original evidence. A polished deck in a forgotten folder is less useful than a short note that remains easy to find.
1. Start with the decision, not the backstory
The first line should tell future-you what changed because of the research.
Good decision lines are concrete:
- Decision: Fix the invite flow before building the Slack integration.
- Decision: Keep the current price and test a smaller entry plan.
- Status: No roadmap change yet. The current-customer sample does not answer why new signups fail to activate.
That third line matters. Research does not have to end in a decision. An exploratory study can narrow the problem, expose a sampling gap, or show that two plausible explanations remain. Forcing a recommendation when the evidence is inconclusive makes the report look decisive at the cost of being useful.
Use the word decision only for something actually decided. If the output is a hypothesis, experiment, or open question, label it that way.
2. Describe what you did in enough detail to judge the findings
Keep the method section short, but do not omit it. Record:
- the research question;
- the dates and method;
- who participated and how they were recruited;
- the incentive, if any;
- which important segments were absent;
- where the original material lives.
The missing segment is often the most valuable line. Nine paying customers can explain how paying customers work. They cannot tell you why people who signed up and never activated left.
This context also helps when a later study appears to contradict the first. Nielsen Norman Group recommends checking participants, tasks, logistics, and analysis before deciding that one result invalidates another. You can only make those checks if the report preserved the study design.
For a lightweight capture system, pair this report with a research repository for small teams rather than copying every transcript into the report.
3. Write findings as claims with traceable evidence
A finding is not a topic. “Onboarding”, “pricing”, and “Slack” are labels. A useful finding says what happened, where it happened, and why it matters.
Compare these:
| Weak | Stronger |
|---|---|
| Onboarding was confusing. | Six participants described leaving setup to ask an administrator for information they did not have. |
| People want Slack. | Four of five Slack requests were attempts to avoid checking whether a long-running task had finished. |
| Users could not find export. | In the usability test, the export action was below the fold and no participant found it without prompting. |
The last example is an observed usability finding. The first two are reports of what participants said. Do not blur that difference.
If you watched someone fail to complete a task, describe the behaviour and the relevant part of the interface. Nielsen Norman Group’s guidance on actionable usability findings recommends focusing on the design rather than blaming the participant.
If the evidence came from an interview, use appropriately narrow language: “participants described”, “participants recalled”, or “the accounts suggest”. An interview can reveal a workflow, motivation, expectation, or workaround. It does not by itself prove how the product behaved or how common the experience is in the customer base.
Keep observation and interpretation separate
Your report should make it possible to disagree with the interpretation without losing the source evidence.
For each finding, record:
- The claim: your concise description of the pattern.
- The evidence: what was observed or described.
- The sources: links to the relevant transcript moments, notes, or clips.
- The counterevidence: cases that did not fit.
- The interpretation: your explanation of why the pattern may exist.
A memorable quote can help someone recall a conversation. Teresa Torres includes one in her interview snapshot for that reason. But one vivid sentence is evidence from one participant, not proof of the whole finding. Keep the quote attached to the wider set of evidence.
If you still have raw notes rather than findings, use the separate guide to synthesising user interviews into themes before writing the report. Affinity mapping can help organise material, but the resulting groups still require interpretation.
4. Report study counts without pretending they are population estimates
For small qualitative studies, write:
7 of 12 participants in this study described switching to a spreadsheet.
Avoid:
58% of users switch to spreadsheets.
The first sentence describes the sample you actually studied. The second sounds like an estimate of all users.
This distinction is not cosmetic. Nielsen Norman Group shows how unstable percentages can be in small qualitative usability samples. In its worked example, 5 successful participants out of 10 produces a wide 95% confidence interval of 24% to 76%. Qualitative protocols also vary as moderators probe and follow different threads, adding more noise to numerical comparisons.
Counts still need care:
- Use the correct denominator. If only nine participants were asked or meaningfully addressed the topic, do not write “7 of 12”.
- Say participants in this study, not users or customers generally.
- Do not use frequency as the only measure of importance. A rare issue can be severe, and a frequent comment can be irrelevant to the decision.
- Do not count repeated mentions by one participant as multiple independent cases.
- Do not imply statistical precision from a purposive or convenience sample.
Counts help readers see the shape of the evidence. They do not turn an exploratory interview study into a prevalence survey. If you need to estimate how common a behaviour is, follow the qualitative work with an appropriate quantitative method. For sampling guidance, see how many users to interview.
5. Connect each finding to an action or decision status
A report should not quietly turn every finding into a feature request. For each important finding, choose one status:
| Status | Meaning |
|---|---|
| Act now | The evidence and risk justify a defined action. |
| Test next | The explanation or solution still needs evidence. |
| Monitor | Keep the finding visible and look for it in later work. |
| No action | It is outside the research question, strategy, or current scope. |
Then name the owner, timing, and evidence that would change the choice. “Explore notifications” is not an action. “Prototype email-on-completion this week and test whether it solves the checking problem” is.
For usability tests, you may also rate problems by frequency, impact, and persistence. Those factors come from Nielsen’s severity framework for usability problems. Do not present that framework as a universal score for discovery findings, market demand, or roadmap value. Those decisions also depend on evidence strength, strategic fit, cost, reversibility, and business risk.
Finish with what remains unknown. This is where you record the unrepresented segment, alternative explanation, missing behavioural data, or question the method could not answer. Unknowns stop a partial finding from hardening into company folklore.
A filled example
The company, participants, counts, quotes, and product details below are hypothetical. They illustrate the format; they are not Maren customer research.
Decision: Fix the invite flow before building a Slack integration.
Research question: What prevents new workspace owners from bringing a teammate into their first project?
What I did: 12 interviews from 8–24 July: 9 current paying customers and 3 customers who cancelled in the previous 90 days. Recruited from the customer list with no incentive. Async written interviews. Did not include people who signed up but never activated.
Finding 1: Eight participants described leaving the project to look for invite controls; six asked a colleague or support for help. Source excerpts: P-02, P-04, P-05, P-07, P-08, P-09, P-10, P-12. Interpretation: The project-level collaboration model is not visible from the project screen. Counterevidence: Two experienced administrators found the control without help.
Finding 2: Five participants requested Slack, but four described the underlying problem as not knowing when a long-running task had finished. Interpretation: Completion notification may solve more of the problem than a full Slack integration. This remains a hypothesis until tested.
What happens next: Add invite access to the project header and run a usability test. Prototype email-on-completion before scoping a chat integration. What would change the decision: Evidence that Slack is needed for a separate team workflow, not only as a notification channel.
What I still do not know: Whether people who never activated encountered the same invite problem. Recruit that segment before treating this as the main activation barrier.
The example does not claim that eight interviews prove the invite flow causes churn. It preserves a narrower chain: who was studied, what they described, how the founder interpreted it, and what will be tested next.
When a one-page report is not enough
A one-page report is a practical default for a small, focused qualitative study. It is not a universal standard.
Use a fuller archival report when someone must be able to reproduce or audit the work, when methods or results are complex, or when the decision is high-risk. Examples include benchmark or quantitative studies, broad competitive studies, field research that should remain useful for years, regulated work, and external consulting deliverables.
In a 2005 poll, Nielsen asked 258 usability practitioners which reporting methods they used. The responses were not mutually exclusive, and the poll is too old and too specific to usability practitioners to serve as a founder benchmark. Its lasting value is the distinction between quick findings for rapid iteration and formal reports for work that needs durable methodological context.
Choose the format based on the decision and the report’s future use, not on a fixed page count.
Build the report during the study
Report writing becomes slow when synthesis begins only after the final interview.
After each conversation, create a short record while the context is fresh. Torres’s interview-snapshot workflow captures one conversation on one page; she says experienced teams can create a snapshot collaboratively in 15–20 minutes. Treat that timing as her reported workflow, not a performance target.
Then:
- create or review the per-interview record;
- link notable evidence to its transcript or recording;
- compare records across participants;
- develop and challenge the themes;
- write the decision report from that organised evidence.
The guide to taking notes in a user interview includes a lightweight capture format. The important part is traceability: a later reader should be able to move from the report’s claim back to the relevant source.
Protect participant information in the report
A concise report can still contain personal data, especially in quotes and linked transcripts. Use participant IDs where names are not necessary, limit access, and avoid copying sensitive details into a widely shared document.
For organisations subject to the GDPR, the European Commission’s data-processing principles include purpose limitation, data minimisation, storage limitation, and integrity and confidentiality. Define retention and access rules for the report and its source material. Pseudonymising a quote reduces exposure, but context can still identify someone, so review what the quote reveals before sharing it.
How Maren fits into this workflow
For research run in Maren, transcripts, per-interview summaries, searchable conversations, cross-interview synthesis, and exports provide the evidence layer for a report.
Use those outputs as inputs, not as an automatic roadmap decision. Check consequential claims and quotes against the underlying conversation. Then add the context the product cannot know on its own: your decision, constraints, behavioural data, alternative explanations, next action, and remaining uncertainty.
The final report should make the reasoning inspectable. Maren can organise what participants said across interviews; the researcher remains responsible for deciding what that evidence can support.
User research report checklist
Before sharing or archiving the report, check that it:
- states a decision, decision status, or explicit reason not to decide;
- names the research question;
- describes participants, recruitment, method, and missing segments;
- limits findings to what the method can support;
- links every important claim to source evidence;
- includes counterevidence or meaningful outliers;
- scopes counts to the study rather than the wider population;
- separates observation from interpretation;
- assigns each finding an action status;
- records what is still unknown;
- protects participant identity and sensitive information;
- lives somewhere the team will find again.
A research report is successful when a later decision-maker can see not only what you concluded, but why—and where the conclusion stops.