Task Success Rate: Calculate It with Clear Criteria, Denominators, and Evidence

Define the result before counting the successes

Task success rate is the number of attempts that meet a stated success criterion divided by the number of attempts included in the analysis. The arithmetic is simple. The difficult part is deciding what counts as the task, what evidence establishes success, and what happens to assisted or unobserved attempts.

MeasuringU's task-metrics guide distinguishes observed completion from other measures such as perceived ease and time. A participant can be confident that they finished while the system contains the wrong result. The criterion should therefore describe the outcome that matters, not just the last button clicked or the participant's satisfaction.

This article uses an invented report-export study to show the full calculation. Twelve people are scheduled to export a monthly report from a fictional application. The example includes individual records, assistance, a product failure, a missing observation, uncertainty, and the exact report wording.

Turn a vague task into a scoring rule

The task is: 'Your team needs a CSV containing only approved expenses from September. Create the file you would send them using the report area of this test account.' The starting account contains approved and pending expenses from September and October. The participant does not need to email a real person; the task ends when a valid file has been created.

Before running the study, prepare the expected set of September approved records. A successful file has the CSV format and exactly that set of records. Merely selecting September and clicking Export is not enough if the file includes pending expenses or a different month. Conversely, a participant may take an unexpected route and still succeed if the file meets the same criterion.

The main measure is independent success during each participant’s first study attempt; self-correction without guidance still counts. Once a moderator supplies navigation or filter guidance, a later valid file is recorded as assisted completion. Repeating the neutral task wording without revealing a route is distinguished from guidance. Decide this policy in advance, train observers on examples, and preserve the exact intervention in the notes.

Partial progress is still useful diagnostic information. A participant who selects the right month but exports every status has located part of the workflow. That does not meet the declared task outcome. If the team wants a separate milestone measure, report it separately rather than assigning an improvised half-success score after seeing the results.

Keep a row for every scheduled participant

The fictional log below includes all twelve scheduled people so the denominator can be reconstructed. Eleven begin the task. Ten have an observed outcome. Seven independently create the correct file; one completes after guidance; two do not produce a valid file. One attempt remains unknown because the capture ends and the test file cannot be recovered. One person never starts.

For the complete observed attempts, independent success is 7 divided by 10, or 70%. The assisted completion stays in that denominator but not in the independent-success numerator. If you also report completion with or without assistance, it is 8 divided by 10, or 80%, under a different label. Do not silently use 80% as the independent result.

The application error in P10 is a genuine observed failure of this task. Removing it as 'technical' would improve the score by deleting part of the product experience. P11 is different: the evidence is insufficient to establish the outcome. That missing observation must remain visible, even though it cannot enter the complete-case binary calculation.

Show how the missing attempt could change the answer

The complete-case result is not automatically the result for all attempts. For the eleven people who started, the unknown P11 could be an independent success or a nonsuccess. Keeping every other classification fixed, the independent rate would be 7/11 = 63.6% if P11 did not succeed, or 8/11 = 72.7% if P11 did succeed.

This 63.6% to 72.7% range is a simple missing-outcome sensitivity range. It is not a confidence interval and does not describe sampling uncertainty. It shows only how this one unknown record changes the denominator-based result. It also does not repair a recruitment sample that differs from the intended users.

Do not use the twelve scheduled people as the denominator for a task-completion rate without explaining that change of question. Seven out of twelve combines task behavior with attendance. That may be useful for study logistics, but it is not the same quantity as success among people who attempted the task.

The same discipline applies when several tasks are assigned. If one participant attempts five tasks, those are not five independent people. Report task-specific counts first. An overall participant-task proportion can be described, but its uncertainty and interpretation must account for repeated observations rather than treating every row as an unrelated participant.

Add uncertainty without making the sample representative

A proportion from ten observed attempts is imprecise. To illustrate sampling uncertainty, a two-sided 95% Wilson interval for 7 successes in 10 independent binomial observations is approximately 39.7% to 89.2%. NIST provides the Wilson method and distinguishes it from other binomial interval methods. State which method you use rather than presenting an unexplained error bar.

For reproducibility, use p = 0.7, n = 10, and z = 1.96. The Wilson center is (p + z²/(2n))/(1 + z²/n). Its half-width is z × sqrt(p(1 − p)/n + z²/(4n²))/(1 + z²/n). Subtract and add the half-width to obtain 0.3968 and 0.8922, then convert to percentages. This is a calculation under a model, not a prediction that the next ten people will fall inside that range.

The interval does not solve the unknown P11 outcome, assistance-policy differences, biased recruitment, or a task that does not resemble real work. In this teaching study, the complete-case interval describes the calculation for the ten observed outcomes under its assumptions. It should not be advertised as a validated range for all customers. Report the missing-outcome sensitivity analysis separately.

A target such as 'at least 90% independent completion' also needs a decision rule. An observed 9/10 does not establish that the population rate exceeds 90%. For a consequential benchmark, plan the sample and analysis around the precision or comparison needed, with the relevant statistical support. Do not borrow a universal passing score from an unrelated product.

Use the failures to decide what to fix

A completion rate can tell you that the task deserves attention; it cannot identify the repair by itself. Return to P08, P09, and P10. P08 needed help finding the filter. P09 exported the wrong status set without realizing it. P10 encountered an application error. These are different mechanisms and may need different owners and follow-up checks.

For P09, a candidate repair is to show the selected month and status beside the export action and in the preview. The follow-up task should still ask for the correct file without naming that new control. Inspect the resulting CSV as well as what the participant believes. A more reassuring success message alone could make the wrong export feel even more convincing.

For P10, reproduce the export error with the same test conditions and verify the product fix. Then include the repaired flow in user testing when appropriate. A developer's successful export is useful technical evidence but does not establish that the filter choice is understandable. Keep technical verification and user outcome evidence distinct.

Report the numerator, denominator, and limits in one place

A complete report for the invented study could read: 'Twelve participants were scheduled; eleven began the report-export task. Ten outcomes were observable. Seven of those ten produced the required approved-only September CSV without guidance (70%). One completed after filter guidance and two did not produce a valid file. One started attempt had an unknown outcome. Treating that unknown as nonsuccess or success gives 63.6% to 72.7% independent completion among all eleven attempts. The 95% Wilson interval for the ten observed binary outcomes is 39.7% to 89.2%, under the stated binomial assumptions. This small recruited sample supports diagnosis of the observed export problems, not a claim that 70% of all customers succeed.'

Keep the raw record and scoring key with the report so another reviewer can reproduce the count. Record the task wording, prototype or product version, participant criteria, device context, assistance policy, and exclusions. If a classification changes after review, preserve the reason and update the calculation rather than leaving the slide and spreadsheet inconsistent.

When comparing a later design, preserve the task and success criterion or clearly state why they changed. Use comparable recruitment and assistance rules, account for repeated participants if any, and choose an analysis suitable for the study. A larger percentage from a different task or population is not by itself evidence that the redesign caused an improvement.

• Task and final state: [what must be true for success].
• Evidence and scoring: [how correct output, assistance, failure, and unknown outcomes are recognized].
• Counts: [scheduled], [started], [observable], [independent successes], [assisted], [failures], [unknown].
• Result: [numerator/denominator], [uncertainty method if used], [missing-outcome analysis], and [scope of the conclusion].
• Action: [observed mechanism], [candidate repair], and [follow-up that could verify it].

References

• MeasuringU: A guide to task-based UX metrics
• NIST: Confidence intervals for a binomial proportion