Classification must precede any redesign

What it is

Given a batch of user error reports, the classification into slip, mistake, and violation has to be finished before deciding what to change — not the other way around. If a team sees "users keep mis-tapping this" and jumps straight to debating "add a confirmation box or add a hint," they're debating a question that hasn't actually been established yet, because no one has worked out how many of these errors fall into which category.

Why it happens

Classification needs extra information — what the user intended, what they understood about the system, whether they knew the correct action — and that information can only be gathered right when the error happens or through a dedicated follow-up. Once a design discussion has already started and a solution is already taking shape in people's heads, the team tends to unconsciously bend whatever information comes in afterward to fit the chosen solution, rather than letting the classification determine the solution. This is a textbook case of confirmation bias: forming the solution first and hunting for evidence afterward drifts off course far more easily than gathering evidence first and then deciding — and once a solution has already been invested in, that drift is hard to reverse.

Where it stops holding

This ordering doesn't apply when an error is already unambiguous enough that no dedicated classification is needed — if logs and context already clearly show the nature of a failure (say, a crash that wiped data, with no bearing on user intention at all), inserting a formal classification round is just theater. Classify-first matters specifically when the cause of the error is genuinely unclear but the team is already discussing a specific fix.

Applying it

When setting up an error-handling process, make "classify" its own step, done before "propose a fix": write the classification conclusion — slip / mistake / violation, with the proportions and the evidence behind them — as a document, get it reviewed, and only then move into solution discussion. If a single batch of reports contains more than one category, the solutions need to be matched accordingly rather than covered by one fix. Verification: audit the team's recent error-handling records. If "problem found" and "solution proposed" show up in the same meeting, produced by the same discussion, with no independent classification document feeding into it, the process hasn't put classification first, and the fix's relevance to the actual problem can't be assured.

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.4 Slips are fixed by interface constraints, mistakes by model correction — the remedies are not interchangeable · 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.16 Incident investigation and error reporting
• Search terms: error classification · diagnosis before fix · human error taxonomy