A booking journey ends on a confirmation screen, but the participant has selected the wrong date. Whether the session counts as a success depends on what the study set out to measure. Task success rate, also called task completion rate, is useful precisely when the team has agreed what completing the task actually means.
The basic calculation is the number of successful attempts divided by the number of valid attempts, multiplied by 100. In an illustrative study where 16 of 20 participants complete the same task successfully, the observed success rate is 80%. That describes this sample under these study conditions; it is not an exact statement about every future customer.
Define success before watching the sessions
Write an observable criterion that matches the participant’s goal. Reaching checkout, buying any ticket and buying the appropriate ticket are different outcomes. A task scenario should provide the goal without revealing the route, while the research plan records what the observer will count as success.
Nielsen Norman Group’s introduction to success rate explains the value of this straightforward measure. Its usefulness depends on consistent scoring, especially when someone receives help, stops early or believes they have succeeded when they have not.
Decide in advance how to handle moderator assistance and technical failures. An interruption caused by broken test equipment may be excluded under a documented rule; a person abandoning the product because they cannot proceed is evidence about the experience. Quietly dropping unsuccessful attempts would make the rate misleading.
Keep partial completion visible
Some tasks contain several meaningful outcomes. A person might find the right account but misunderstand the withdrawal conditions, or complete a form only after a moderator points out a required field. Record those cases so that the final number does not erase an important difficulty.
If the report uses binary success, state which cases qualify. If it uses a separate partial-success category or a weighted score, explain that convention and avoid presenting the result as though it were an ordinary completion percentage. The scoring rule should remain stable across the versions being compared.
A short record of the observed difficulty often matters more to a designer than the classification alone. “Failed” identifies an outcome; “selected the correct delivery date but could not recover after an address error” identifies something the team can investigate.
Show uncertainty alongside the percentage
Small samples produce uncertain estimates. Reporting 80% without its denominator makes four successes in five attempts look equivalent to 80 in 100, although the precision differs substantially. Include the number of valid attempts and an appropriate confidence interval when the study is designed to estimate a rate.
Sauro and Lewis’s research on completion-rate intervals examines methods suited to this problem. Avoid applying a simple symmetric interval mechanically, particularly near zero or 100%, and do not treat a small difference between observed rates as a confirmed improvement.
Pair completion with the experience of getting there
Success alone does not show whether a task was slow, uncertain or exhausting. Observations, errors and the Single Ease Question can help explain the experience behind the outcome. Someone may succeed through repeated trial and error, while another may confidently take the wrong route.
In prototype testing, also distinguish a limitation of the prototype from a problem the final design would retain. Compare rates only when tasks, participants, scoring and study conditions support the comparison. The result should help the team decide what to improve, with enough context to understand what the number leaves out.