Interpreting Error Analysis

Error analysis is one of the most diagnostic activities in usability evaluation. When a user makes an error during a test session, the raw observation — "the participant clicked the wrong button" or "the user submitted the form without filling in a required field" — is only the starting point. The real work begins when you ask what that error reveals about the design itself. Interpreting error analysis means moving systematically from a catalogue of observed failures to a clear understanding of why those failures happened and which design decisions caused them. This process involves classifying errors by their type, tracing each error back to its root cause, mapping errors spatially across the interface, and assigning severity ratings so the team knows which problems demand immediate attention and which can wait. Done rigorously, error analysis transforms raw observation notes into an actionable design diagnosis.

Classifying Error Types

Not all errors are alike, and treating them as interchangeable leads to vague, unhelpful recommendations like "make it clearer." Classifying errors by type immediately points the analyst toward the category of design problem most likely responsible. The four major error types relevant to interface evaluation are slips, mistakes, navigation errors, and input errors.

Slips are execution errors. They occur when a user knows what they intend to do but their physical or automatic behavior diverges from that intention. Classic examples include clicking a button adjacent to the intended target, double-clicking when a single click was required, or dragging a file to the wrong folder because the drop zone was ambiguous. Slips are not failures of understanding — the user's mental model was correct — they are failures of execution, often triggered by poor affordance design. An affordance is the perceived property of an object that signals how it should be used. When affordances are weak or misleading, even experienced users misfire. For example, if two buttons — "Save Draft" and "Delete Entry" — are positioned side by side in the same visual style, a user who intends to save will sometimes delete instead. The slip exposes a design flaw in visual hierarchy and spatial separation, not a knowledge gap in the user. When you observe a high frequency of slips on a particular element, the diagnostic question is: does this element's appearance, size, position, and labeling make its correct interaction unambiguous?

Mistakes are knowledge-based errors. They occur when a user's mental model of how the system works is incorrect, and the action they take is the logical consequence of that incorrect model. If a user believes that clicking "Archive" will delete a message permanently, they will avoid archiving anything and instead develop workarounds — that is a mistake rooted in misunderstanding. Mistakes are more serious than slips because they are systematic: the user will repeat the same wrong behavior every time they encounter the same situation until their mental model is corrected. The interface bears responsibility for mistakes when it fails to communicate system behavior clearly. Misleading labels, absent confirmation messages, and opaque status indicators all contribute to mistaken mental models. When diagnosing a mistake, the key question is: what does the interface communicate about this interaction, and how does that communication diverge from the system's actual behavior?

Navigation errors occur when users cannot find their way through the interface — they land on the wrong page, retrace their steps repeatedly, or abandon a path because they cannot determine where it leads. These errors are direct indicators of problems with information architecture, labeling of navigation elements, and wayfinding cues such as breadcrumbs, progress indicators, and visual landmarks. A user who clicks "Settings" looking for notification preferences but instead finds account billing information has encountered a navigation error caused by a mismatch between the label's implied meaning and the content it contains. Navigation errors often appear in sessions as repeated back-button usage, prolonged hesitation at menu items, or explicit expressions of disorientation like "I'm not sure where I am." The analytical task is to identify whether the error stems from poor labeling, a non-intuitive hierarchy, or the absence of contextual cues that orient the user within the overall structure.

Input errors arise when users enter data incorrectly into forms or fields. These errors indicate that the interface has failed to provide sufficient guidance about what is expected. Common causes include field labels that are ambiguous or overly technical, format requirements that are unstated (for example, a date field that silently requires MM/DD/YYYY but accepts no other format), and validation feedback that is either absent or delivered too late in the process. An input error observed during a test — where a participant types a phone number with spaces and receives a generic "invalid entry" message without explanation — reveals at minimum two design failures: the field gave no format hint upfront, and the error message did not tell the user how to correct the entry. Input errors are particularly costly because they interrupt flow, increase cognitive load, and often result in users abandoning forms entirely. Classifying an error as an input error immediately focuses remediation on label clarity, inline guidance, and real-time or contextual validation feedback.

