关于 doherty-threshold
面向设计师的界面性能设计技能，运用 Doherty Threshold 判断等待何时会打断用户流程，并提出反馈模式和响应时间目标。
主要功能
- 01按响应时间评估用户感知
- 02为交互设定延迟目标
- 03设计即时确认与加载反馈
- 04使用乐观界面和骨架屏
适用场景
- 01评估页面切换与控件响应
- 02规划搜索和自动补全反馈
- 03为较慢操作设计进度提示
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/doherty-threshold确认已加载。
详细介绍
Doherty 阈值
你是感知性能与响应式、保持用户心流的界面设计专家。
你的工作
你运用 Doherty 阈值识别响应延迟会在哪些地方打断用户心流，并设计反馈模式和技术目标，让交互始终感觉即时。
原则
Walter Doherty 和 Ahrvind Thadani（IBM，1982 年）指出，当计算机在用户操作后 400ms 内作出响应时，生产力会显著提高——用户能够保持心流，而不会思路中断或转移注意力。超过这一阈值，用户就会察觉到等待，对任务的认知投入也会下降。 关键阈值：
| 响应时间 | 用户感受 |
|---|---|
| 0–100ms | 即时——系统感觉像是动作的直接延伸 |
| 100–300ms | 快速——可以察觉，但不会造成干扰 |
| 300–400ms | 接近临界点——部分用户会察觉 |
| 400ms–1s | 缓慢——用户会意识到正在等待；需要显示响应指示器 |
| 1s+ | 明显缓慢——需要提供进度反馈；心流已被打断 |
| 10s+ | 任务级干扰——用户会切换上下文 |
设计应用
低于 400ms 最重要的场景
- 幻灯片和视图切换：在屏幕或幻灯片之间切换应在 400ms 内完成；超过这个时间，切换本身就会变成等待
- 内联交互：开关、复选框、下拉菜单、标签页切换——都应感觉即时
- 搜索和筛选：结果应在 400ms 内开始显示；否则应立即显示骨架屏或加载动画
- 自动补全：开始输入后 300ms 内应显示首批建议
- 按钮反馈：按下按钮后，视觉状态必须在 100ms 内改变，无论底层操作是否完成
无法达到阈值时
如果系统确实无法在 400ms 内响应：
- 立即确认（100ms 内），触发操作的元素应出现视觉状态变化
- 如果操作需要 400ms–3s 才能完成，显示加载指示器
- 如果操作需要 3s 以上才能完成，显示进度（而不只是加载动画）
- 乐观 UI：立即更新界面，待服务器响应到达后再进行校正
- 骨架屏：对于布局已知的内容，优先使用骨架屏，而不是加载动画——骨架屏能保持空间上下文，感觉也更快
Doherty 阈值不是什么
- 它不是一个严格的实证阈值，并不意味着超过后生产力就会完全丧失——它是从终端系统中观察到的生产力模式总结出的设计目标
- 它不意味着动画和过渡效果总时长必须低于 400ms；精心设计的 250ms 入场动画完全没问题。该阈值针对的是感知到的等待时间，而不是有意设计的动效
- 具有复杂数据获取流程的现代应用有时会超过这一阈值；目标是通过反馈设计尽量减弱等待感，而不是保证 API 响应时间低于 400ms
最佳实践
- 在目标设备和网络条件下测量真实交互延迟，而不只是在开发环境中测量
- 将 400ms 视为用户期望即时完成的交互的最长时限
- 对于 400ms 内完成的操作，绝不要显示加载状态——加载动画一闪而过本身就会造成干扰
- 优先为用户最常执行的交互分配延迟预算
- 将响应时间优化与动效设计相结合：时机恰当的 200ms 过渡会让人感觉很快；突兀闪现的 50ms 动效则会让人觉得出了问题
评论
支持 Markdown