Error rate

What does error rate measure, and what does it tell you?

Error rate is how often people make errors while doing a task - mistakes per attempt, or the share of attempts that go wrong. It's a usability metric, not a verdict on users: a high error rate almost always points at a confusing design, not careless people, and the type of error tells you what kind of fix it needs.

Also known as: error rate, user error rate, error frequency

Prefer to watch? Watch the recap 0:52

The demo

Twelve people tried the same task. A third made an error. Before you blame the users - look at which errors, and ask what the design did to cause them.

What this demo shows (text version)

A grid shows 12 task attempts. Several contain an error, each tagged as a slip (right intention, wrong action - a mis-tap or typo) or a mistake (wrong intention from a faulty mental model - doing the wrong thing because a label misled them). The demo computes the error rate (here a third of attempts) and lets you highlight slips versus mistakes, showing that the errors cluster in patterns: the slips around fiddly controls, the mistakes around a confusing label.

The point is that a high error rate is a design signal, not proof users are careless - if many people fail the same way, the design caused it. And the type matters: slips call for interface fixes (bigger targets, constraints, confirmation), mistakes for conceptual fixes (clearer language, structure, matching the mental model). Measure errors to find the problem, then design them out and make the rest recoverable. (Figures illustrative.)

A high error rate is a design smell, not a user failing - if lots of people get the same thing wrong, the design set them up to. Distinguish the two kinds: slips (right intention, wrong action - a typo, a mis-tap) point to interface friction; mistakes (wrong intention, faulty mental model) point to confusing concepts or labels. Measure it, see where errors cluster, and fix the design - prevention beats blame.

Error rate is usually expressed as errors per attempt, or the percentage of task attempts containing at least one error, and it's a core usability measure alongside task success and time on task. A spike on a particular step is a flashing arrow at a design problem - the more people who fail the same way, the more clearly it's the design's fault, not theirs.

The crucial distinction is slips versus mistakes. A slip is the right intention executed wrong - a typo, a mis-tap, the wrong button hit by accident - and points to interface friction (small targets, confusable controls, no confirmation). A mistake is the wrong intention from a faulty mental model - doing the wrong thing because the labels or flow misled you - and points to conceptual confusion. The fixes are different, so the diagnosis matters.

Treat errors as design signals and design them out: prevent slips with constraints, sensible defaults and forgiving inputs; prevent mistakes with clearer language, structure and matching the user's mental model. Then make the errors that remain easy to recover from. Counting errors tells you where to look; reducing them - by changing the design, not exhorting the user - is the goal.