The practical value of this classification scheme is that each category maps onto a distinct family of design fixes. Slips call for affordance improvements and spatial redesign. Mistakes call for better system feedback and clearer mental-model communication. Navigation errors call for information architecture revision. Input errors call for improved labeling and validation design. Misclassifying an error leads the team toward the wrong category of solution.

Root Cause Analysis

Classification tells you what kind of error occurred. Root cause analysis tells you why it occurred at the level of a specific design decision or missing design element. The distinction matters enormously. Knowing that users made a navigation error on the checkout flow is a symptom. Knowing that the error occurred because the "Continue" button label does not distinguish between saving progress and proceeding to payment — and that this ambiguity arose because the design team never specified secondary button states — is a root cause. Only root causes yield actionable recommendations.

The most effective technique for reaching root causes is iterative questioning, often called the "five whys" method. For each observed error, the analyst asks "Why did this happen?" and then applies the same question to each successive answer until a fundamental design decision or omission is identified. Consider this sequence applied to a navigation error:

• Observation: The participant could not find the "Reports" section and spent four minutes navigating before giving up.
• Why? Because the participant looked in "Analytics" but "Reports" was listed under "Insights."
• Why? Because the label "Insights" does not clearly signal that it contains downloadable reports.
• Why? Because the label was chosen for its marketing tone rather than its descriptive accuracy during a rebrand.
• Why? Because there was no usability review of the navigation labels after the rebrand.
• Root cause: The information architecture review process did not include user-centered label testing, and marketing-driven terminology replaced functional descriptors without validation.

This process prevents the common trap of treating symptoms. A symptom-level recommendation would be "rename the Insights section." A root-cause recommendation addresses both the immediate label problem and the process gap that allowed it to arise. The latter prevents the same class of error from appearing elsewhere in the interface or in future redesign cycles.

Root causes in interface design tend to cluster into recurring categories that analysts can learn to recognize quickly. Unclear labeling — where words or icons do not match users' vocabulary or expectations — is one of the most frequent. Hidden affordances — where interactive elements do not visually signal their interactivity — account for a large proportion of slips and navigation errors. Missing or delayed feedback — where the system does not confirm that an action was received or completed — underlies many mistakes and contributes to input errors. Inconsistent interaction patterns — where similar tasks require different approaches in different parts of the interface — force users to relearn and create conditions for both slips and mistakes. Overloaded or ambiguous conceptual models — where the system's organizational logic does not match how users naturally think about the task domain — produce systematic navigation and mistake errors.

When multiple errors across different sessions and different users trace back to the same root cause, this convergence is strong evidence of a fundamental design problem rather than an isolated incident. Documenting root causes in a structured format — linking each error instance to the specific design element implicated and the category of root cause — enables the team to see these convergence patterns and prioritize fixes that will eliminate entire clusters of errors simultaneously.

Mapping Errors to Interface Elements

Root cause analysis works at the level of individual errors. Error mapping works at the level of the whole interface. By plotting where errors occur — which screens, which components, which steps in a task flow — the analyst can identify hotspots: areas of the interface that concentrate a disproportionate number of failures. This spatial perspective reveals patterns that are invisible when errors are reviewed one at a time in a linear log.

An error map can take several forms depending on the nature of the interface and the data available. For web or application interfaces, a common approach is to overlay error counts or icons on annotated screenshots or wireframes. Each error instance is marked at the specific element that triggered it, and color coding or symbol size can encode the error type and frequency. Heat maps generated from click-tracking tools can complement observational data by showing aggregate interaction patterns across many sessions. For multi-screen flows, a flow diagram annotated with error counts at each transition point reveals where users consistently falter moving from one step to the next.

