Slips need interface constraints, mistakes need model correction — the remedies don't transfer

What it is

Slips, mistakes, and violations all look on the surface like "not doing what was expected," but correcting them takes entirely different remedies. Treating the three as one blurs the target of any intervention: what fixes a slip usually does nothing for a mistake, what fixes a mistake usually does nothing for a violation, and so on in every direction.

Why it happens

The three failure types sit at different layers. A slip is at the execution layer — the plan was fine — and gets corrected by tightening interface constraints at the point of execution, making the deviant action impossible to produce or harmless when produced. A mistake is at the belief layer — the plan itself rests on a wrong understanding — and gets corrected by fixing the mental model, surfacing the system's real behavior at the decision point rather than restricting the action. A violation is at the motivation-and-institution layer — the user knows the correct action and deliberately chooses otherwise — and gets corrected by changing the trade-off itself, making the cost of deviating perceptible, or removing the unrealistic rule that was pushing people to deviate in the first place. Applying the wrong remedy has a predictable outcome: constrain the interface against a violator and they'll find a way around the constraint; add a confirmation prompt for a mistake and, as long as the underlying model hasn't changed, the prompt is soon dismissed as routine; run motivational or institutional training on someone who made a pure slip, and you're disciplining a person who never made a bad choice to begin with.

Studying it

Whether this mapping holds can be tested with a "remedy-mismatch" check: apply three qualitatively different interventions to the same batch of errors and see which one actually lowers the rate. If tightening the interface does nothing for a given error type but changing the incentives or the rule itself brings the rate down, that type was misclassified as a slip when it was really a violation — and the reverse pattern reveals the opposite misclassification.

Where it stops holding

The three-way split doesn't always carve a single real-world incident cleanly — a user might first make a bad choice driven by a wrong mental model, then slip while carrying it out, stacking two different kinds of cause into one event. In that case the two layers need to be separated and treated individually; applying one remedy to a compound-cause failure usually only fixes half of it.

Applying it

Given an error report, first classify it (was the intention correct? if not, did the person not know, or know and choose otherwise anyway), then pick the remedy that matches the category: confirmed slip → touch the interface constraint; confirmed mistake → touch the information display and correct the model; confirmed violation → review the incentives and whether the rule itself is realistic. Don't reflexively add a confirmation dialog across the board — it may help with slips and mistakes, but for someone who has already decided to deviate, it's just one more click. Verification: after an intervention ships, track the rate change broken down by error category. If a given category's rate doesn't move with its matched remedy, the original classification was wrong and needs to be redone, rather than doubling down on the same fix.

Related

• Same group: A10.01.1 Slip — correct intention, deviated execution · A10.01.2 Mistake — the intention rests on a wrong mental model · A10.01.3 Violation — deviating on purpose despite knowing the rule · A10.01.5 Classification must precede any redesign · A10.01.6 Blaming "user carelessness" halts diagnosis · A10.01.7 The line between violation and mistake is whether the deviation was intentional
• Nearby: A10.06 Error-proofing techniques · A10.14 Forcing functions and interlocks · A10.13 Violations and non-compliance
• Search terms: error remediation · slip versus mistake versus violation · intervention mismatch