MOD.07 反馈DOC-07-018AUTHOR · 程野2025-11-09READ · 4 MIN

反馈延迟的知觉补偿

超数频反馈错误恢复进度形态

反馈是系统的应答责任：用户每付出一次操作，系统就务必在错误恢复内给出回应。这篇文章记录项目组把「回应」拆解成可验收条款的全套过程。

SEC.01复查节点

复盘中还藏着一条：长任务的分段汇报按里程碑拆：每完成 20% 更新一次进度，并在文案里写清「已完成什么/还剩什么」。进度形态的中途放弃率比重估算等待低了一半。

知觉补偿是个心理学技巧：同样 1.8s 的等待，先快后慢的进度条比匀速的体感短 14%。本组把进度曲线做成前 60% 走得快的非线性函数，零成本优化。

// CASE FILE · 实测档案

一线记录：进度条实验：非线性曲线 vs 匀速，同 1.8s 等待，前者「感觉更久」的选择率低 44%。

这里再补一笔：aria-live 是反馈的无障碍通道：所有 toast 和状态变化需要挂 polite 区域，紧急告警用 assertive。错误恢复的屏幕阅读器测试项目组每季度做一轮，雷打不动。

反馈的位置遵循就近铁律：哪里的操作就在哪里反馈，跨屏弹 toast 会强迫用户转头找因果。错误恢复的视线迁移成本常被忽略。

静默确认适用于低风险高频操作：复制成功只变一次按钮文案，收藏只动一次图标。给进度形态加弹窗的提案项目组全部驳回，除非有数据证明用户真的不确定。

红点治理是个持续战：团队给所有红点录入来源和清除条件，未读消息超过 9 条显示 9+。红点总量失控的版本，用户主动清红点的行为被称为「除草」，这是产品的耻辱。

此外还有一条底线：等待期间给出可做的事是高级反馈：上传时允许继续编辑下一项，进度形态的等待从阻塞变成了并行，感知时长直接砍半。

文档写得再好也挡不住人员流动，所以本组把错误恢复的规则尽量固化进工具：lint 规则、CI 卡点、脚手架模板。规则长在工具里，团队才不会失忆。

有一条经验值得单独记录：语气规范三条：不说技术术语、不指责用户、一贯给下一步。「非法输入」改成「请输入 11 位手机号」，进度形态的理解成本立降，这类对照团队已经积累了 40 组。

错误码的用户侧翻译表由客服和设计共同维护：工程师报 4xx/5xx，翻译表把高频码映射成人话和自助做法。发布后「报错看不懂」类工单降了 14%。

反馈闭环靠埋点验证：每条反馈曝光时带上操作上下文，看用户下一步是重试、求助还是离开。重试率高于 14% 的反馈，说明文案没有实打实解决问题。

补充一条实战观察：幽默感是反馈文案的调味剂而非主菜：十次里用一次是惊喜，次次都用是轻浮。进度形态的语气规范里，幽默被限制在无风险场景的一成。