简介

系统需要在 400ms 内对使用者的操作做出响应，这样才能够让使用者保持专注，并提高生产效率。

在此之前，计算机研究人员普遍认为计算机可以花 2000ms 来响应用户的操作，以便留给用户足够的时候来思考下一步操作。但随着计算机算力的增长，这个时间被 Walter Doherty 的研究刷新到了 400ms 内。

对于前端和后端开发而言，应尽可能优化系统的响应逻辑，避免过长时间的无响应等待；对于设计师而言，也应考虑过渡动画长度，不能使用过长的动画让用户觉得响应好像很慢。

详情

发展历史

上世纪 70 年代后期，研究人员依然认为计算机可以花费两秒的时间对使用者的操作做出反馈，因为他们认为人们大概正好需要两秒时间来决定下一步的操作，所以 2s (2000ms) 一度成为了计算机响应时间的标准值。直到1979 年，计算机的算力开始大幅提升，这时 IBM 的研究员 Walter Doherty 进行了一系列研究来评估算力的增长对生产力的影响。

研究结果表明，计算机的响应速度直接影响了用户响应时间，换句话说，计算机的响应时间越长，用户就要花费越多的时间来思考和决定下一步的操作。

上面这张表格的横纵坐标分别为 用户响应时间 和 系统响应时间。实验表明，系统响应时间如果从之前的 2000ms 降低到 300ms ，用户的响应时间就能够缩短 5s 以上。Doherty 认为人们会将工作需要的一系列操作步骤存储在短期记忆之内，如果系统响应时间太长，就会打断人的短时记忆从而影响下一步决策。

所以，Doherty 认为程序的响应时间，需要在 400ms 之内。

具体说明

1.响应时间的多尔蒂阈值

400ms，是 Doherty 给出的极限值，系统对用户的操作响应时间不能超过这个时间，否则将降低使用效率。单独观察下方每一个时间延迟可以发现，延迟越长，操作越不跟手，用户将受到更大的情绪影响，从而丧失进行下去的动力。

2.过渡动画

时至今日，计算设备的算力早就远远超越了 400ms 的阈值，除了开发能力过差导致的代码响应问题，设计师几乎不需要考虑 400ms 这个响应阈值。设计师反而需要考虑适当时间的动画，来润滑操作与过渡，不能让响应瞬间进行。

另一方面，也不能使用过长的过渡动画，这同样会起到操作不跟手的错觉，让用户等待太久依然不是一个好动画。

3.不可避免的高延迟

在现实的设计工作中我们会发现，在某些场景下响应速度实在没办法做到如此迅捷快速，比如 APP 启动时；还有时候即便系统可以响应，网络却不行。网络并不能在用户操作的一瞬间就把所有需要的资源都下载好，用户必须等待几秒的时间，那么这时候就需要考虑如何减少用户等待的焦灼感，优化等待的体验。

前一种情况，通常会设计一个启动页 (iOS规范中的 Launch screen )；而后一种情况则可以先行渲染一个占位框架，等信息拉取完毕再显示真实的内容。

总结

• 合理的操作响应时长、方式有助于用户保持专注和提高效率
• 软件操作的过度动画时间不宜太短或太长，最常见于 400ms 左右
• 如果无法避免操作中较长读取、等待时间，那么就用其他更有趣的动画、页面来减少用户的焦虑感

参考

1. Doherty, W. J., & Watson, T. J. (1982, November). The Economic Value of Rapid Response Time. Jim Eliott’s Mainframe Blog. https://jlelliotton.blogspot.com/p/the-economic-value-of-rapid-response.html
2. Chinta, V. (n.d.). Is There a Real Connection between Doherty Threshold and Addictive UX? Quora. https://www.quora.com/Is-there-a-real-connection-between-Doherty-threshold-and-addictive-UX