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

1. 理论定义

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

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

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

2. 设计应用

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

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

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

2.1 骨架屏

当内容必须加载时，用户最先需要的不是更多信息，而是一个明确的信号。页面是否在工作，操作是否生效，接下来会发生什么。

骨架屏所做的第一件事，就是尽快给出这个信号。以 Blinkist 的骨架屏加载为例，真实内容还没回来，页面先把主要版式搭起来，用灰色占位块把标题、图片、按钮的大致位置标出来。用户看到的不是一片空白，而是一个已经成形的页面框架。

骨架屏接着解决第二个问题，用户不想在等待时反复找位置。内容分批加载时，如果页面元素不断挤压、跳动，用户刚刚扫到的区域会被打散，视线需要重新定位。骨架屏通过提前占位，把每个模块的空间固定住，让后续文字和图片只是替换内容，而不是改变布局。页面因此更安静，用户也更容易把注意力留在任务上。

从体验角度看，骨架屏的价值可以概括为两点。

1. 它让系统在很短时间内给出反馈，让用户知道正在处理。

2. 它也让等待变得可预期，用户能提前理解信息结构，知道内容会出现在哪里。

等待仍然存在，但不再是让人焦虑的空白。

在实际产品里，骨架屏最适合信息密度高、需要快速扫读的页面，比如信息流、列表页、搜索结果、商品卡片、评论区和数据看板。相比转圈或空白提示，它更早把界面交到用户手里，让用户在等待期间也能保持方向感。

2.2 渐进加载

模糊渐显技术讲的是图片在加载过程中的呈现方式。页面先加载一张体积很小的低清图片，并把它放大到最终显示尺寸。因为低清图放大后会出现明显颗粒感，界面会再叠加高斯模糊（Gaussian blur），让画面看起来更平滑。等高清图片在后台加载完成后，再用淡出过渡把高清图替换上来，用户几乎不会察觉到突兀的跳变。