1982 年，两位 IBM 员工发表论文提出了一种经验标准：当响应时间压到 400 毫秒以下时，生产力的提升并非线性增长，而会出现更显著的增益。论文中那句常被引用的表述是，当计算机与用户以一种双方都不必等待对方的节奏互动时，生产力会提升，成本会下降，满意度会更高，质量也更可能改善。多赫蒂阈值因此被提出，用来强调响应时间对效率具有放大效应。

1. 理论定义

多赫蒂阈值（Doherty Threshold）讲的不是“快一点更好”这种宽泛的常识，而是一个更具体的体验门槛：当系统能在 400 毫秒以内给出反馈，用户与系统的协作节奏会进入一种更连贯的状态，用户几乎不需要等待，生产效率会显著上升。

这里需要特别强调的一点是：“400ms”并不等于“所有事情都必须在 400ms 内完成”。在真实产品里，很多任务天生要更久：拉取网络数据、渲染复杂页面、上传文件、风控校验、生成报告……这些都不是你想快就能快的，所以多赫蒂阈值真正强调的是交互节奏：用户做了一个动作，系统要在足够短的时间里回应，告诉用户“我收到并在处理”。这个回应可以是状态变化、过渡、占位、进度、动效、甚至是一种“先假定成功”的即时呈现。目的不是掩盖慢，而是把慢从“令人焦虑的空白等待”变成“可理解、可预期、可承受的过程”。

所以，多赫蒂阈值和设计最相关的部分并不是“性能指标”，而是反馈设计。性能属于工程现实，阈值属于心理体验；设计师要做的事，是把这两者用“反馈策略”连接起来。

2. 设计应用

如果把多赫蒂阈值换成设计师更容易执行的说法，它其实在教你拆解系统响应的节奏，把一次响应分成两层。

• 先在 400ms 内给出我收到了的反馈，让用户立刻知道系统已经接收并开始处理。
• 再用合适的呈现方式承接后续过程，把真实的处理时间解释清楚，让等待变得可理解、可预期。

接下来我们通过具体的设计案例加以说明。

2.1 骨架屏