metrics
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 signal, not a verdict on users, and it has many causes: design, task complexity, training, environment, unfamiliarity or who you tested. A cluster of the same error is worth investigating, and the type of error hints at the kind of fix.
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 often a design smell - if lots of people get the same thing wrong, the design may have set them up to - but it can also reflect task difficulty, unfamiliarity, environment or participant fit, so read it in context. Distinguish the 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. See where errors cluster, then fix the likeliest cause - and prevent rather than blame.
When one in three attempts goes wrong, the instinct is "users aren't paying attention" - but if a third of people trip on the same step, the step tripped them. Error rate turns that into a number you can't argue with, and the type of error - a fumbled tap versus a misunderstood label - points straight at whether you've got an interface problem or a comprehension one.
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.