{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-09-22T10:57:18.304Z"},"content":[{"type":"documentation","id":"c5c1b4e8-4ec6-4605-8884-6777a18872f6","slug":"slips-vs-mistakes-usability-errors","title":"Slips vs Mistakes: How to Classify User Errors in Usability Testing (2026)","url":"https://www.koji.so/docs/slips-vs-mistakes-usability-errors","summary":"A slip is the right goal executed wrongly; a mistake is a wrong plan executed correctly. They look identical on a session recording and need opposite fixes: slips need interface changes, mistakes need a different mental model. Classification requires asking the participant what they intended. Because slips come from habit, first-session tests with novices cannot surface capture errors, so test with daily users too.","content":"**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.\n\nThis 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.\n\n## Where the taxonomy comes from\n\nThree bodies of work converge here, and it helps to know which one you are borrowing from.\n\n### Norman's action slips (1981)\n\nDonald 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.\n\n### Rasmussen's skill, rule and knowledge levels\n\nJens 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.\n\n### Reason's slips, lapses and mistakes (1990)\n\nJames 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).\n\n## The classification in one table\n\n| Error type | Level | What failed | Example in a product | Fix direction |\n|---|---|---|---|---|\n| Capture slip | Skill | A familiar sequence took over | User meant *Save as draft* and hit *Publish*, which starts the same way | Break shared prefixes between frequent and rare actions |\n| Description slip | Skill | Two targets too similar | Deleted the wrong one of two identical-looking rows | Make different things look different |\n| Mode error | Skill | Same action means different things in different states | Typed a search query into the filter box | Remove the mode, or make it loud |\n| Lapse | Skill | A step was forgotten | Set up the campaign and never activated it | Forcing function, reminder, visible incomplete state |\n| Rule-based mistake | Rule | A sensible rule applied where it does not fit | Assumed *Archive* works like email archive and is recoverable | Match conventions, or explicitly break them with feedback |\n| Knowledge-based mistake | Knowledge | Wrong mental model | Believed *Workspaces* were folders, and moved clients into one to organize them | Change the model the interface teaches |\n\nThe 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.\n\n## Why the recording cannot classify the error\n\nHere is the part that most usability protocols skip. **The category lives in the participant's intention, and the intention is not on the screen.**\n\nTake a single observed event: the participant clicks *Archive* on a project they still need. That click is:\n\n- a **description slip** if they meant to click *Duplicate* next to it and hit the wrong one,\n- a **capture slip** if they archive dozens of projects every Friday and did it on autopilot,\n- a **rule-based mistake** if they believed archive means *hide from my list* and assumed it was harmless,\n- a **knowledge-based mistake** if they thought archiving was how you *share* a finished project.\n\nFour 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.\n\n### The two questions that classify almost anything\n\n1. **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.\n2. **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.\n\nAsk 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.\n\n## The expertise inversion: your best users make the slips\n\nThis is the least intuitive consequence of the taxonomy, and it changes who you recruit.\n\nMistakes 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.\n\nMost 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.\n\nThe *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:\n\n- participants who already use the product daily,\n- tasks embedded in their real routine rather than scripted fresh,\n- time-based or diary methods that catch errors when attention is elsewhere -- the condition under which slips happen.\n\n## Classifying errors across a study\n\nOnce each error has a type, the aggregate becomes readable in a way that a raw error rate never is.\n\n### Same error rate, opposite diagnosis\n\nImagine 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.\n\n### Weight severity by type\n\nSeverity 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.\n\n### Watch for mistakes that masquerade as slips\n\nParticipants 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.\n\n## Common mistakes when classifying user errors\n\n- **Counting without classifying.** An error count with no type is a thermometer with no diagnosis.\n- **Classifying from the recording alone.** You are guessing the intention. Ask.\n- **Treating all errors as design failures of the same kind.** A description slip and a wrong mental model share nothing but the word *error*.\n- **Testing only novices.** You will find mistakes, and structurally cannot find capture slips.\n- **Letting the participant's word choice decide.** *I misclicked* is a claim about the error, not a classification of it.\n- **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*.\n\n## How Koji fits into error classification\n\nThe 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.\n\n- **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.\n- **Structured classification questions.** Koji's [structured questions](/docs/structured-questions-guide) 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.\n- **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.\n- **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.\n- **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.\n\nTraditional 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.\n\n## Frequently asked questions\n\n### What is the difference between a slip and a mistake in UX?\n\nA 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.\n\n### What is a lapse?\n\nA 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.\n\n### How do you tell a slip from a mistake in a usability test?\n\nAsk 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.\n\n### What is Rasmussen's skill, rule and knowledge model?\n\nIt 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.\n\n### Why do experienced users make more slips?\n\nBecause 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.\n\n### Does a confirmation dialog fix user errors?\n\nIt 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.\n\n## Related Resources\n\n- [Structured questions in AI interviews](/docs/structured-questions-guide) -- the six question types, including the yes_no plus open_ended pair that classifies an error.\n- [Usability metrics guide](/docs/usability-metrics-guide) -- where error rate sits among the other task metrics.\n- [Usability issue severity ratings](/docs/usability-issue-severity-ratings) -- adding error type as a severity dimension.\n- [Poka-yoke for research](/docs/poka-yoke-mistake-proofing-research) -- forcing functions and why they only work on some errors.\n- [Think-aloud protocol](/docs/think-aloud-protocol) -- capturing intention while the task is still running.\n- [Automation surprise in research operations](/docs/automation-surprise-research-operations) -- mode errors when the system, not the user, changed state.\n","category":"Research Methods","lastModified":"2026-09-22T03:26:50.848907+00:00","metaTitle":"Slips vs Mistakes: Classifying Usability Errors","metaDescription":"Slips and mistakes look identical on a recording and need opposite fixes. How to classify usability errors, and why experts make the slips.","keywords":["slips vs mistakes","usability error classification","slips lapses mistakes","rasmussen skill rule knowledge","capture error","mode error","human error ux"],"aiSummary":"A slip is the right goal executed wrongly; a mistake is a wrong plan executed correctly. They look identical on a session recording and need opposite fixes: slips need interface changes, mistakes need a different mental model. Classification requires asking the participant what they intended. Because slips come from habit, first-session tests with novices cannot surface capture errors, so test with daily users too.","aiPrerequisites":["Basic familiarity with usability testing","Experience reviewing session recordings"],"aiLearningOutcomes":["Classify an observed error as a slip, lapse or mistake","Map each error type to the right design fix","Use two debrief questions to capture intention","Recruit habituated users to find capture slips"],"aiDifficulty":"intermediate","aiEstimatedTime":"12 min"}],"pagination":{"total":1,"returned":1,"offset":0}}