Slips vs Mistakes: How to Classify User Errors in Usability Testing (2026)

A slip is an error where the user had the right goal and executed the wrong action. A mistake is an error where the user executed their plan perfectly and the plan was wrong. The two look identical on a session recording -- the same wrong click, the same failed task -- and they need opposite fixes. Slips are fixed by changing the interface (make different things look different, remove modes, break shared action prefixes). Mistakes are fixed by changing the model the interface teaches (labels, structure, feedback, onboarding). A usability report that counts errors without classifying them hands the team a number that cannot tell them which fix to build.

This guide covers the three-way taxonomy that human-error research settled decades ago, how to classify an error you observed, and why the classification can only be made by asking the participant a question -- which is where most usability studies quietly skip a step.

Where the taxonomy comes from

Three bodies of work converge here, and it helps to know which one you are borrowing from.

Norman's action slips (1981)

Donald Norman's paper Categorization of action slips (Psychological Review, 88(1), 1-15) defined a slip as an action that was not intended. His model has intentions activating schemas, which are then triggered by conditions in the world. Errors can enter at each step: in forming the intention (mode errors and description errors), in activating the schema (capture errors, data-driven actions, loss of intention), and in triggering it (blends, premature triggering). For interface work this is the most directly useful source, because every category names a design property.

Rasmussen's skill, rule and knowledge levels

Jens Rasmussen's framework sorts behaviour by how much conscious control it needs. Skill-based behaviour runs on autopilot -- typing a password, hitting save. Rule-based behaviour applies a stored if this, then that pattern -- if the export is greyed out, I need to select rows first. Knowledge-based behaviour is reasoning from first principles in an unfamiliar situation. Each level fails in its own way, and that matters because different users operate at different levels on the same screen.

Reason's slips, lapses and mistakes (1990)

James Reason's Human Error joined the two. Execution failures are slips (an observable action goes wrong, usually attentional) and lapses (a memory failure -- the step that was forgotten). Planning failures are mistakes, which Reason defined as failures in the judgmental or inferential processes involved in selecting an objective or the means to achieve it. Skill-based errors are slips and lapses; mistakes split into rule-based (a good rule misapplied, or a bad rule) and knowledge-based (reasoning from a wrong model).

The classification in one table

The right-hand column is the whole reason to classify. A description slip fixed with better onboarding stays broken. A knowledge-based mistake fixed with a bigger button stays broken.

Why the recording cannot classify the error

Here is the part that most usability protocols skip. The category lives in the participant's intention, and the intention is not on the screen.

Take a single observed event: the participant clicks Archive on a project they still need. That click is:

• a description slip if they meant to click Duplicate next to it and hit the wrong one,
• a capture slip if they archive dozens of projects every Friday and did it on autopilot,
• a rule-based mistake if they believed archive means hide from my list and assumed it was harmless,
• a knowledge-based mistake if they thought archiving was how you share a finished project.

Four categories, four different fixes, one identical click. The only instrument that separates them is a question: what were you trying to do just then, and what did you expect to happen? Error rate is the metric; the intention is the classification. A study that records the first and never collects the second produces a severity list the design team cannot act on.

The two questions that classify almost anything

1. Did the action match what you meant to do? If no, it is a slip (or, if a step is missing, a lapse). If yes, keep going.
2. Did what you meant to do match what the product required? If no, it is a mistake -- and the follow-up is why did you think that would work?, which tells you whether the participant applied a rule from somewhere else or reasoned from a wrong model.

Ask them as soon after the event as you can. Retrospective accounts drift toward rationalized plans, which makes slips look like mistakes after the fact -- people rarely remember acting on autopilot, because that is what autopilot means.

The expertise inversion: your best users make the slips

This is the least intuitive consequence of the taxonomy, and it changes who you recruit.

Mistakes are the errors of people who do not yet have the right rules or model -- novices. Slips and lapses are the errors of people whose behaviour has become automatic -- experts. A capture error requires a habit: nobody is captured by a sequence they have not practised hundreds of times.

Most usability tests recruit participants who are new to the flow, because that is the easiest condition to set up and the one that feels most rigorous. The consequence is structural: a first-session usability test cannot surface capture errors at all, because the habit that produces them does not exist yet. The test is not bad at finding slips; it is incapable of it. The error type that hurts your most valuable, most habituated customers is the one your standard protocol is guaranteed to miss.

The power users will be fine assumption therefore inverts. Power users are fine on mistakes and exposed on slips, especially on destructive actions that sit next to frequent ones. If you want to find slips, you need:

• participants who already use the product daily,
• tasks embedded in their real routine rather than scripted fresh,
• time-based or diary methods that catch errors when attention is elsewhere -- the condition under which slips happen.

Classifying errors across a study

Once each error has a type, the aggregate becomes readable in a way that a raw error rate never is.

Same error rate, opposite diagnosis

Imagine two onboarding studies that both report a 30% task-failure rate on create your first project. In the first, 9 of 10 failures are description slips between two adjacent icons. In the second, 9 of 10 are knowledge-based mistakes: participants think a project is a single document rather than a container. The first team needs a visual change in an afternoon. The second needs to rethink the information architecture. Reported as 30% failure, the two studies look like the same problem.

