Q3.08.1Error taxonomy over error countsdesignresearch

Errors need classification, not just counts

Aliases: error classification · slip versus mistake · recoverable error

What it is

An error rate that only counts events treats a one-off mis-tap, selecting the wrong object, walking a whole flow on a false mental model, and an unrecoverable submit as the same number. Classification asks where the failure came from in control or knowledge, and what it cost. Counts can say “more or less”; classes decide whether to change labels, constraints, feedback, or the flow.

Why it happens

Action deviations have different sources. A slip is a correct intention executed off-target, often from adjacent targets, timing, or delayed feedback. A mistake is a wrong intention, often from a false system model or missing information. Recoverable versus unrecoverable cuts consequence. Summing them lets an interface that invites adjacent taps and one that teaches “delete” as “archive” post the same rate while needing opposite fixes. Counts are also diluted by opportunity: a rarely used dangerous action produces few errors without being safe.

Studying it

Build an error dictionary in advance: action-level (slip, omission, mode error), knowledge-level (rule/knowledge mistakes), and consequence-level (self-correction, system intercept, task failure, external harm). Bind each code to the interface state where it occurred, not to a bare “wrong.” Report people per class and opportunity-adjusted rates (errors divided by attempts of that action). When comparing designs, watch class shifts: a flat total with fewer unrecoverable errors can still be a real gain. Inter-rater agreement should be computed on classes, not only on whether an error occurred.

Where it stops holding

Very short tasks yield few errors and empty class cells; case description then beats a rate. Expert slips and novice knowledge mistakes should not be rate-compared directly. Automated validation intercepts many execution deviations before submit, so log “errors” are the ones that leaked, while lab observation still sees the blocked attempts. Near misses in safety work need their own class; final task success is not a reason to drop them.

Applying it

  • Ban a sheet with only an “error count” column; at least split self-corrected, system-blocked, and task-failing errors.
  • Map frequent classes to a change type: adjacent slips to spacing or confirmation, model mistakes to wording and examples, omissions to a required step.
  • Use attempts of that action as the denominator so a rarely used dangerous control is not scored as “rarely wrong.”
  • On retest, check class shifts; a lower total with more unrecoverable errors is a regression.

Related

  • Same group: Q3.08.2 Help-seeking indicates that the interface does not explain itself · Q3.08.3 Support records are a low-cost source of error evidence
  • Adjacent: Q3.06 Task success rate · Q3.07 Task completion time
  • Search terms: error taxonomy · slip versus mistake · recoverable error

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/Q3.08.1