SayCraft

← Blog

Usability Test Report Example and Reusable Template

By SayCraft Team · 2026-09-08 · 4 min read

A usability test report should state the research questions, participant and method context, product version, tasks, evidence, findings, severity rationale, limitations, and recommended actions. Report what participants did before explaining why it may have happened. Avoid presenting a small qualitative sample as population statistics; use task results and quotes as evidence for design decisions, then validate changes in another round.

Community signal: Researchers are often asked for a report example when stakeholders actually need a defensible bridge from session evidence to a product decision. Separating observation, finding, consequence, and recommendation makes that bridge reviewable and reduces overclaiming from a small study.

Reusable usability test report template

Write the report soon after the sessions while observations are fresh. Protect participant identity and follow the consent terms for notes, recordings, screenshots, and quotes. Name the prototype or build tested so future readers do not apply an old finding to a different interface.

Lead with the most decision-relevant findings rather than a diary of every session. Keep raw notes and recordings in the controlled research repository and link only the evidence the audience is authorized to view.

  • Study header: product version, dates, researcher, decision owner, and consent boundary
  • Research questions: what the team needed to learn and why now
  • Participants: recruitment criteria, relevant characteristics, and important exclusions
  • Method: moderated or unmoderated format, location, devices, session length, and recording
  • Tasks: believable goals given to participants without revealing the answer
  • Results: completion, abandonment, confidence, time, and notable paths where appropriate
  • Findings: observation, evidence, affected task, consequence, severity, and confidence
  • Recommendations: proposed response, owner, priority, and question for the next test
  • Limitations: sample, environment, prototype fidelity, facilitation, and missing segments
  • Appendix: script, task wording, evidence index, and change log

Illustrative completed example for a clinic booking prototype

In this fictional example, the research question is: Can first-time clinic receptionists reschedule an appointment and understand whether the patient will receive an updated reminder? Five receptionists who regularly manage bookings complete a remote moderated session using prototype build 18 on their own laptops. The team tests rescheduling, canceling, and correcting a phone number.

Finding: participants changed the appointment time but did not notice that the reminder retained its old send time. Evidence: several participants finished the task, returned to the schedule, and expressed surprise when the moderator asked when the reminder would be sent. A real report should link the timestamped recordings and note that the task wording did not mention reminders.

Consequence: staff may believe the change is complete while a patient receives a confusing message. Severity: high for the tested journey because the interface presents a successful appointment update without requiring confirmation of the dependent reminder. Recommendation: place appointment and reminder changes in one review step, state the resulting send time, and retest with the same goal-oriented task.

Limitation: this study involved experienced receptionists and a prototype with simulated messaging. It cannot estimate the population failure rate or prove the production notification integration works.

Separate observation, finding, and recommendation

An observation records visible behavior or a participant statement: the participant opened the schedule twice before selecting a clinic. A finding summarizes the pattern and its consequence: the clinic switcher is hard to locate during cross-clinic booking. A recommendation proposes a response: place the current clinic beside the page title and test a visible switcher.

This separation helps a team challenge interpretation without discarding evidence. It also prevents a preferred redesign from being written as though participants requested it. When evidence is mixed, state the uncertainty and the next research question.

  • Use exact task and interface context for every material observation
  • Include contrary evidence rather than selecting only supporting moments
  • Explain severity through user consequence and journey importance
  • Avoid universal language when the study sampled a narrow participant group
  • Retest the changed design instead of treating a recommendation as validated

Use metrics carefully in qualitative research

Task completion, time, abandonment, confidence, and perceived difficulty can help compare tasks or repeated benchmark rounds when the method is stable. With a small qualitative study, those numbers describe the observed sessions; they do not become reliable population estimates merely because they are shown as percentages.

Combine counts with the reasons visible in paths, recordings, notes, and participant explanations. Preserve consistent tasks when benchmarking over time, and document design or recruitment changes that affect comparison.

Keep the tested prototype and conversation connected

SayCraft creates a running web-app preview from a live product conversation and keeps a meeting replay. A research team can use that preview as the named prototype, then connect a finding to the product decision and screen state that produced it.

Confirm the preview version at the start of each session and avoid changing it midway unless the study design calls for that comparison. After the team revises the product in a later meeting, run another usability round; the replay documents the decision, but only new participant evidence validates the change.

Sources and discussion

Community posts describe individual experiences and questions; they are not treated as universal proof.

Related resources

Build the next step with SayCraft

Use a SayCraft working preview as the clearly identified test artifact, preserve the meeting replay as product context, and fill this report with evidence from real participant sessions.

Start building live →