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 misread.
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.
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.