诊断界面感知变慢或制定性能预算时，用 Doherty…

适用于诊断响应延迟造成的感知卡顿、为高频交互设定延迟预算，并在无法及时响应时设计反馈模式。

适用场景

解决思路

1. 应用 Doherty Threshold 识别响应延迟在哪里破坏用户流，并据此设计反馈模式和技术目标，让交互感觉即时。
2. 将 400ms 作为响应目标：用户操作后系统在 400ms 内响应可显著提升生产力，让用户保持心流；超过后用户会注意等待，认知投入下降。
3. 用 0–100ms 区间判断为即时，系统像动作的直接延伸。
4. 用 100–300ms 区间判断为快，可感知但不干扰。
5. 用 300–400ms 区间判断为接近边界，部分用户会注意到。
6. 用 400ms–1s 区间判断为慢，用户意识到等待，需要响应指示器。
7. 用 1s+ 区间判断为确定慢，需要进度反馈，心流已断。
8. 用 10s+ 区间判断为任务级中断，用户会切换上下文。
9. 让 slide 和 view transitions 在 400ms 内完成；超过后过渡本身变成等待。
10. 让 inline interactions（toggles、checkboxes、dropdowns、tab switches）感觉即时。
11. 让 search 和 filter 结果在 400ms 前开始出现；若不能，立即显示 skeleton 或 spinner。
12. 让 autocomplete 首个建议在输入后 300ms 内出现。
13. 让 button feedback 在按压后 100ms 内发生视觉状态变化，无论底层动作是否完成。
14. 若系统确实无法在 400ms 内响应，先在 100ms 内用触发元素的视觉状态变化确认收到操作。
15. 若完成需要 400ms–3s，显示 loading indicator。
16. 若完成需要超过 3s，显示 progress，而不仅仅是 spinner。
17. 使用 Optimistic UI：立即更新界面，服务器响应到达后再 reconcile。
18. 对已知布局的内容优先使用 skeleton screens 而不是 spinners；它们维持空间上下文并感觉更快。
19. 在目标设备和网络条件下测量真实交互延迟，而不只是在开发环境测量。
20. 将 400ms 视为任何用户期望立即完成的交互的外边界。
21. 对在 400ms 内完成的操作绝不显示 loading state；spinner 闪一下本身就会造成干扰。
22. 优先为最频繁的交互设置延迟预算。
23. 将响应时间优化与 motion design 结合：计时合适的 200ms transition 感觉快，突然的 50ms flash 可能感觉 broken。

适用边界 · 注意事项

• 不要用它评估有意的动画/过渡总时长；它衡量感知等待时间，不限制 intentional motion，故意的 250ms 入场动画可以。
• 不要要求所有复杂数据获取的 API 响应都低于 400ms；现代应用有时会超过，目标是通过反馈设计最小化等待感知。
• 不要把它当作严格实证阈值，认为超过后所有生产力都会丧失；它是从终端系统生产力模式观察中得出的设计目标。