What time on task measures
You start the clock when the participant begins the task and stop it when they have finished it. What counts as finished has to be defined in advance, in the same words for everyone, or the timings are not comparable. Interruptions, questions to the moderator and technical faults are usually excluded and noted separately.
Only successful attempts are timed. Someone who gave up produced a failure, not a slow completion, and folding that into the timings hides the worst result behind a number that looks merely disappointing. For the same reason the middle value is more useful than the mean: one participant who wandered for several minutes will drag a mean upwards and make an otherwise clear picture look muddy.
The same measure can be taken from live traffic, by timing the gap between the first and last event in a defined sequence. That gives volume, but it also picks up people who left a tab open over lunch, so it needs sensible limits before it means anything.
Why time on task matters
It catches the problem that task success rate hides. A journey everyone finishes, slowly and with visible frustration, scores full marks on completion and still costs you customers, because a real visitor with no moderator watching would have left. Timing is what turns “they got there in the end” into evidence.
It is also the measure that responds most obviously to fixes. Remove three fields from a form, put the price where people look for it, or shorten a checkout by a step, and the effect shows up in the timings immediately, long before any change is visible in monthly sales. That makes it a good early indicator when traffic volumes are too small to prove anything statistically.
Where time on task goes wrong
Confusing it with time on page is the common error. Longer time on a blog article can be a good sign — someone is reading. Longer time on a task is nearly always bad, because the task was the point and the reading was not. The two get reported side by side and the opposite conclusions get drawn.
Timing conditions are the second issue. A test run on a fast laptop over office broadband will not reproduce what happens on a mid-range phone over mobile data, which is how most people in Nepal will meet the same page, and page loading is part of the elapsed time whether you meant to measure it or not.
The third is chasing speed for its own sake. A checkout that hides shipping cost until the final step is quick and also dishonest, and the timings will look excellent right up until the refunds start.
How to act on it
Establish the current timing before you change anything, so improvements are measured rather than asserted. Time the same task, worded the same way, on the same class of device and connection each round.
Read it with what you watched, not on its own. Where the clock ran long, go back to the recording and find the pause: a label people read twice, a field that rejected a local phone number, a step that made someone scroll back to check something. Those pauses are the fixes. Then confirm the pattern in live data with a funnel report or form analytics, because a timing that improved for a handful of participants should show as fewer abandonments at the same step for everyone else.