How to Present a Usability Testing Report

Usability testing produces recordings, notes, and observations. Presenting the results means transforming that raw material into a coherent picture of where users struggle and what needs to change.

The presentation serves one purpose: give the team enough confidence to act on specific design changes. If the meeting ends with "we need more research," the presentation has not done its job.

Structure the Report Around Findings, Not Sessions

The instinct after running five usability sessions is to present them chronologically: "In session one, the user did X. In session two, the user did Y." Resist this. Presenting by session makes it impossible to identify patterns and forces the audience to do synthesis work they shouldn't have to do.

Instead, present by finding. What are the 3–7 distinct usability problems this study revealed? Each finding gets its own section.

Slide Structure

Slide 1: Study Context

• Task scenarios tested
• Number of participants, recruitment criteria
• Test format (moderated/unmoderated, remote/in-person)
• Prototype or production environment tested

One slide, factual. The audience needs to know what was tested before they can interpret results.

Slide 2: Summary of Findings

A numbered list of all findings, ordered by severity. Include a one-sentence description of each. This slide gives stakeholders the scope of the study and lets them orient themselves before the detail slides.

A severity framework helps: Critical (blocks task completion), High (significant friction or confusion), Medium (minor friction, users recover), Low (cosmetic or edge case).

Slides 3–8: Individual Findings

One slide per finding. Each slide contains:

Headline: A specific, observable description of the problem. "Users cannot locate the export function" is a finding. "Export function could be more discoverable" is not.

Observation: What did participants do? How many experienced this problem? "4 of 6 participants navigated to Settings looking for export. None found it without assistance."

Video or screenshot evidence: A 30-second clip or annotated screenshot is worth a page of text. If the testing platform supports it, embed a highlight clip directly.

Severity rating: Critical, High, Medium, or Low, with the criteria for your rating.

Design direction: Not a specific solution, but a direction. "Export needs to be accessible from the primary navigation or prominently surfaced within the data view." Design directions give the team latitude to solve the problem without prescribing implementation.

Slide 9: Task Completion Rates

If you tracked task completion formally, summarize it here. A table showing each task, the completion rate, and average time-on-task gives stakeholders a quantitative complement to the qualitative findings.

Even approximate completion rates ("5 of 6 participants completed this task, 1 required assistance") are more useful than impressionistic descriptions.

Slide 10: What Worked

Usability testing surfaces problems, but it also reveals what's working. Noting which flows users navigated confidently and which interactions generated positive commentary gives design teams direction for what to preserve during redesign work.

Slide 11: Recommendations

Ordered by severity and ease of implementation. Each recommendation should be:

• Specific enough to be actionable ("move export to the primary toolbar" rather than "improve discoverability")
• Tied to a finding ("this addresses finding #2 and #4")
• Estimated for effort (small/medium/large)

Separate quick fixes from design changes that need a full sprint. Quick fixes should go straight to the backlog from this meeting.

Slide 12: Suggested Next Steps

What happens after this presentation? Options: schedule a design iteration on the critical findings, run a follow-up test on a redesigned flow, prioritize the top three findings for the next sprint, or expand the study to a larger sample.

Be specific about who owns what and by when.

Presenting the Findings Live

Show clips. A 30-second recording of a participant struggling with a flow is more persuasive than any description. If you have clips, use them. Stakeholders who see a real user fail at a task are far more likely to prioritize the fix.

Defend the finding, not the solution. Your job in this presentation is to present what users did and experienced, not to advocate for a specific design fix. When stakeholders propose solutions, note them, but keep the discussion focused on understanding the problem before jumping to solutions.

Don't overgeneralize from small samples. Usability studies with 5–8 participants are standard and appropriate for directional insight — but they're not statistically representative. When presenting findings, say "4 of 6 participants," not "most users" or "users typically."

What to Leave Out of the Presentation

Everything that doesn't directly support a finding should go in the appendix. Full session transcripts, background on test methodology, demographic breakdowns that don't affect interpretation — these are reference material, not presentation content. Link to them. Don't show them.