Articles

Categorising Usability Issues by Severity and Frequency

Usability testing produces valuable observations, but a long list of findings does not automatically show what a team should fix first. A clear classification method helps researchers distinguish a minor inconvenience from a barrier that prevents people from completing an essential task.

Severity describes the impact of an issue when it occurs. Frequency shows how often it appears across participants, sessions, devices or journeys. Considering both measures gives product teams a more balanced view of risk, effort and user benefit.

For Australian organisations, this approach is especially useful when a service must work across Sydney offices, Melbourne households, regional Queensland communities and remote users with slower or less reliable connections. A problem that appears occasionally in a laboratory may become far more important in a wider market.

A shared record also improves communication between UX researchers, designers, developers and product owners. UCDmanager can help organise research findings, usability tests, personas and requirements in one collaborative project, making it easier to trace a reported issue from evidence to resolution.

Separate Impact From Occurrence

Severity is concerned with consequences. A critical defect may stop a person from submitting an application, purchasing a product or accessing essential information. A major issue may cause repeated errors or lead users to abandon a task, while a minor issue creates hesitation, extra effort or confusion without blocking progress.

Frequency is a separate measurement. If six of ten participants encounter an issue, its observed frequency is 60 per cent. A problem seen once may still deserve urgent treatment if it affects a high-value task, creates a privacy risk or prevents a user with a disability from proceeding.

Teams should record both the raw count and the context. “Three participants struggled” is more useful when accompanied by the task, device, user group, location and outcome. This distinction prevents frequent cosmetic complaints from automatically outranking rare but serious failures.

Use A Consistent Severity Scale

A four-level scale is often enough for practical decision-making. Critical issues block completion, cause data loss, create a serious accessibility barrier or expose users to significant harm. High-severity problems require workarounds and substantially reduce task success. Medium issues slow people down or cause uncertainty, while low-severity issues involve wording, layout or visual polish.

The scale should be defined before reviewing the findings. Otherwise, the loudest opinion in a workshop can determine the rating. Evidence should lead the decision: task failure rates, observed workarounds, participant comments, accessibility checks and support records all provide useful signals.

For example, an Australian government service that hides an eligibility requirement may create a high-severity problem, while an unclear date format could become critical if it causes applicants to enter an incorrect deadline. Local conventions, including day-month-year dates and Australian English terminology, should be considered during evaluation.

Combine Severity And Frequency

A simple matrix makes prioritisation visible. High-severity, high-frequency issues usually receive immediate attention because they affect many people and cause substantial harm. High-severity, low-frequency findings still require careful review, especially when they concern security, legal compliance, accessibility or essential services.

Low-severity, high-frequency issues can have a significant cumulative cost. A confusing navigation label encountered on every page may waste thousands of minutes across a large customer base. Conversely, a low-severity issue observed once may be recorded for later design refinement rather than placed in the next development sprint.

The matrix should support judgement rather than replace it. A satellite dish tracking interface, for instance, may use specialist concepts that users do not understand; reviewing orbital inclination effects could help a researcher decide whether terminology confusion is an occasional annoyance or a task-blocking problem.

Account For User Groups And Context

A frequency percentage can hide important differences between groups. An issue affecting two participants may represent a serious pattern if both are screen-reader users, older people or customers accessing a service on mobile devices. Segment results by relevant characteristics instead of relying solely on an overall average.

Context matters in Australia’s varied geography and infrastructure. A checkout flow that works well on fast NBN connections in inner Melbourne may perform poorly for a regional user relying on mobile data. Testing across Android and iPhone devices, small screens and realistic network conditions can reveal issues that a desktop session misses.

Cultural and language context should also be documented respectfully. Terminology, form fields and identity options may affect Aboriginal and Torres Strait Islander users, migrants and people using English as an additional language in different ways. A finding should explain the observed barrier without making unsupported assumptions about a whole group.

Track Patterns Over Time

A severity rating can change as evidence accumulates. A problem first seen in one moderated session may become more important after analytics, support tickets or a second round of testing confirms it. Teams should preserve the original observation while updating confidence, frequency and business impact.

Longitudinal tracking is particularly valuable after a release. Comparing issue rates across research rounds can show whether a redesign reduced errors or merely shifted them to another step. Guidance on tracking test results can support this type of ongoing measurement.

Each finding should have a clear status, owner, decision and follow-up date. This prevents “fixed” from meaning only that a developer changed the interface; the team should verify that users can now complete the task more successfully.

Turn Findings Into Action

A useful issue record connects the problem to evidence and a practical response. Include a concise title, affected task, participant quote or observation, severity, frequency, affected segment, proposed direction and validation method. For document-heavy workflows, access problems can be especially consequential; a secured PDF process may need separate investigation, such as understanding third-party PDF protection before judging the user experience.

Collaborative review works best when researchers and delivery teams agree on rating definitions. In UCDmanager, project documentation can keep the rationale beside the finding rather than scattering decisions across emails and spreadsheets. Teams needing product or account information can use the UCDmanager contact page as part of that collaboration.

Practical Prioritisation Rules