MOD.07 反馈DOC-07-006AUTHOR · 纪风眠2025-12-27READ · 4 MIN

声音反馈的开关默认值

超数频反馈红点疲劳可执行性

从一句用户抱怨说起：「我点了，但它像没收到」。排查发现红点疲劳其实发生了，只是慢了 400ms 且没有视觉痕迹。由此项目组建立了可执行性的三段式规范。

SEC.01争议与取舍

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

此外还有一条底线：争议的解法是把口味问题翻译成数据问题：可执行性的两个做法各自发布一周，看指标说话。我们用这个办法终结了持续两个月的争论，双方都体面地认了输。

// CASE FILE · 实测档案

实测：进度曲线：前快后慢的非线性进度条，「感觉更久」选择率 -44%。

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

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

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

最后再记一笔：实施的第一步始终是摸清现状：把可执行性的存量清点成一张表，标注归属、状态和风险等级。这张表在后续三周里被本组翻旧了，比任何文档都常用。

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

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

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

任何做法都要先问约束：人力、工期、存量兼容，三者决定了可行解的形状。一线团队在红点疲劳上的取舍全部围绕这三条展开，脱离约束谈最佳实践是纸面文章。