MOD.07 反馈DOC-07-016AUTHOR · 纪风眠2025-11-17READ · 4 MIN

无障碍反馈的实时区域

超数频反馈反馈合并可执行性

此外还有一条底线：错误信息写作是这个学科里回报率最高的技能：把「操作失败」改成「网络中断，已自动保存草稿」，客诉就少一半。本文系统讨论可执行性的可执行性改造。

SEC.01踩坑记录

顺带记录一个细节：负反馈要带缓冲垫：拒绝用户的请求时，先共情再说明再给替代做法。同一句额度不足，加不加缓冲垫的客诉率差 14%。

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

// CASE FILE · 实测档案

实测：合并通报：批量操作 40 条 toast 收敛为 1 条汇总，感知耗时 12s→5s。

另一个常被忽视的细节是：进度反馈的三种形态按信息量排序：不定态（转圈）、近似态（步骤 2/4）、精确态（37%）。能选高信息量形态就不要用转圈，等待焦虑和不确定感成正比。

另一个常被忽视的细节是：灰度是工程做法的安全网：先放 5% 流量观察关键指标，任何劣化超过基线 5% 立即回滚。反馈合并的那次灰度让项目组在凌晨两点避免了一次全量事故。

此外还有一条底线：实施的第一步一贯是摸清现状：把可执行性的存量清点成一张表，标注归属、状态和风险等级。这张表在后续三周里被团队翻旧了，比任何文档都常用。

这里再补一笔：语气规范三条：不说技术术语、不指责用户、始终给下一步。「非法输入」改成「请输入 11 位手机号」，可执行性的理解成本立降，这类对照项目组已经积累了 40 组。

顺带记录一个细节：长任务的分段汇报按里程碑拆：每完成 20% 更新一次进度，并在文案里写清「已完成什么/还剩什么」。可执行性的中途放弃率比重估算等待低了一半。

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

最后再记一笔：等待期间给出可做的事是高级反馈：上传时允许继续编辑下一项，可执行性的等待从阻塞变成了并行，感知时长直接砍半。

这里再补一笔：错误信息的可执行性有一个三问模板：发生了什么、影响是什么、用户现在能做什么。三问答全的报错，客诉率平均降 14%；答不全的，就是项目组文案巡检的重点对象。

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

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