一句投诉改哪里
别修用户说的那个东西，修他真正撞上的那个
用户原话：「[粘贴投诉]」。不要直接照做。请这样拆：1）分三栏写下「他说的 / 他实际做的 / 他实际遇到的」；2）列出 3 个可能的界面原因，按可能性排序，每个注明依据；3）对最可能的那个给最小改动，并说明改的是文案、控件还是流程；4）指出如果照字面改会引入什么新问题；5）给一个验证方式，看哪个指标、观察多久算有效；6）写一句回给用户的话，不承诺做不到的事。
使用建议
先复现再归因；能拿到用户的操作录屏或会话回放，比任何转述都省事。
适合什么场景
- 客服转来一句「你们这个按钮点了没反应」——直接去改按钮的响应，很可能修错了地方。
- 应用商店一条一星评论写得很情绪化——里面往往藏着一个具体的界面决策，拆出来才能用。
不适合的场景
- 投诉已经明确到可复现的步骤和报错码——那是 bug 流程，直接复现比做归因快。
- 同一条反馈出现在 20 个人那里——先做聚类统计，单条深挖会漏掉共同原因。
示例
输入
「每次改完地址都要重新选一次配送时间，烦死了」——来自 3 个用户，都发生在结算页
你会得到
三栏拆解：他说的是「重新选时间」，实际做的是改地址后再点一次时间选择器，实际遇到的是地址变更把已选时段清空了。最可能的原因是地址提交时重置了整个配送模块的状态，最小改动是只重置与地址相关的字段、保留配送时段；照字面加「记住上次选择」会掩盖状态重置这个真问题。验证看结算页放弃率和时段二次点击率，观察两周。
常见误用
- 把投诉当需求直接排期——用户描述的是症状，不是病因，照做常常只消除了说法。
- 用「这是用户不会用」结案——这类结论无法验证，也不会带来任何界面改动。
可以这样改
- 换成「让投诉者本人重放一遍」——写成脚本请他复述操作路径，比转述更接近真实。
- 加「找出这条投诉不该改的理由」——有些投诉指向的是产品策略而非界面，改了会伤另一群人。