Usability test report: how to link findings to the recording
Document usability test findings with the observation, task context, impact, priority and a way to verify the change. Includes an example issue card and a report template.
The report starts with observations
“The participant didn't like the navigation” does not tell the team what to fix. The recording might show that the person opened the payment section three times looking for returns, then asked for help. That gives the team a reproducible issue in a specific task.
Record the test conditions: interface version, device, scenario, success criterion and moderator assistance. Without them the team may mistake a problem in a prototype for a bug in the live product, or count completion after a hint as independent success.
Turn sessions into findings the team can verify
Mark the important episodes
For each session, mark the start of the task, difficulties, recovery and outcome. Compare the transcript with the screen recording. “I clicked” does not always describe an actual click. Keep timecodes before and after the action so the reader can see the context.
Separate observation from explanation
Record the action and outcome in the observation field. Enter the suspected cause separately. “Looked for returns in Payments” is an observation. “The section label is unclear” is a hypothesis that can be tested with the next interface version.
Compare similar cases
Group episodes only when they show the same issue in comparable tasks. State how many participants encountered the issue and how many attempted the task. Do not extrapolate the share in a small research group to the entire product audience.
Define an action and a check
Assess the impact: the task stopped, required help or took extra steps. Agree on the priority in the context of the product. For the proposed change, specify what observable result in the next test would show whether it helped.
A user looks for a way to return an order
This is a fictional training example. The names, circumstances and outcomes are included solely to explain the method.
It's probably under Payments. No, there's only the card here. Maybe I should contact support? I can't see where to return the order.
A single remark does not show what happened on screen. In this example, the recording shows two visits to Payments and the task stopping until the moderator gave a hint. Put that on the card together with the prototype version.
Adding a link to the order details is a possible change that still needs testing. The next test will check whether the participant can find the action without help and knows which order they are returning.
| Field | Example entry | Why it matters |
|---|---|---|
| Context | Prototype A, returning a paid order | Understand the conditions |
| Evidence | Session U3, 08:15–09:02 | Verify the episode |
| Impact | Continued only after a hint | Assess the effect |
| Next action | Test placing the action in the order details | Schedule a check |
Issue card for a usability report
Write the issue cards first, then summarize the main obstacles. This keeps the conclusions tied to the test material.
Short issue title: Version / device / task: Participant and timecode: Observed action: Impact on the task: Whether the moderator helped: Recurrences in comparable sessions: Suspected cause: Priority and rationale: Proposed change: How we will check the result:
Check that the report supports action
- Important findings can be located in the recording.
- It is clear whether the task was completed independently.
- The cause is presented as a hypothesis.
- The proposal has a criterion for the next test.
A closer look
Do I need a long video for every issue?
No. A precise link or timecode with enough context is sufficient if the team can access the original. A short clip should preserve any hint or change in the task.
Can I include a solution straight away?
Yes, present it as the team's proposal, with a rationale and a way to test it. A participant suggesting a similar button does not prove the solution works.