6.5.8 User assistance measures

What this heading covers

Help takes many forms: inline hints, a help centre, a chatbot, a person. The family is about the product's assistance, so the measure should start with the point where a user needs it. Two useful shapes are the proportion of help interactions that resolved the problem, and the support contacts per unit of use. A help centre with excellent articles that nobody finds is not good assistance. The measure should record how the user reached the help and whether they returned to the task.

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

How a measure for this family is built

Count help interactions that ended with the user completing the task as the numerator over help interactions in the period. Alternatively, divide support contacts by active users or by tasks performed, and read it as a demand measure with the caveat that lower is not always better.

What to put in place before publication

1. Define resolved from the user's task, not from the help article being opened.
2. Record the help path, including search and chatbot.

Evidence to keep

Two questions to ask

• Does resolved mean the user completed the task, or that the help was opened?
• How did users reach the help: search, inline, chat or a person?

Where teams usually fall short

• A count of help articles published, presented as assistance quality.

What the number cannot tell you

It cannot tell you whether the help was needed at all. Good assistance can mask an interface that should have explained itself.

What happens next

Self-descriptiveness is the design property that reduces the need for assistance in the first place.