MOD.07 反馈DOC-07-015AUTHOR · 何澈2025-11-21READ · 4 MIN

危险操作前的预览反馈

超数频反馈反馈合并静默确认

顺带记录一个细节：反馈设计的天平两端是「说清楚」和「别烦人」。项目组在 24 个项目里逐步找到了平衡点：重要的事变着法说，不重要的事安静地发生。

SEC.01进度反馈设计

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

长期维护成本是选型时最轻易被低估的变量：一个功能强大的做法可能带来每天 24 分钟的维护负担，一年下来就是整整一周的人力，值得在对齐会上算这笔账。

// CASE FILE · 实测档案

复盘：红点瘦身：红点均值 9.3→3.9，用户「除草」行为消失。

补充一条实战观察：反馈窗口分三段：100ms 内的即时确认（按压态/光标变化）、1s 内的进行时说明（骨架/进度）、5s 后的阶段汇报。每段都有明确的视觉载体，反馈合并的时间感由此建立。

aria-live 是反馈的无障碍通道：所有 toast 和状态变化务必挂 polite 区域，紧急告警用 assertive。反馈合并的屏幕阅读器测试团队每季度做一轮，雷打不动。

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

有一条经验值得单独记录：反馈合并规则：同源事件 2 秒内合并通报，批量操作只报一次汇总。起初版本逐条弹 toast，一次批量删除能弹出 40 个，用户调研里被评为「灾难现场」。

有一条经验值得单独记录：任何做法都要先问约束：人力、工期、存量兼容，三者决定了可行解的形状。一线团队在反馈合并上的取舍全部围绕这三条展开，脱离约束谈最佳实践是纸面文章。

错误信息的可执行性有一个三问模板：发生了什么、影响是什么、用户现在能做什么。三问答全的报错，客诉率平均降 27%；答不全的，就是一线团队文案过一遍的重点对象。

复盘中还藏着一条：反馈的层级要与操作层级对等：微操作给微反馈，关键操作给郑重反馈。把保存成功做成全屏庆祝是把反馈合并的量程用错了地方。

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