6.5.4 Operability measures

What this heading covers

Operability is the steady state. It covers the number of steps, the error rate, the consistency of the interaction and the physical effort. The measure should be taken from a task that represents normal work, with users who know the product, because otherwise it measures learning. A common failure is to measure the happy path only, where operability is highest and least informative. The measure should include recovery from an error, which is part of operating the product.

Record position: family 11 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.4 in the public contents; the text behind it is not public.

How a measure for this family is built

Take the number of operations completed without error as the numerator over the operations attempted. Alternatively, count the steps or the time per task and compare with the target the requirements set. Record the task, the user group and the interface version, because all three change the result.

What to put in place before publication

1. Use tasks that represent normal work, not a demo path.
2. Include an error and a recovery in the task set.

Evidence to keep

Two questions to ask

• Which interface version do these operation results belong to?
• Did the task set include an error and a recovery?

Where teams usually fall short

• A time-on-task result from the product team, who designed the interface.

What the number cannot tell you

It cannot tell you whether the task was the right task. A well-operated interface on a badly designed task is still a product problem.

What happens next

User error protection is the next family and the one that decides how costly an operability failure is.