--- title: "Usability Test Report Template for PMs" description: "A usability test report template that leads with the three worst issues, with evidence, severity and action, plus an exec version, retest plan and filled log." canonical_url: "https://builderscamp.com/guides/templates/usability-test-report-template" date_published: "2026-10-05" date_modified: "2026-10-05" author: "Dr Chloe Sharp" publisher: "Builders Camp" guide_class: "templates" --- # Usability test report template: how to write a report stakeholders act on **TL;DR:** A usability test report that gets acted on leads with the three most severe issues, each with a specific finding, evidence (count out of five, a timestamped quote, a clip), a 0 to 4 severity rating agreed by three people, and a proposed action. Follow with what worked, a backlog table, a two-minute executive version that ties each issue to the metric it threatens, and a retest plan and insights log that carry findings into the next round. ## Why do most usability test reports get ignored? Most usability reports are written as a record of the study rather than as a tool for the next decision. Amy Schade of Nielsen Norman Group, in [Making Usability Findings Actionable](https://www.nngroup.com/articles/actionable-usability-findings/), puts the consequence plainly: "If product teams don't know what to do with usability results, they'll simply ignore them." Her fix is to treat the report as a design problem in its own right: "Usability findings have to be usable themselves: we need meta-usability." Volume is the usual failure. Schade notes that a usability report "may have 5 or 100 findings, depending on the scale of the study, the design tested, and the usability practitioner." A stakeholder who opens 40 findings reads the first few and forms a view from whichever were most vivid. The template below forces a ranking, puts three issues first, and moves everything else into a backlog table that the team works through but leadership does not need to read. This is the last step in a four-part sequence for a real test: [screener](https://builderscamp.com/guides/templates/usability-test-screener-questions), [session script](https://builderscamp.com/guides/templates/usability-test-script-template), [moderation](https://builderscamp.com/guides/other/usability-testing-moderation-tips), and the report. The filled example continues the same grocery checkout study. The analysis that comes before the report, coding notes and counting participants per problem, is covered in [AI for usability test analysis](https://builderscamp.com/guides/tools/ai-for-usability-test-analysis), and the overall method is in [how to run a usability test](https://builderscamp.com/guides/other/how-to-run-a-usability-test). ## What structure should a usability test report follow? Six sections, in this order, with the top three issues on the first screen: | Section | What goes in it | Length | |---|---|---| | 1. Summary | What was tested, with whom, the decision it feeds, and the verdict in one sentence | 3 lines | | 2. Top three issues | For each: finding, evidence, severity, proposed action | Half a page | | 3. What worked | Parts of the flow participants handled well, so nobody redesigns them | 3 to 5 bullets | | 4. Backlog | Every other issue in a table: finding, count, severity, owner, action | One table | | 5. Method and limits | Participants, format, tasks, what the study cannot tell you | 4 to 6 lines | | 6. Next round | Retest plan and open questions | Short table | The "what worked" section is not padding. Schade's advice is "Don't forget to include positive findings as well, letting the team know what's already working." Without it, a team fixing three problems in a flow will often rewrite the parts that were fine as well. ## How do you write a finding that a team can act on? Name the specific design element and what it caused, not the participant's difficulty. Schade's example of a finding that gives a team nothing to work with is "Registration was hard". Her second rule is "Don't blame the user": findings phrased as "three users could not find that" focus on people rather than on the design and make it easy for a reader to decide those users were unusual. | Weak finding | Why it fails | Actionable finding | |---|---|---| | "Checkout was confusing." | No element, no behaviour | "The delivery slot labels show only a start time, so participants read '11:00' as arriving by 11." | | "3 users couldn't find substitutions." | Blames users, names no cause | "Substitution settings sit behind a per-item Options link that no participant opened unprompted." | | "Users don't like the voucher field." | An opinion, not a behaviour | "The voucher field is collapsed under 'Add a code', and two participants typed the code into product search instead." | Each actionable version could be handed to a designer without a meeting. That is the test to apply before a finding goes into the report. ## How do you agree severity for each issue? Use Jakob Nielsen's 0 to 4 scale from [Severity Ratings for Usability Problems](https://www.nngroup.com/articles/how-to-rate-the-severity-of-usability-problems/), which combines frequency, impact and persistence: | Rating | Nielsen's label | What it means for the report | |---|---|---| | 0 | Not a usability problem | Leave it out | | 1 | Cosmetic problem only | Backlog, fix if time allows | | 2 | Minor usability problem | Backlog, low priority | | 3 | Major usability problem | Top issues or high-priority backlog | | 4 | Usability catastrophe | Top issues, fix before release | Do not rate alone. Nielsen's experience was that "severity ratings from a single evaluator are too unreliable to be trusted", and that the mean of ratings from three evaluators "is satisfactory for many practical purposes." In practice: after analysis, the PM, the designer and an engineer who watched sessions each rate every issue privately, then you average. Where the three differ by two points or more, discuss it, because the disagreement usually means the finding is written too vaguely. ## What does the blank report template look like? ``` USABILITY TEST REPORT: [Flow], round [n] Date: Author: Raters: 1. SUMMARY Tested: [flow and version] with [n] [participant type], [format], [dates]. Decision this feeds: [ship / revise / choose between options] Verdict: [one sentence] 2. TOP THREE ISSUES Issue 1: [specific finding: element + what it caused] Evidence: [x] of [n] participants. "[quote]" ([ID], [time]) Clip: [link] Severity: [mean] (ratings: [a], [b], [c]) Recommendation: [proposed action, labelled as a starting point] Owner: [name] Decision needed by: [date] Issue 2: ... Issue 3: ... 3. WHAT WORKED - [element participants used without hesitation, with count] 4. BACKLOG ID | Finding | Count | Severity | Recommendation | Owner 5. METHOD AND LIMITS Participants: [n, how recruited, mix] Tasks: [list, link to session guide] Limits: [what this round cannot tell you] 6. NEXT ROUND Retest: [issues and the task that retests each] New questions: [what to explore next round] Proposed date: [date] APPENDIX: notes, recordings, observation log [links] ``` ## What does a filled usability test report look like? Here is the report for round 1 of the grocery checkout study. Counts are out of five participants, quotes carry participant IDs and timestamps, and the products and numbers are invented for the example. ``` USABILITY TEST REPORT: Checkout redesign, round 1 Date: 14 October Author: PM Raters: PM, designer, engineer 1. SUMMARY Tested: new checkout prototype v3 (basket to payment) with 5 weekly online grocery shoppers, remote moderated, 45 minutes. Decision this feeds: ship the new checkout in the next release, or revise first. Verdict: revise first. Two issues would cause wrong orders. 2. TOP THREE ISSUES Issue 1: Substitution settings sit behind a per-item "Options" link that no participant opened unprompted, so participants could not set different rules for different items. Evidence: 4 of 5 could not set "replace milk, not bread" without help. 2 of 5 believed the default was "never replace". "I assumed it just won't swap anything." (P4, 19:32) Clip: [link] Severity: 3.7 (ratings: 4, 4, 3) Recommendation: show a replacement toggle on each basket line and state the default above the list. Owner: designer Decision needed by: 21 October Issue 2: Delivery slot labels show only a start time, so participants read "11:00" as arriving by 11. Evidence: 3 of 5 first chose the 11:00 slot for a "before 11" delivery. 2 noticed only when probed. "Oh. It might be after eleven." (P3, 07:30) Clip: [link] Severity: 3.3 (ratings: 3, 4, 3) Recommendation: label slots as ranges ("9:00 to 10:00") and repeat the chosen range on the payment screen. Owner: designer Decision needed by: 21 October Issue 3: The voucher field is collapsed under "Add a code" below the order total. Evidence: 2 of 5 typed SAVE10 into product search first. All 5 applied it eventually. "Is this where?" (P2, 14:05) Severity: 2.0 (ratings: 2, 2, 2) Recommendation: show the code field open above the total. Owner: engineer Decision needed by: next sprint 3. WHAT WORKED - 5 of 5 found and changed an existing order's slot (Task 4) in under two minutes. Keep the order card design. - 5 of 5 understood the basket total and delivery fee without questions. 4. BACKLOG ID | Finding | Count | Sev | Recommendation | Owner B1 | "Delivery" heading looks like a link | 2/5 | 1.7 | Restyle as heading | Designer B2 | Slot picker needs horizontal scroll on | 1/5 | 2.3 | Stack days on mobile | Engineer a small phone B3 | Cut-off time for changes not shown | 1/5 | 2.0 | Show "change until" | Designer 5. METHOD AND LIMITS Participants: 5 recruited by screener (2 phone-first, 3 who had a substitution in the last month), 1 spare unused. Tasks: 4 (session guide v1.2, linked). Limits: prototype only, no real payment; 5 participants show what goes wrong and why, not how often across all customers. 6. NEXT ROUND See retest plan below. Proposed date: 4 November. ``` Notice that the top issue is not the one with the highest count. Issue 1 and Issue 2 both affect most participants, but Issue 1 rates higher because a wrong substitution produces a wrong order that the customer cannot correct after delivery, which is the impact and persistence part of Nielsen's scale. ## How do you write the executive version? Write one paragraph per top issue, and tie each to the business metric it threatens. Executives do not need the evidence detail; they need to know what the issue costs and what decision you want. Keep the counts, drop the quotes except one, and link the full report. ``` CHECKOUT REDESIGN: USABILITY ROUND 1 (2 minute read) Recommendation: do not ship the new checkout in the next release. Fix two issues and retest on 4 November. 1. Customers cannot control which items get replaced (4 of 5 participants). Metric at risk: refunds and support contacts for unwanted substitutions. Fix: replacement toggle on each item. Small design change. 2. Customers misread delivery times (3 of 5 picked a slot that arrives later than they wanted). Metric at risk: missed deliveries and redelivery costs. Fix: show times as ranges. Copy change. 3. Discount codes are hard to find (2 of 5). Metric at risk: checkout completion for customers with a code. Fix: next sprint, not blocking. What works: changing an existing order, and the price breakdown. We are keeping both. Full report and clips: [link] ``` Do not invent the size of the metric impact. If you have a baseline (current substitution refund volume, say), add it; if not, name the metric and let the retest and post-release data size it. ## How do you present the report so it changes the plan? Present it in a meeting, with clips, before you send it. Jakob Nielsen's case in [Involving Stakeholders in User Testing](https://www.nngroup.com/articles/stakeholders-and-user-testing/) is that people who take part in analysis "are more likely to accept and act on the recommendations", and that seeing problems happen beats reading about them. A 30-second clip of a participant saying "It might be after eleven" does more than any severity number. Schade adds a rule for recommendations: label them as recommendations, offered "to jumpstart thinking about design solutions", not as the only answer, and do not hand over full redesign wireframes in place of findings. End the meeting with an owner and a date against each top issue. The [GOV.UK guidance on analysing a research session](https://www.gov.uk/service-manual/user-research/analyse-a-research-session) lists the kinds of actions to agree as a group, including "new user stories to add to the product backlog", which is where every backlog row should land before the meeting ends. ## What should the retest plan after fixes include? A retest reuses the same tasks, word for word, for every fixed issue, so you compare like with like. Nielsen's reasoning in [Why You Only Need to Test with 5 Users](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/) is that a redesign only seems to fix the problems until you check: "A second test will discover whether the fixes worked or whether they didn't." He also notes that a second round probes deeper, because participants are no longer stopped by surface problems. His summary: improve the experience with "3 studies with 5 users each" rather than one study with 15. | Issue | Fix shipped to prototype | Task reused (same wording) | Pass criterion | New task for round 2 | |---|---|---|---|---| | 1. Substitution settings hidden | Per-item replacement toggle, default stated | Task 2 | 4 of 5 set milk and bread rules without help | "Check what will happen if your eggs are out of stock" | | 2. Slot labels read as start time | Slots shown as ranges, repeated at payment | Task 1 | 5 of 5 choose a slot ending by 11:00 | None | | 3. Voucher field collapsed | Not fixed this round | Task 3 | Expect 2 of 5 again; confirms baseline | None | | New question | Not applicable | Not applicable | Not applicable | "Book a delivery for an address that isn't your home" | Keep the unfixed issue's task in the retest. If it fails at the same rate, that is evidence the round is comparable; if it changes, something else in the flow changed too. ## How do you keep a running usability insights log? Keep one table for the product, not one per study, and add every issue from every round. Schade's argument for keeping findings is about future value: "If you maintain an archive of usability findings people can draw upon these insights as they plan and execute future design projects. No reason to make the same design mistake a second time." ``` USABILITY INSIGHTS LOG: Grocery app ID | First seen | Flow | Finding | Sev | Rounds seen | Status | Fix | Retest result UX-14| Round 1 | Checkout | Substitution settings hidden per item| 3.7 | 1 | Fixed | Per-item toggle | Round 2: 5/5 pass UX-15| Round 1 | Checkout | Slot labels read as start time | 3.3 | 1 | Fixed | Ranges | Round 2: 5/5 pass UX-16| Round 1 | Checkout | Voucher field collapsed | 2.0 | 1, 2 | Open | Planned sprint 23 | Round 2: 2/5 fail UX-09| Onboarding | Account | Postcode error clears whole form | 3.0 | 1, 2, 3 | Won't fix | Accepted risk, Q3 | Not retested ``` Two columns make the log worth keeping. "Rounds seen" shows which problems keep coming back, which is the strongest argument for finally fixing them. "Retest result" separates fixes that worked from fixes that only shipped. Review the log at the start of each new study, so the next screener and session guide include any open issue that touches the flow you are testing. ## What can a usability report not tell stakeholders? A qualitative round shows what goes wrong and why, for the kind of person you recruited. It does not show how often it happens across all customers, and a report that writes "60% of users failed" on five sessions invites a fair challenge that undermines the real findings. Write counts out of five. When stakeholders need a rate, the next step is a larger unmoderated study or an experiment on live traffic. A report also cannot replace watching. Stakeholders who attended two sessions read the report differently from those who did not, so invite them to the next round before you send this one. When the retest is booked, start again from the [script template](https://builderscamp.com/guides/templates/usability-test-script-template) with the tasks from your retest table. Builders Camp runs live and self-paced bootcamps in product management and AI product building. [See the Usability Testing for Product Managers bootcamp](https://builderscamp.com/bootcamps/usability-testing-for-product-managers?utm_source=guide&utm_medium=organic&utm_campaign=usability-test-report-template) for the next cohort and the self-paced version. ## Frequently asked questions ### What should a usability test report include? A one-line summary of what was tested and with whom, the three most severe issues each with the finding, evidence, severity and proposed action, what worked well, a backlog table of the remaining issues, a short note on method and limits, and the plan for the next round. Everything else, such as full notes and recordings, goes in an appendix or a linked folder. ### How long should a usability test report be? Short enough to read in five minutes for the team version and two minutes for the executive version. The top three issues should fit on one screen. If the report has more than ten issues outside the backlog table, findings have probably been written as topics rather than as specific problems. ### How do you rate the severity of usability findings in a report? Use Jakob Nielsen's 0 to 4 scale, which combines frequency, impact and persistence: 0 is not a usability problem, 1 cosmetic, 2 minor, 3 major and 4 a usability catastrophe that must be fixed before release. Nielsen found ratings from a single person too unreliable, so have three people rate independently and use the mean. ### Should a usability report include recommendations? Yes, labelled as recommendations. Nielsen Norman Group advises presenting them as a way to start design thinking rather than as the only or best solution, and warns against handing over full redesign wireframes instead of findings. ### Should you report usability results as percentages? No, not from a qualitative round of five. Write 3 of 5 participants, never 60%, because a percentage implies a precision that five sessions cannot support. Percentages belong in quantitative studies with much larger samples. ### What is a usability insights log? A running table of every issue found across rounds, with when it was first seen, its severity, its status, the fix and the retest result. It stops teams rediscovering the same problem every quarter and shows which fixes actually worked. ### How long does it take to write a usability test report? Most of the time goes into analysis rather than writing. The GOV.UK Service Manual suggests aiming for 1 hour of analysis for every 2 hours of research, so five 45-minute sessions need about two hours of group analysis, plus an hour or two to write and cut the report. ## Sources - [Amy Schade, Nielsen Norman Group: Making Usability Findings Actionable: 5 Tips for Writing Better Reports](https://www.nngroup.com/articles/actionable-usability-findings/) - [Jakob Nielsen, Nielsen Norman Group: Severity Ratings for Usability Problems](https://www.nngroup.com/articles/how-to-rate-the-severity-of-usability-problems/) - [Jakob Nielsen, Nielsen Norman Group: Why You Only Need to Test with 5 Users](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/) - [Jakob Nielsen, Nielsen Norman Group: Involving Stakeholders in User Testing](https://www.nngroup.com/articles/stakeholders-and-user-testing/) - [GOV.UK Service Manual: Analyse a research session](https://www.gov.uk/service-manual/user-research/analyse-a-research-session) ## How this guide was made Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.