美剧《奔腾年代》（Halt and Catch Fire）里有一段台词：

“当你使用计算机执行一系列操作，每当你按下回车键，它都能在400毫秒内给予你反馈，反馈时间还不到半秒，那么就可以让你一直保持专注，效率也会飙升，你会完全沉迷进去。但反馈时间哪怕只是偏差到半秒钟，你的注意力都容易被分散，你甚至会想起身洗个碗、拿个遥控板、看场比赛...所以说400毫秒以下的反馈速度，是最佳节点。”

当然翻译中带了点我个人的语言色彩，但意思还是这么个意思，也就是说当交互反馈时间小于400毫秒，那么将大大提升用户的专注程度与效率，用户也不易急躁。而大于400毫秒，即使仅仅是偏差到半秒钟（500毫秒），也容易被用户感知到，从而影响用户心流。

而剧中引用到的这个临界值“400毫秒”，就是我们今天要聊到的——多尔蒂阈值（Doherty Threshold）。

一、为什么是400毫秒

1982年，IBM公司的WJ·多尔蒂（WJ·Doherty）及其团队就“系统响应时间对经济价值影响”的课题展开了研究。研究过程主要以用户操作系统后，系统的响应时间作为变量，观察其对多个维度的结果产生的影响。

最终从其中的一组研究实验结果中观测到了一个现象：一旦当系统响应时间超过400毫秒左右时，各项指标数据就会开始产生较大数值的波动。

于是IBM公司就此提出了研究结果：系统响应时间应该低于400毫秒，这将显著提升用户的关注度，从而影响到用户的操作、工作效率。并将“400毫秒响应时间”这个节点值以WJ·多尔蒂的名字命名为「多尔蒂阈值」。

虽然如今我们早已认为系统拥有快速响应时间是一件理所应当的事情，但「多尔蒂阈值」的提出，在当时那个年代却是开辟先河性的。因为70年代左右，计算机研究界还普遍以“系统的响应时间可以为2000毫秒（2秒）”作为业界标准。

虽然我现在已经查询不到这个“2秒”旧知识的科研文献了，但是在 IBM 2018年的一场欧洲线上演讲会的PPT中我们还可以看到：

所以「多尔蒂阈值」可以说是重新定义了现代人机交互领域响应体验的指标，影响着一个标准规范产品的视觉侧、交互侧、体验侧、开发侧等多个方面。

二、多尔蒂阈值的运用

我们要清楚的是，「多尔蒂阈值」是IBM公司给到的一个系统响应时间的最大参考值，并不是说所有的机器响应时间都必须卡在400毫秒这个节点上，而是说响应时间应保持在400毫秒以内，尽量不要大于400毫秒。

那么知道了“400毫秒以内”这个范围值，我们作为设计师，要怎么将其运用到设计工作中，或者说「多尔蒂阈值」会影响到我们哪些设计标准呢？——来看看 Google 旗下 Material Design 的系统动作规范，应该能让你找到一些方向。

  · 要点一：并不是越快越好  

作为设计者、开发者，我们都希望系统能够尽量快地响应用户的操作。但也并不是一味地追求极速就一定是好的。

Material Design 在系统响应动作规范中强调了“过渡时间”的概念，虽然大家都希望系统的响应速度越快越好，但同时用户也需要一些时间去理解系统响应的结果。

如果响应即结果，而不给用户一个视觉过渡的反应时间，则会让用户无法跟随UI变化，同样也是会给用户造成困扰的。

Material Design 规范建议到：不要给用户过慢的响应速度，干扰用户操作进程，让用户急躁；但也不要给用户过快的响应速度，用户无法跟随UI变化，对用户理解会造成困扰。

我们将响应速度结合「多尔蒂阈值」范围内的视觉过渡效果，可以帮助用户理解操作反馈的结果，有时间思考类似于“我刚才点击了什么”、“结果和我的操作之间是什么关系”、“结果是否满足我的预期”等问题，并做出下一步的反应。

  ·  要点二：响应时间不是一成不变  

