6.5.5 User error protection measures

What this heading covers

Protection has two halves: prevention, through constraints and good defaults, and recovery, through confirmation, undo and clear messages. A measure built only on errors observed will miss the errors that were prevented, so the definition should say which half it covers. The population is the set of tasks where an error would matter, not every click. This is one of the most useful families in a procurement conversation because it turns a vague claim about being easy to use into a testable property.

Record position: family 12 of 40 in clause 6, under 6.5 Interaction capability, which carries 8 families. It is one of the 40 families a programme has to map its measures to, and its elements are listed below. The heading is 6.5.5 in the public contents; the text behind it is not public.

How a measure for this family is built

Count the error opportunities where the product prevented or recovered the error as the numerator over the opportunities identified in the task analysis. For prevention, test the boundary cases that invite a mistake. For recovery, inject the error and measure whether the user can return to the task without help.

What to put in place before publication

1. Identify the error opportunities before testing, and record their consequence.
2. Test recovery as well as prevention, with a real error.

Evidence to keep

Two questions to ask

• Does the measure cover prevention, recovery or both?
• Where is the list of error opportunities and their consequences?

Where teams usually fall short

• Undo tested by a developer who knows the exact sequence, with no first-time user involved.

What the number cannot tell you

It cannot tell you about the error nobody anticipated. The population is the task analysis, and the analysis is only as good as the people who wrote it.

What happens next

Inclusivity is the next family, and it often exposes error opportunities that a narrow user group never sees.