6.2.4 Functional appropriateness measures

What this heading covers

A product can be complete and correct and still be inappropriate: the functions exist, they work, and they do not fit the way the task is done. This family is the bridge between the product and the context of use, and it needs a task, a user group and a setting. That makes it the most expensive of the three functional families to measure and the one most often skipped. The measure should be built from observed task completion, not from a feature review.

Record position: family 3 of 40 in clause 6, under 6.2 Functional suitability, which carries 3 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.2.4 in the public contents; the text behind it is not public.

How a measure for this family is built

Take the number of tasks completed with the product as intended as the numerator and the number of tasks attempted in the study as the denominator. If efficiency matters, add the time or the steps per completed task as a second element. The task list and the user group are part of the definition.

What to put in place before publication

1. Write the task list before observing anyone, and keep it fixed for the study.
2. Record workarounds, because a completed task with a workaround is not the same result.

Evidence to keep

Two questions to ask

• Which user group and which tasks were observed, and in what setting?
• How many completions needed a workaround, and what was the workaround?

Where teams usually fall short

• Appropriateness inferred from a demo by the product team, using their own workflow.

What the number cannot tell you

It cannot tell you why a task failed. The number moves; the observation beside it is what tells you whether the interface, the data or the task design was the cause.

What happens next

Move to the performance efficiency families next if response time is part of what makes a task appropriate.