连锁的中间状态需要有明确反馈，否则用户会误以为系统卡死
别名: 连锁反馈 · interlock feedback · 中间态提示
概念解释
连锁约束操作必须按顺序发生，这意味着用户在完成前置条件之前，后一步操作会被拒绝或者干脆没有反应。这个"没有反应"的瞬间如果没有配套的反馈说明当前卡在哪一步、还差什么条件，用户没有办法把它和系统故障区分开——按了没用、点了没反应，在用户的经验里和死机、卡顿是同一种感觉，连锁本身设计得再合理，也会被当成一次产品缺陷。
机制
用户判断一个操作有没有生效，依赖的是操作后多快能收到某种可感知的结果，这个判断几乎是即时发生的，人在极短的延迟内就会把"没有反馈"解读为"没有发生"，而不会耐心地去想背后是不是有一个还未满足的前置条件在拦着。连锁的中间状态恰恰是最容易被误判的场景：操作确实被系统接收了，只是因为前置条件不满足而没有放行，这个"接收但不放行"的中间态，在没有反馈的情况下和"根本没接收到"在用户的感知里完全无法区分。要打破这个误判，反馈必须在用户预期能得到响应的时间窗口内出现，并且要说清楚两件事——操作被挡住了（而不是没生效），以及还差什么条件才能继续。
怎么研究
评估连锁反馈是否充分，可以借用感知反馈延迟阈值的研究方法：测量从用户触发被连锁拦下的操作到出现任何可感知反馈之间的间隔，对照人在什么延迟范围内还会把结果归因为这次操作直接引起、超过这个范围会开始怀疑操作没有生效这一类阈值数据，检验连锁反馈是否落在了用户仍然会做出正确归因的窗口内。同时可以对比"有明确中间态反馈"和"沉默拦截"两种设计下，用户重复点击、反复尝试的次数——重复尝试次数高，说明用户把沉默解读成了没有响应，正在用更用力或更频繁的操作去"唤醒"系统，而不是在等待条件满足。
边界
连锁反馈能解决的是"用户误以为系统故障"这个感知问题，它不能替代把前置条件设计得更合理这件事——如果一个连锁的前置条件本身极其苛刻、大多数用户几乎不可能自然满足，再清晰的反馈也只是让用户清楚地知道自己被卡住了，并不会让流程本身变得可用，这种情况需要回到连锁的设置是否合理这个更上层的问题。
怎么落地
对流程里每一个可能因连锁而拒绝操作的节点，设计与操作发生时间接近的即时反馈，内容至少包含"这个操作现在做不了"和"要满足什么条件才能做"两部分，避免用完全静默或者和正常成功状态视觉上无法区分的方式处理拦截。反馈出现的时机要接近用户按下操作的那一刻，而不是延迟很久之后才展示，延迟本身就会被当成第二次故障信号。验证办法：记录用户在连锁节点被拦下后的后续行为——如果大比例用户在被拦下后立刻重复点击同一个操作两次以上，说明反馈没有被及时注意到或内容不够清楚，需要检查反馈出现的时机与位置是否落在用户视线所在处。