01 / UNDERSTAND
What is task success rate?
Task success rate is the proportion of observed task attempts that meet predefined completion criteria. It describes effectiveness for a particular task, population and test condition. Define success before the session, rather than deciding afterward that a plausible action was close enough.
In a usability study, distinguish independent completion, assisted completion, failure and invalid attempts. The primary rate can use a binary rule, while the additional categories explain what that rate leaves out.
Why use Task Success Rate?
A designer can see several people reach the final screen and still miss whether they achieved the intended outcome. Explicit criteria make observation more consistent and reveal failures that otherwise look like progress. The measure supports comparison only when the task, participants, help and environment remain meaningfully comparable.
When to use it
USE IT WHEN
The team has a specific goal that can be observed in a test.
A design change needs an effectiveness comparison with a defined baseline.
Researchers need consistent completion coding across sessions.
When to choose another method
Use User Interviews to discover goals before writing test tasks.
Use Single Ease Question (SEQ) to capture perceived difficulty after an attempt.
Use Funnel Analysis for a live sequence measured through analytics.
What you’ll need
Write a realistic scenario and an observable end state. Decide what help is permitted, when an attempt ends and how partial results are coded. Pilot the task wording so it does not reveal the answer. Recruit people relevant to the intended use and record conditions, including assistive technology. A laboratory completion rate should not be presented as the live service rate.
What makes task success measurable
Keep the elements that help answer your question and support a decision.
The person’s goal and context without solution clues.
The observable outcome that counts as completion.
One eligible person attempting one defined task.
What assistance is allowed and how it is recorded.
Success, assisted, failed or invalid under stated rules.
Sample size, recruitment and conditions limiting generalisation.
02 / PUT IT INTO PRACTICE
How to measure task success rate
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Choose the task
Pick a consequential user goal rather than a requested click sequence.
Move a repair visit while preserving the original until a replacement is confirmed.
02
Specify success
Describe the actual final state and what would make it incorrect.
A submitted change request alone is not a confirmed replacement.
03
Define assistance
Agree neutral prompts and distinguish help that reveals the route.
Repeat the scenario if needed; record a suggested button as assistance.
04
Pilot the wording
Check that a plausible participant can understand the scenario without hints.
Avoid naming the Reschedule control in the task.
05
Observe and code
Apply criteria consistently and record what happened at the failure boundary.
A person may believe they succeeded while the booking state is wrong.
06
Calculate the rate
Divide independently successful valid attempts by all valid attempts for the primary independent rate.
Seven independent successes from ten valid attempts gives 70%.
07
Interpret and decide
Show counts, assisted outcomes and uncertainty, then prioritise a consequential failure.
Investigate false confirmation before polishing a low impact delay.
Example: independently changing a repair visit
Fictional scenario: ten valid participants attempt to change a booking. Seven meet the independent success criterion, two complete after route specific help and one leaves the original visit cancelled without a replacement. Independent success is 7 divided by 10, or 70%. Assisted completion is reported separately.
The visual shows ten attempt markers grouped by outcome. An annotation describes the harmful false completion. The invented 70% is a description of these attempts, not a reliable estimate of every resident’s performance.
The next design decision targets the wrong final state. The team would make booking status and recovery clearer, then test the same goal with equivalent criteria. Combining assisted and independent completion would conceal why the intervention matters.
03 / BELOW THE SURFACE
Below the surface: the system can succeed while the person misunderstands
Correct backend state and correct user understanding are related but distinct outcomes.
RESULT
Did the intended state actually occur?
Verify the outcome rather than the screen.
HELP
Could it happen without route specific assistance?
Keep assistance visible.
UNDERSTANDING
What does the person believe will happen next?
Inspect false confidence separately.
A participant might create the replacement correctly but believe both visits remain active. Another might confidently believe the change succeeded when only a request was logged. A single binary completion code can obscure these two different risks.
Keep the primary success criterion explicit and add a separate comprehension observation where the task makes a consequential promise. Ask the person to explain what will happen next without teaching them the answer. Confidence in a wrong result is a design problem of its own.
This is an editorial extension to task observation, not a replacement metric. Use the two observations to choose the intervention: routing and state control for incorrect completion, explanation and confirmation for misunderstanding. Report each rather than combining them into an unexplained score.
Task Success Rate companion worksheet
The original companion records task wording, criteria, help and outcome codes. Page two reviews failure consequences and comprehension. Use separate rows or copies for additional attempts and preserve counts before calculating a rate.
Practical tips
Keep the numerator and denominator visible.
Document invalid attempts without silently removing failures.
Use appropriate uncertainty estimates when making population claims.
Common mistakes
Changing success criteria after watching sessions.
Counting assisted success as independent completion.
Reporting a small study percentage as the live population rate.
What you’ll get
A transparent account of effectiveness for the tested task and conditions. Use failure evidence to select a change and compare again under equivalent rules, with uncertainty proportionate to the sample.