metrics
Time on task
What is time on task?
Time on task is how long it takes someone to complete a specific task, from start to finish. It’s the most common efficiency metric in usability testing - and one of the easiest to misinterpret.
Also known as: task time
Prefer to watch?
Watch the recap 0:35
The demo
One small task, timed. When you're ready, your job is to find and switch off "Email notifications" in the settings panel. The clock starts the moment you begin.
Find and switch off: Email notifications
What this demo shows (text version)
You're given a single task - turn off "Email notifications" in a mock settings panel of five switches - and the time from starting to completing it is measured. That elapsed time is your time on task.
The demo then makes the metric's main pitfall concrete: a time means nothing without knowing whether the task actually succeeded, and a single measurement means little without a distribution to place it in. A fast time on a task someone abandoned isn't efficiency - it's giving up. Time on task is most useful reported as a median across several people, always read alongside task success.
Time on task measures how long someone takes to finish a task, start to done - the most common efficiency metric in usability testing, and one of the easiest to misread. A fast time only means something if they actually succeeded, and as a median across several people rather than a single run. You can see and try this concept in action on this page.
The seconds you just clocked are a time-on-task measurement - the exact metric behind every timed demo on this site. On its own, though, your number means little: fast could mean you breezed it, or that you gave up and clicked the first plausible thing. The metric only speaks once you pair it with whether you actually succeeded.
A single time tells you almost nothing - you need a distribution. One person taking 40 seconds might be the norm or a wild outlier; only a spread of times across several people shows where the real trouble is. And always report the median, not the mean: one lost participant who took five minutes drags an average somewhere no real person ever was.
My rule: never read time on task without task success next to it. A quick time on a failed task isn't efficiency, it's surrender - the person bailed. The fastest "completion" in a test is sometimes the clearest signal that something is badly broken.
Time on task shows how long users take to complete a task - but only matters if they succeed, and it’s best seen as a group average, not a single run. You can try this in action on this page. To avoid misreading time on task, always pair it with success rates and test it across multiple users - the demo here lets you see how it works in real time.
Time on task measures how long users take to complete a task - but only matters if they succeed. You can test this yourself in the interactive demo on this page, where you’ll see how task time changes with different UX designs.
Time on task is the duration from start to finish of a user completing a specific task - and you can test it live on this page. It’s a common UX metric, but only meaningful when paired with success rate and averaged across multiple users.
Time on task UX is the most common efficiency metric in usability testing - but only meaningful if users succeed and you average across multiple runs. You can see and try this concept in action on this page. It’s easy to misread time on task UX without context - a fast time doesn’t mean good UX if the user failed or didn’t understand the task.