Weight severity by type

Severity scales normally combine frequency, impact and persistence. Type adds a fourth dimension: persistence differs by category. A mistake tends to self-correct once the participant learns the model -- the same person rarely makes it twice. A slip can recur indefinitely, because it is produced by the habit that learning creates. A low-frequency capture slip on an irreversible action can outrank a high-frequency novice mistake on a reversible one.

Watch for mistakes that masquerade as slips

Participants often narrate a mistake as a slip -- oops, I clicked the wrong thing -- because it is less embarrassing to have a clumsy finger than a wrong idea. If the wrong thing was the thing their stated plan pointed at, it was not a slip. Code the plan, not the apology.

Common mistakes when classifying user errors

• Counting without classifying. An error count with no type is a thermometer with no diagnosis.
• Classifying from the recording alone. You are guessing the intention. Ask.
• Treating all errors as design failures of the same kind. A description slip and a wrong mental model share nothing but the word error.
• Testing only novices. You will find mistakes, and structurally cannot find capture slips.
• Letting the participant's word choice decide. I misclicked is a claim about the error, not a classification of it.
• Fixing mistakes with forcing functions. A confirmation dialog stops a slip; it does nothing for someone who is confidently doing the wrong thing, and who will simply click Yes.

How Koji fits into error classification

The missing step -- asking what the participant intended -- is the step that takes moderator time, so it is the step that gets dropped when a study has 30 sessions instead of 5. That is the part an AI interviewer can carry.

• A post-task intention debrief at scale. Koji runs voice or text interviews without a moderator, and its AI follow-up questions can ask what were you trying to do? and what did you expect to happen? after every task, for every participant, in the same wording.
• Structured classification questions. Koji's structured questions support six types -- open_ended, scale, single_choice, multiple_choice, ranking and yes_no. A yes_no question (did the result match what you meant to do?) followed by an open_ended why did you expect that? is the two-question classifier from above, built into the guide.
• Recruiting the habituated users slips require. Because Koji interviews run asynchronously, you can reach daily users in the middle of their real routine rather than scheduling them into a lab session that resets their habits.
• Automatic analysis across the corpus. Koji's auto-analysis groups open-ended answers into themes with supporting quotes, so thought archive was reversible and thought a project was one document surface as distinct clusters rather than one undifferentiated error count.
• Credit-efficient debriefs. Koji's quality gate means only conversations that score 3 or higher consume credits, so a batch of short debriefs where half the participants had nothing to report does not cost you the full run.

Traditional survey tools like SurveyMonkey or Typeform can ask did you have trouble with this step?, but they cannot follow a yes with what did you expect to happen? and then probe the answer. That follow-up is where the classification lives. With Koji, the follow-up is the default rather than a moderator luxury.

Frequently asked questions

What is the difference between a slip and a mistake in UX?

A slip is when the user had the right intention and performed the wrong action, such as clicking the wrong one of two similar buttons. A mistake is when the user performed exactly the action they intended and the intention itself was wrong, because their model of the product was wrong. Slips are fixed by changing the interface; mistakes are fixed by changing the model the interface teaches.

What is a lapse?

A lapse is a memory failure during execution -- a step that was forgotten, like configuring a campaign and never activating it. Reason grouped lapses with slips as execution failures. The fix is usually a forcing function or a visible incomplete state, so the forgotten step cannot stay invisible.

How do you tell a slip from a mistake in a usability test?

Ask the participant what they were trying to do and what they expected to happen, as close to the event as possible. If the action did not match their intention, it was a slip. If it matched and the intention was wrong, it was a mistake. The recording alone cannot tell you, because the category depends on intention. With Koji, the AI interviewer asks both questions after every task automatically.

What is Rasmussen's skill, rule and knowledge model?

It sorts behaviour by how much conscious control it needs: skill-based behaviour is automatic, rule-based behaviour applies stored if-then patterns, and knowledge-based behaviour reasons through an unfamiliar situation. Skill-based failures are slips and lapses; rule-based and knowledge-based failures are mistakes.

Why do experienced users make more slips?

Because slips are produced by automatic behaviour, and automatic behaviour comes from practice. A capture error needs a habit strong enough to take over, which only a frequent user has. This is why a first-session usability test with new participants cannot find capture errors, and why you should also test with daily users.

Does a confirmation dialog fix user errors?

It helps with slips, because it interrupts an automatic action and gives attention a chance to catch up. It does nothing for mistakes: a user who confidently believes the action is right will read the dialog, agree with it, and confirm. Using confirmation dialogs as the universal fix is a sign that errors were counted but never classified. Koji's post-task debriefs are one way to find out which kind you are dealing with before you build the fix.

Related Resources

• Structured questions in AI interviews -- the six question types, including the yes_no plus open_ended pair that classifies an error.
• Usability metrics guide -- where error rate sits among the other task metrics.
• Usability issue severity ratings -- adding error type as a severity dimension.
• Poka-yoke for research -- forcing functions and why they only work on some errors.
• Think-aloud protocol -- capturing intention while the task is still running.
• Automation surprise in research operations -- mode errors when the system, not the user, changed state.