为了让响应视觉过渡更加符合现实规律，Material Design 根据响应结果区域的大小设置了3种响应过渡时间规范，其中又以用户的操作场景进行了更进一步的规范细分。

先来说说根据响应结果区域的大小设置的响应过渡规范：Material Design 将操作响应结果区域分为小、中、大3种场景，当操作影响的结果区域越小，那么响应过渡时间就应该越短。反之，操作影响的结果区域越大，响应过渡时间就会越长。这一点是符合人类意识对运动的理解的。

其次 Material Design 还认为，用户做“关闭”、“退出”类操作时，预示着他们那要进入下一个任务流，而此时上一个任务流的内容，用户就不再关注了。操作与结果的关系、层级的关系、内容的位置关系，在“打开”、“进入”类的过渡中就已经阐明给用户了，所以他们离开的时候，可以更快。这就是在响应结果区域大小的基础上，又以用户的操作场景进行的更进一步的规范。

• 小型区域：响应过渡统一为100毫秒；

• 中型区域：打开的响应过渡为250毫秒，关闭的响应过渡为200毫秒；

• 大型区域：打开响应过渡为300毫秒；关闭响应过渡为250毫秒。

结合两个要点总结一下：系统响应应该结合视觉过渡给用户操作与结果的关系进行指引，所以也并不是越极速越好。响应过渡应该在「多尔蒂阈值」以内，并且可以结合响应区域大小、用户操作场景，使响应更符合现实规律，更加人性化。

三、面对不可避免的延时响应

虽然把系统响应控制在「多尔蒂阈值」内是我们追求的目标，但是响应速度往往和请求的数据量、网络环境等诸多因素有关。对于结果返回数据量小的场景，我们利用视觉或代码层面的解决方案，可以让响应时间是可控的。

但当用户遇到结果请求数据量大、网络环境较差等场景，响应时间以“秒”起步那也是司空见惯的事情。此时面对无法保证响应时间在“400毫秒”以内的情况，我们应该怎么办呢？

其实这已经超过「多尔蒂阈值」的讨论范围，对于不可避免的延时响应场景，已经是属于“如何解决用户等待焦虑”的话题了。

但恰好我之前在《聊聊加载等待的那些事 之 进度指示器》中聊到过这个话题。想系统了解的朋友，可以移步查看。（知识就这么串联起来了！神不神奇~）

对于想走捷径的同学，我在这里把当时的调研结果贴出来，希望能够帮助到你们。

我结合了 “用户等待4秒原则”和UX研究咨询公司 Nielsen Norman Group（NN/g 尼尔森诺曼集团）的一篇文献中提出的 用户等待心理模型，得出了以下参考结论：

用户是一个复杂的群体，他们其实并不关心所谓的量化时间，他们只希望：加载尽量快，快到不要中断我的操作流，如果实在快不起来，那就告诉我还要等多久。所以由上表得出的结论是：

• 加载时长在0到1秒之间时：用户不易感知，不需要给予用户 loading 提示，在任何加载情境下频繁给出 loading 提示其实反而会干扰用户心流；

  
  

• 加载时长在1秒到4秒之间时：此时不需要明确给予用户量化时间提示，用户也不易产生焦虑情绪；

  
  

• 加载时长大于4秒时：超过这个时间你就需要明确地告诉用户当前的进度状况了，加载百分比或剩余时间都可以让用户心里有个底；

  
  

• 加载时长大于x秒时：设计者应该根据具体加载场景设置加载时间临界点机制，在加载超过这个时间之后默认为加载失败，让用户进行再次操作，而不是无意义地苦苦等待。

四、总结

「多尔蒂阈值」不仅仅是设计师完成交互动效、反馈体验时的一个知识点，它是IBM对整个计算机反馈机制进行研究之后得到的结论，影响体验、效率

、经济等多个方面。所以我认为这是互联网人都应该熟知的一条交互理论。

只是我在这里仅结合了 Material Design 的系统动作规范，分析了设计层面对「多尔蒂阈值」的应用，还是稍显片面。但感兴趣的朋友，还可以去搜索了解更多关于「多尔蒂阈值」的实验、故事与实践方案。