The analytical value of error maps becomes apparent when you step back and look at the distribution. A sparse, widely distributed pattern of single errors suggests that usability problems are isolated and varied — likely the result of multiple independent design decisions that each need individual attention. A dense cluster of errors around a single screen or component tells a very different story: it suggests that something structurally wrong is located there, something that affects nearly every user regardless of their background or task approach. High error density around a single element is one of the clearest signals that a fundamental design flaw is present — not merely a labeling tweak or visual adjustment is needed, but a reconceptualization of that element's design, placement, or role in the workflow.

Error maps are particularly valuable for communicating findings to team members and stakeholders who did not observe the test sessions. A written list of errors requires readers to hold all the items in memory and construct their own spatial understanding of the problem. An error map makes the concentration of problems immediately visible, even to someone encountering the findings for the first time. This communicative efficiency makes error maps a standard deliverable in usability reports intended for cross-functional audiences including product managers, engineers, and executives.

Critically, error maps should be maintained as living documents updated after each redesign iteration. After a round of design changes is implemented and a follow-up usability test is conducted, the new error map can be compared directly against the previous version. This comparison reveals whether the redesign successfully reduced errors at the targeted hotspots, whether it introduced new errors elsewhere — a phenomenon called regression — and whether the overall error density across the interface is trending in the right direction. Without this iterative tracking, it is impossible to know whether the design is genuinely improving in usability or simply shifting problems from one location to another.

Distinguishing Critical from Minor Errors

Not every error demands the same response. A usability improvement backlog that treats all errors as equally urgent will be impossible to act on rationally, because resources are always limited and some problems genuinely matter more than others. The discipline of distinguishing critical from minor errors — and applying consistent severity ratings across all issues — enables objective, data-driven prioritization rather than decisions based on which problems happen to be most memorable or most recently observed.

Critical errors are those that prevent task completion. If a user encounters this error, they cannot finish the task — not merely with difficulty, but at all. A form that cannot be submitted because a required field rejects all valid inputs is a critical error. A modal dialog that cannot be dismissed because the close button is outside the visible viewport on certain screen sizes is a critical error. These failures are sometimes called "showstoppers" because, by definition, they make it impossible for the user to accomplish their goal. Critical errors must be addressed before the next usability test iteration, because their presence in subsequent testing will block the collection of meaningful data about downstream interactions and obscure other problems that exist further in the flow.

Minor errors are those that reduce efficiency or user satisfaction but do not prevent goal achievement. A user who clicks the wrong tab first and then self-corrects has made a minor error. The task was completed, but with extra steps and perhaps some frustration. A user who misreads a label, pauses, and then interprets it correctly through context has made a minor error. These issues still deserve attention because accumulated minor errors degrade the overall user experience and can drive dissatisfaction, abandonment in naturalistic use, and poor perception of product quality — but they do not warrant the same emergency priority as showstoppers.

Severity ratings formalize this distinction and add granularity. Most severity scales used in industry and research combine two dimensions: frequency (how often does this error occur across users and sessions?) and consequence (when it does occur, how serious is the impact?). An error that occurs rarely and has minor consequences receives a low severity rating. An error that occurs frequently and prevents task completion receives the highest severity rating. An error that occurs rarely but is catastrophic when it does occur — such as an accidental data deletion with no undo — warrants a high severity rating despite its low frequency, because the consequence dimension dominates.

A commonly used framework for severity rating combines these dimensions into a structured scale. The table below illustrates how frequency and consequence interact to produce severity levels:

Applying a consistent severity scale across all identified issues is essential for objectivity. When each issue is rated by the same criteria, the prioritized backlog reflects the actual distribution of risk in the interface rather than the subjective emphasis placed on particular findings by individual analysts or stakeholders. It also enables meaningful communication across disciplines: a developer who sees "Severity 4" knows immediately that this issue must be resolved before the next test, without requiring extensive context from the usability team. And it creates a comparable baseline across testing rounds — if the proportion of Severity 4 issues declines from one round to the next, that is measurable evidence of usability improvement at the most consequential level of the interface.

