Usability Metrics: Task Success Rate, Time on Task, and Error Rate Explained
Usability metrics show whether people complete a task, how hard it is, and where they go wrong. How to calculate them, read the SUS, and size your sample.
What do usability metrics measure?
A usability test watches people trying to do something. Metrics turn that observation into comparable numbers, so you can tell whether one version beats another or whether a problem is serious.
Userlytics defines the three basic metrics directly: task success rate is completed tasks divided by attempted tasks; error rate is mistakes divided by attempts; and time on task is how long people take to complete a specific action (Userlytics, “5 essential usability metrics”).
Typeform recommends tracking time through the median and the outliers, not only the average: a few very long sessions may come from power users or from people who got seriously stuck (Typeform, “Usability metrics: 12 key metrics to track”).
Why should a designer care?
Because it turns a debate about taste into a concrete question: how many people finish, and how hard is it for them? If you redesign a form, you can say, for example, that the success rate rose from 60% to 85%, or that median time dropped from four minutes to two. That is stronger than saying the screen “looks cleaner”.
It also protects you from the trap of averages. A task can show 80% success overall and 40% at the step that matters most. That is why it helps to read metrics task by task.
How do you calculate each one?
| Metric | Formula | Example |
|---|---|---|
| Task success rate | Completed tasks ÷ attempted tasks × 100 | 75 of 100 attempts = 75% |
| Error rate | Errors ÷ attempts × 100 | 25 errors in 200 attempts = 12.5% |
| Time on task | Time for each completed attempt; report median and outliers | Median of 1 min 40 s |
| SUS | Ten-question questionnaire, score from 0 to 100 | Reference average: 68 |
For time, measure only attempts that end in success, or report abandonments separately. Mixing them changes the result. For errors, define beforehand what counts as one: a click on the wrong place, a field filled in wrongly, or a screen that wasn’t understood.
What does the SUS tell you?
The System Usability Scale is a standardized ten-question questionnaire that produces a score between 0 and 100. MeasuringU uses an average of 68 as its reference, which corresponds to the 50th percentile of its database of 500 products. MeasuringU clarifies that the score is not a percentage and that, to interpret it, you convert it to a percentile against that database (MeasuringU, “10 things to know about the SUS”).
Typeform offers a different reading: above 80 is excellent, between 50 and 80 leaves room for improvement, and below 50 signals serious problems (Typeform). The two bands don’t match. Using either is fine, but cite which one you use and don’t compare results across studies that use different criteria.
For a specific task, MeasuringU recommends the Single Ease Question: one question about how easy or difficult the task was, asked right after the attempt.
How many people do you need?
MeasuringU shows that with five people, the SUS average falls within six points of the true score 50% of the time. That works as a rough guide, but not for stating precisely how much something improved. Confidence intervals, which you can calculate from two people up, show how much uncertainty there is, and with five people they are fairly wide.
The practical rule: to observe problems, a few people are enough; to compare versions with numbers, you need more, and the interval tells you whether a difference is real or noise.
Example
Illustrative example: a team tests the sign-up flow of a transport app with 12 people. Before the redesign, 7 of 12 complete the task, with a median of three minutes and five errors in total. After it, 11 of 12 complete, the median drops to a minute and a half, and there are two errors. The numbers aren’t definitive with so few people, but the direction is clear, and the team reports the interval along with the rate. They then look at the SUS: it rises from 52 to 71, and they communicate it against the benchmark they chose.
When NOT to use these metrics
- When you don’t yet know what success means. Without a definition of a completed task, the success rate means nothing.
- To compare different products. A SUS of 70 in an internal tool is not comparable to a 70 in a consumer app without context.
- As a substitute for understanding why. Metrics tell you what happened. Observation notes and interviews explain the why.
- With very small samples and big decisions. A two-point difference in the SUS with four people does not justify a brand change.
Common mistakes
- Reporting only the average time.
- Not defining what counts as an error before starting.
- Measuring task success without looking at the success of each step.
- Treating the SUS as a percentage.
- Comparing results from studies with different criteria without saying so.
How to start tomorrow
Pick the most important task in your product. Write down what counts as success, what counts as an error, and when the stopwatch starts and stops. Test with five people and record the result of each attempt. Calculate the success rate and the median time. After your change, repeat with the same script. If you need to prepare the test, the usability test script helps you write tasks that don’t lead people to the answer. If you want to go deeper into preparing the session, see usability testing. And you can bring the overall figures into the team’s KPIs, after reading them as quantitative data.