A usability testing report connects a decision to the evidence behind it: what was tested, what happened, what remains unknown, and who acts next. Use the template below to report human studies, synthetic browser checks, and supporting QA without turning them into one misleading success rate.
This is a manual, tool-agnostic report template, not an automatic Swarm export. It covers the study-level decision; the first website test guide covers run setup and individual issue triage.
What should a usability testing report include?
Include an executive summary, study purpose, methods, task results, prioritized findings, and recommendations. The Department of Homeland Security's reporting guidance also calls for positive findings and ties qualitative and quantitative observations to the tasks that produced them.[2]
The template adds a decision record and evidence register so readers can trace each recommendation. An evidence register is an index of the original material, its method, and its limits. A disposition records what the team decided to do with a finding, including deferring or rejecting it with a reason.
Keep the methods separate
Choose the applicable rows below. For a broader explanation of the categories, see the AI usability testing methods guide.
AI-assisted analysis of human sessions belongs with those sessions, with the analysis tool and human review disclosed. Keep generated commentary separate from participant quotations. Nielsen Norman Group advises treating synthetic-user findings as hypotheses and never presenting them as real-user research.[36] Its cited evaluation concerns simulated interviews, not a benchmark of browser-agent accuracy.
Copyable usability report template
Copy this block into your document. Replace each brace-delimited field, remove unused method rows, and write "not collected" rather than leaving evidence gaps blank. Keep sensitive recordings in an access-controlled repository; use redacted IDs in the report.
USABILITY TESTING REPORT
Report ID / version: {ID, version, date}
Report owner / decision approver: {names}
Product / build / environment: {scope}
Study dates / report audience: {dates, readers}
Decision deadline: {date}
EXECUTIVE DECISION
Decision requested: {specific release or design choice}
Recommendation: {release, hold, limited rollout, more research}
Supporting findings: {finding IDs and evidence IDs}
What worked: {observed successful paths and evidence IDs}
Unresolved risk: {unknowns that could change the decision}
Disposition: {approved, rejected, deferred, with reason}
Accountable owner / due date: {name, date}
Approver / decision date: {name, date or pending}
Retest required before closure: {criteria, owner, date}
PURPOSE AND COVERAGE
Research questions: {questions this study can answer}
Target users / recruitment criteria: {population, selection}
Included tasks / success criteria: {task IDs, observable outcomes}
Excluded roles, devices, states and tasks: {gaps and reasons}
Safety and privacy controls: {fixtures, consent, access, retention}
METHOD-SPECIFIC EVIDENCE REGISTER
Repeat one entry for each evidence set.
Evidence ID / method: {ID, human, synthetic, QA, analytics}
Collection dates / build / environment: {conditions}
People or runs included: {IDs and eligibility rule}
Method details: {recruitment and moderation OR agent configuration
OR test assertion OR analytics event/cohort definitions}
Assistance, retries, setup failures: {counts and treatment}
Original evidence: {restricted link, timestamp or step reference}
Reviewer / verification status: {name, reviewed or pending}
Limitations: {what this evidence cannot establish}
TASK RESULTS: REPEAT PER TASK AND METHOD
Task ID / method / evidence IDs: {identifiers}
Unit counted: {distinct participants, runs, tests, form attempts}
Success rule / observation window: {rule, window}
Eligible units / attempted units: {counts}
Completed without help / with help: {counts, if applicable}
Failed / unresolved / not attempted: {counts and reasons}
Excluded units: {count, reason, whether excluded from denominator}
Reported result: {numerator / explicit denominator, method label}
Time or ratings, if collected: {definition, units, eligible subset}
Comparison limits: {changes in task, build, sample or conditions}
FINDINGS AND ACTIONS: REPEAT PER FINDING
Finding ID / task / evidence IDs: {identifiers}
Observed behavior: {what the original evidence shows}
Interpretation / alternative explanation: {hypothesis, uncertainty}
Impact / priority / rationale: {blocked task, friction, consequence}
Recommendation: {change or further research}
Disposition / reason: {fix, investigate, defer, reject}
Action owner / due date / linked ticket: {name, date, link}
Acceptance check / retest method: {observable condition, method}
Retest owner / build / evidence / outcome: {details or pending}
Remaining uncertainty: {what still needs evidence}
CLOSURE
Decision status / approver / date: {record}
Open actions / owners / next review: {record}
Evidence access and retention owner: {name, policy}
Do not combine participants, agent runs, QA assertions, or analytics events into a single denominator. Even within one method, separate tasks and record assistance and retries. Keep setup failures visible as missing coverage rather than quietly dropping them to improve the result. A repeated attempt is not a newly recruited participant.
Worked example: hypothetical synthetic evidence
This example is invented to demonstrate reporting. It is not a Swarm run, customer result, or measured conversion outcome. All IDs and proposed outcomes below are illustrative.
The team is deciding whether to release a changed delivery-address form. Task T1 is to save a valid test address, reload the page, and confirm that the stored address matches the input. The report owner is the product lead; the engineering lead approves release.
The executive recommendation is to hold the affected release until the persistence defect is fixed. The release approver accepts that recommendation based on S1 and Q1. The excluded login failure remains an open coverage action owned by the test lead. The report does not add Q1 to the synthetic denominator or count missing human research as a failed task.
Finding F1 links the failing S1 trace and Q1 readback. Its disposition is "fix before release," owned by the form engineer. The acceptance check requires the corrected address to survive reload and match the independently read stored value. The QA owner must repeat the failing fixture and the other attempted cases on build B before the next release review. Retest status remains pending; a planned check is not a pass.
A separate claim that people will distrust the confirmation is a hypothesis. Its disposition is "investigate with participants," owned by the researcher. That action can remain open even after the persistence fix passes. See AI versus human usability testing for choosing the follow-up method.
How do you close a usability report?
Close a finding only after its recorded acceptance check has evidence and a reviewer. Close the release decision separately, with an approver, date, and accepted residual risks. A passing retest supports the tested conditions; it does not establish population-wide usability or erase missing coverage.
Add a bounded Swarm check
Prepare a reachable test flow with disposable data, then create a Swarm account to run a bounded browser task. Review its browser evidence and add it as a labeled synthetic input to this report. Check current pricing and account access before relying on authenticated testing or developer integrations.
Sources
[2] https://www.dhs.gov/cx/learning-trainings/cx-learning/usability-testing-topics/reporting-on-usability-testing - Department of Homeland Security: Reporting on Usability Testing [36] https://www.nngroup.com/articles/synthetic-users - Nielsen Norman Group: Synthetic Users