System response time counts toward the total only when it blocks the user

What it is

The system response operator only counts toward a task's total time the portion the user must wait through, unable to proceed to the next action. If the response happens in the background or the user can work in parallel, it does not block the skilled path and should not simply be added to the sequence. This card corrects an easy intuitive mistake: it is not "how long the system took to process" that decides whether to include it in the model, but "was the user actually forced to stop" — the core difference between this unit and units like keystroke or pointing, whose duration is entirely up to the user, while whether this one's duration counts toward the task total depends on whether the interface design turned it into a block.

Why it happens

Judging blocking is essentially judging whether a dependency exists between the system response and the user's next action. If the button is disabled after submission and the interface clearly signals the next action cannot happen yet, the response time is a segment the skilled path must pass through and belongs in the total. But if the result appears later while the user can keep editing the next section or switch to another task during the wait, that response time occurs outside the skilled path, and adding it to the sequence artificially inflates a number that should not have been inflated. There is also a more easily overlooked middle case: a response that is only partially blocking in time — the first few hundred milliseconds leave the interface completely unusable, after which, even though the main content has not fully loaded, some secondary actions become available. This needs to be split into a blocking segment and a non-blocking segment handled separately, not lumped together as entirely blocking or entirely non-blocking. Another easily confused pair: an asynchronous task's "total completion time" (from initiation to true final completion) and "user operation time" (how much attention the user actually spends on the task) are two different metrics — the former concerns when the business considers the matter done, the latter is what KLM is actually trying to estimate — and neither substitutes for the other or can simply be plugged into the other's place.

Where it stops holding

Whether users can genuinely do something else in parallel during a wait needs real observation to verify; it cannot be assumed just because the interface technically permits parallel action. Many users, even when technically free to switch away, still sit and watch the loading animation — at which point "non-blocking" in a technical sense and "blocking" in experienced terms diverge, and a model that judges purely by the technical path will underestimate the real perceived cost of waiting. Conversely, even when a response is technically quite fast, a noticeable stutter or visual lag can make users click repeatedly out of uncertainty about whether the system received the command — extra actions caused by perceptual uncertainty that also fall outside the standard R unit and need to be logged and assessed separately. A long response wait, beyond consuming time directly, also erodes user trust in the system and raises the odds of abandonment or duplicate submission — consequences that likewise exceed what a simple "does it count toward the total" judgment can cover, and need their own separate evaluation method.

Applying it

• Judge each system response individually: does it disable the user's next action, and does the interface clearly signal "you cannot continue right now" — only when this condition holds should the time count as blocking.
• Record the median and a high percentile (P50 and P95) of the blocking interval, and note exactly what actions the user is and is not permitted to take during it.
• For a response confirmed non-blocking, design it as a background status indicator the user can return to check at any time, while ensuring it does not interrupt whatever input the user is currently doing.
• How to check: confirm what the user actually did during the wait through real observation or screen recording, rather than drawing a conclusion purely from a server log's response-time figure — if observation shows a user waiting even when technically free to switch away, or clicking repeatedly to confirm the system received the command, those behaviors are themselves an extra cost that needs to be logged separately.

Related

• Same group: B4.12.1 Tasks are split into standard units such as keystroke, point, home, draw, mental preparation, and system response · B4.12.2 The placement of the mental preparation unit is governed by heuristic rules and is the main source of estimation error · B4.12.4 Absolute constant values are questionable, but the differences between alternatives are relatively reliable · B4.12.5 Touch, voice, and gesture lack agreed-upon constants and must be measured before use
• Nearby: I1 State, Time, and Response · B3.01 Visibility of System Status
• Search terms: system response time · blocking wait · async task · perceived latency