What to include in a usability test report

A usability test report turns observations from research sessions into evidence that a product team can act on. It should explain what was tested, who participated, what happened during each task, and which findings deserve attention first. A clear report helps designers, developers, product owners and stakeholders make decisions without having to replay every session.

The best reports balance detail with readability. They preserve enough context to support the findings while avoiding long transcripts, unexplained research jargon or a list of every minor hesitation. Screenshots, quotations, task measures and recordings should support the analysis rather than bury the main message.

For Australian teams, the document may need to reflect different locations, access conditions and customer expectations. A test with participants in Sydney and Melbourne can produce different experiences from one involving regional Queensland users, particularly where mobile coverage, delivery options or digital confidence affect a task.

A well-structured usability test report also creates a useful project record. A collaborative platform such as UCDmanager can help organise research activities, requirements, personas, evaluations and testing evidence in one place, making later design decisions easier to trace.

Define the test purpose and scope

Start by stating the research objectives in plain language. Explain whether the test examined navigation, content comprehension, checkout, account creation, accessibility, a mobile interface or a complete customer journey. Include the product version, prototype link or build number, test dates, locations and any important changes made during the study.

The scope should identify what the sessions could and could not prove. For example, five moderated sessions may reveal serious interaction problems, but they cannot establish market-wide satisfaction or statistical conversion rates. Clarifying this boundary prevents stakeholders from treating qualitative findings as a full performance benchmark.

Describe participants and recruitment

Record the number of participants, relevant demographics, experience levels and recruitment criteria. Include information that directly affected the tasks, such as whether people were existing customers, frequent online shoppers, carers, public-sector users or employees managing devices across a large organisation.

Personas can make these characteristics easier to interpret when they are tied to observed behaviour rather than treated as fictional labels. Teams can review persona profiles alongside participant notes to compare expected needs with what people actually did during testing.

For Australian research, note whether participants came from metropolitan areas such as Sydney, Melbourne, Brisbane or Perth, or from regional and remote communities. Also record device type, internet conditions and accessibility needs. A participant completing a task on a low-cost Android phone over mobile data may encounter very different barriers from someone using a fast home connection on a large monitor.

Explain the method and test conditions

A credible report states whether the study was moderated or unmoderated, remote or in person, exploratory or evaluative. Describe the recruitment process, consent approach, session length, test script, task order and facilitation rules. Mention whether participants were allowed to ask questions, use their own accounts or receive prompts.

Include the environment in which the evidence was collected. Note browsers, operating systems, screen sizes, assistive technologies, prototype limitations and recording arrangements. If participants tested a service during a realistic activity, such as ordering groceries on a smartphone during a public transport commute, explain that context.

For remote research, document technical interruptions and unusual conditions. A failed screen share, an unavailable staging account or a participant joining from a noisy household can affect results. These details help readers judge whether a finding reflects the interface, the research setup or both.

Present tasks, measures and observations

List the tasks in the same order used in the sessions and give each one a clear objective. Include the starting point, success condition and any meaningful constraints. “Find the return policy and identify the time limit” is more useful than “explore the website”.

Quantitative measures can include completion rate, time on task, error count, assistance required, abandonment and confidence ratings. Qualitative observations should explain what participants attempted, where they hesitated and why their behaviour mattered. A direct quotation can add clarity, but it should support a pattern rather than stand in for one.

If the product contains substantial video content, researchers may need to revisit precise evidence quickly. A guide to searching video transcripts can help locate relevant moments in long recordings or demonstrations without relying on vague timestamps.

Turn observations into usability findings

Separate raw observations from interpreted findings. “Four participants opened the filter menu, then closed it without applying a filter” is an observation. “The filtering model is unclear on mobile” is a finding that explains the likely design problem. Showing both gives stakeholders a transparent path from evidence to interpretation.

Group related observations into themes such as navigation, terminology, feedback, form design, trust, accessibility or content clarity. Include the number of participants affected, but avoid implying that frequency alone determines severity. One blocked task may be more damaging than several small annoyances.

For Australian services, consider language and expectations that influence comprehension. Local spelling, delivery areas, suburb and postcode formats, Australian Eastern, Central and Western time zones, and references to Medicare or Australian dollars may all affect whether a journey feels familiar. These details should be recorded when they shape task performance.

Prioritise issues and recommend action

Each issue should have a concise title, description, supporting evidence, impact, severity and recommended direction. Explain whether it prevents task completion, increases error risk, slows progress, reduces confidence or creates an accessibility barrier. Screenshots with annotations can make the problem immediately visible.

Prioritisation should consider user impact, business importance, implementation effort and legal or ethical risk. Accessibility findings may require urgent attention even when they affect a smaller observed group. In Australia, the Disability Discrimination Act 1992 is relevant to digital access, while WCAG conformance provides a practical benchmark for many web projects.

Privacy also belongs in the analysis when sessions involve personal information, account data or recordings. Explain how consent was obtained, how identifying details were removed and who can access the files. The Privacy Act 1988 and Australian Privacy Principles should inform decisions about storing participant data, especially when research tools or suppliers operate overseas.

Close with decisions and traceable evidence

End the report with a short summary of the most important findings, followed by agreed actions, owners and priorities. A recommendation should be specific enough to guide the next design step, such as testing clearer filter labels, adding error recovery or reviewing keyboard focus order. Record open questions that require another study rather than presenting assumptions as resolved facts.

Include appendices for the discussion guide, task script, consent wording, participant screener, detailed metrics, coding notes and selected transcripts. Link each finding to relevant recordings, screenshots or design tickets where appropriate. This keeps the main report readable while preserving an audit trail.

When a product or device programme is being changed, the same principle applies to operational evidence. A practical migration checklist illustrates how documenting dependencies, risks and validation steps supports a controlled transition. A usability report benefits from that same discipline: clear evidence, accountable actions and a record of what was tested.