系统响应时间只有在阻塞用户时才计入总时间
别名: 系统响应 · 阻塞时间 · R 操作 · 感知阻塞
概念解释
系统响应操作（system response operator）只把用户必须等待、不能继续下一个动作的时间计入任务总时。若响应在后台发生或用户可以并行操作，它不阻塞熟练路径，不应简单加进序列。这一条纠正的是一个很容易犯的直觉错误：不是"系统花了多久处理"决定要不要计入模型，而是"用户有没有因此被迫停下来"决定要不要计入模型——这是这一类单元和按键、指点这些单元最本质的区别，后者的耗时完全取决于用户自己，前者的耗时能不能算进任务总时，还要看界面设计有没有把它变成阻塞。
机制
判断阻塞与否，本质上是在判断系统响应和用户下一步操作之间有没有形成依赖关系。如果提交后按钮被禁用、界面明确表示下一步动作暂时做不了，那么响应时间就是熟练路径上必须经过的一段，理应计入总时；但如果结果稍后才出现，用户在等待期间可以继续编辑下一部分内容、切换到其他任务，这段响应时间就发生在熟练路径之外，把它加进序列会人为拉长一个本不该被拉长的估算数字。还有一种更容易被忽略的中间状态：响应只在时间上部分阻塞——比如前几百毫秒界面完全无法操作，之后虽然主要内容还没加载完，但部分次要操作已经可以进行——这种情况需要把响应时间拆成阻塞段和非阻塞段分别处理，不能笼统地算成一整段阻塞或者一整段不阻塞。还有一点容易混淆：异步任务的"总完成时间"（从发起到最终真正完成）和"用户操作时间"（用户实际在为这个任务花费注意力的时长）是两个不同的指标，前者关心业务上这件事什么时候算办完，后者关心 KLM 真正想估算的对象，两者不能互相替代，也不能把其中一个数字直接套进另一个的位置。
边界
用户是否真的能在等待期间并行做别的事，这件事需要用真实观察去验证，不能只凭界面在技术上允许并行操作就认定用户确实会这么做——很多用户即便技术上可以切走做别的事，实际上还是会盯着加载动画等待，这时候技术上的"非阻塞"和用户体验上的"阻塞"就出现了错位，模型如果只按技术路径判断，会低估真实感受到的等待成本。反过来，即使响应时间在技术上确实很短，如果界面上出现明显的卡顿感或者视觉延迟，用户也可能因为不确定系统是否已经收到指令而反复点击，这种因为感知层面的不确定性造成的额外操作，同样不在标准的 R 单元里，需要单独记录和评估。长时间的响应等待除了直接消耗时间之外，还会侵蚀用户对系统的信任、提高放弃或重复提交的概率，这些后果同样超出了"计入总时与否"这个简单判断能覆盖的范围，需要用别的方法单独评估。
怎么落地
- 对每一个系统响应逐一判断：它是否禁用了用户的下一步操作、界面上有没有明确提示"现在还不能继续"，只有满足这个条件才把这段时间计入阻塞。
- 记录阻塞区间的中位数和高分位数（比如 P50 和 P95），同时写明这段时间里用户实际被允许做哪些操作、不被允许做哪些操作。
- 对确认属于非阻塞的响应，把它设计成后台状态提示，允许用户随时回来查看结果，同时保证它不会打断用户当前正在做的输入。
- 验证办法：通过真实观察或录屏确认用户在等待期间实际做了什么，而不是仅仅依据服务器日志里的响应耗时数字下结论——如果观察到用户即使技术上可以切走却依然选择等待，或者反复点击确认系统是否收到指令，这些行为本身就是需要被单独记录的额外成本。