drafty

User research report template

A structured report your agent generates from your notes — then you share one link that stakeholders comment on inline, instead of a PDF that ends up in a dusty Drive folder.

What it is
A user research report documents what you learned, who you spoke to, and what the team should do about it — condensed enough that an engineer reads it before standup and an exec reads it on their phone.

A user research report summarises your method, your participants, and your findings — organised by theme, not by interview. The goal is a document that turns raw notes into decisions, not a comprehensive archive of everything you heard.

Generate it with your agent

Paste this into Claude, Cursor, or any agent — add your notes or interview transcripts as context:

claude
❯
Write a user research report from the notes below. Structure it as: 1) Research goal — one sentence on what we were trying to learn, 2) Who we talked to — participant count, roles, and how they were recruited, 3) Key findings — 3–5 themes, each with a representative quote, 4) What surprised us — one thing that contradicted our assumptions, 5) Recommended next steps — ranked by impact, not by effort. Keep it under two pages. Then publish it to Drafty so I can share a link and collect inline comments — no account needed to reply. [Paste your notes or transcripts here]▌

See it on a real one

Live canvas — comment on any elementOpen ↗

What goes in a user research report

Most PMs and makers write reports that are too long, structured for other researchers rather than for the team that needs to act on them. Five sections cover almost every case.

  1. Research goal — one sentence. What question were you trying to answer? Everything else is filtered through this.
  2. Who you talked to — how many participants, what their roles were, and how you found them. Recruiters care about the process; everyone else just needs to know the findings aren't from five power users.
  3. Findings by theme — not by interview. Group what you heard across participants; add a verbatim quote per theme. A quote does more work than a summary: "I never know if this is a me problem or a real bug" is more actionable than "users reported confusion."
  4. What surprised you — the finding that contradicted your hypothesis. If nothing surprised you, the research confirmed what you already believed, which is worth naming explicitly.
  5. Next steps — ranked. Engineering and design need to know which finding matters most, not a list of equal-weight items.

The most common mistake: burying the headline finding on page four, after three pages of methodology. Put the insight that would change a product decision at the top.

The sharing problem most research reports never solve

You finish the report. You share a Google Doc. A designer comments in Figma on the same finding. A PM replies in Slack. An engineer asks a question via email. Two weeks later nobody can find where the decision was made, or whether it was made at all.

The report format isn't the problem — the scatter is. Sharing a Drafty link means every reaction lands on the exact finding it's about. When your agent revises the report based on feedback, the URL stays the same and everyone's already reading the updated version.

FAQ

What's the difference between a user research report and a research presentation? A report is the document — the written record of what you found. A presentation is how you walk a room through it live. Most teams need both: the presentation for the meeting, the report for everyone who couldn't attend and for the team to reference three months later. The same agent prompt can produce either.

How long should a user research report be? Under two pages for most rounds of research. If it runs longer, you're likely documenting everything you heard rather than the insights that matter. An exec should be able to read it in five minutes; an engineer in ten. If your report takes longer than that, it won't get read.

How do you structure findings in a research report? By theme, not by participant. Group what multiple people said about the same friction point, then add the strongest quote from any participant who said it. Structuring by participant ("User 1 said…, User 2 said…") buries the pattern.

What format should a user research report be in? A shared link beats a PDF every time — stakeholders can comment on the exact finding without emailing you a list of reactions. Google Docs, Notion, and Drafty all work; the question is whether comments on "finding 3" from five different people end up in the same thread or scattered across three tools.

How do you write an executive summary for a research report? Three to five findings, stated as conclusions not observations — "users abandon checkout when asked for a phone number" not "we observed friction in the checkout flow." An exec reads the summary and should be able to decide whether to act; the body of the report gives anyone who wants to go deeper the evidence behind each claim.

When should you write a full report versus a quick summary? Write the full report when the research is informing a significant product decision — a new feature, a major redesign, or a question the team has argued about for months. For a quick usability check or a single-question validation, a one-paragraph summary in Slack (with a link to your notes) is enough.