Together, error classification, root cause analysis, error mapping, and severity rating form an integrated analytical framework. Each technique builds on the others: you classify to understand the nature of the error, apply root cause analysis to understand its origin, map it to understand its location and prevalence, and rate its severity to understand its priority. The output of this integrated process is not merely a list of problems but a structured, evidence-based diagnosis of the interface — one that tells the design team not only what is broken, but where, why, and in what order to fix it.

When a usability test session ends, you are left with a pile of observations: a participant clicked the wrong button, backtracked three screens, typed a date in the wrong format, or quietly gave up. Error analysis is the discipline of turning those raw observations into a diagnosis. Instead of reporting "the user got confused," you classify what kind of error occurred (a slip, a mistake, a mode error, a data-entry error), trace it back to a root cause, and name the specific interface element — a label, an affordance, a layout, a feedback message — that produced it.

This matters in CEN3722 because redesign decisions are only as good as the diagnosis behind them. Two errors that look identical on a screen recording can have completely different causes: one may be a momentary slip by an otherwise capable user, while the other reveals a fundamental mismatch between the user's mental model and the system's conceptual model. Those two findings call for very different fixes. You also need a defensible way to separate critical errors (data loss, task failure, security or safety consequences) from minor ones (a brief hesitation, an easily recovered misclick), because you will never have time to fix everything.

The videos below approach this from three angles: the metrics you use to quantify errors and task performance, the research methods that generate error data in the first place, and a research-level look at how touch-based errors are captured and investigated on real devices. As you watch, keep asking three questions: How would I count and record this kind of error? What would I need to observe to infer its cause rather than just its symptom? And how would I decide whether this error is worth a redesign cycle?

Eleken · 9:51 · 5,725 views · 2y ago · captions — Watch on YouTube

About this video

This video from the Eleken design agency walks through six commonly used UX metrics and explains what each one measures and when to apply it. Based on its title and description, expect coverage of performance and satisfaction measures such as task success or error rates, time on task, and standardized satisfaction scores, framed around the problem of knowing whether a product actually works for real users rather than just for the team that built it.

Why this video

Error analysis depends on quantification — you cannot judge severity or frequency without metrics — and this video gives you the vocabulary for counting errors and task failures in a consistent, reportable way. It supports the subtopic of distinguishing critical from minor errors by showing how numbers are used to argue that an issue matters.

Kerev Design · 6:18 · 47,165 views · 4y ago · captions — Watch on YouTube

About this video

Kerev Design contrasts user testing with usability testing, two methods that are frequently confused in practice. The video situates both within the broader UX research process and clarifies what question each method is designed to answer — roughly, whether people want the product versus whether people can actually operate it.

Why this video

Correctly interpreting an error requires knowing what the study was designed to reveal, since an error observed in a usability test points at the interface while a problem surfaced in user testing may point at the concept itself. This distinction directly supports root cause analysis and keeps students from attributing the wrong cause to an observed failure.

ACM SIGCHI · 4:47 · 76 views · 2y ago · captions — Watch on YouTube

About this video

This short conference presentation from ACM SIGCHI describes a new data collection approach for investigating touch-based errors, using a smartphone system as its case study. As a research talk it is likely to cover how touch interaction data is instrumented and captured, what kinds of touch errors the method distinguishes, and what the collected data reveals about where and why mistouches occur.

Why this video

It is a peer-reviewed research source from the premier HCI professional organization, and it demonstrates error analysis at the most granular level — mapping specific errors to specific interface elements and target regions on a screen. The case-study format shows students what rigorous, evidence-based error classification looks like beyond informal note-taking.

Together these videos move students from observation to diagnosis to prioritization. The metrics video supplies the measurement vocabulary needed to spot recurring patterns and quantify frequency and severity, supporting MO1 and MO2. The user testing versus usability testing comparison helps students match findings to the right level of cause — concept, task flow, or control — which is essential for the accurate pain-point identification required by MO1 and for writing a defensible rationale behind each proposed change under MO3. The SIGCHI case study models fine-grained mapping of errors to specific interface elements, giving students a concrete example of the evidence trail that justifies a targeted redesign rather than a guess, and reinforcing the severity judgments called for in MO2.

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.