用户反馈转改动清单
从一堆抱怨里提炼该改什么，以及哪些不该照做
下面是用户反馈原文：[粘贴反馈]。请转成设计改动清单：1）先合并成不超过 6 类问题，每类注明出现次数；2）区分用户说的和用户实际遇到的，标出哪些是表述问题、哪些是流程问题；3）每条给一个改动动作，并注明改的是界面、流程还是文案；4）按「影响人数 × 修改成本」排序；5）列出哪几条建议不该照做，理由是什么。不要直接把反馈当需求，也不要因为有人喊得响就排前面。
使用建议
反馈少于 20 条的时候结论不稳，先攒够数量，再来做这一步。
适合什么场景
- 收了一堆反馈（群聊、工单、应用商店评论），要判断这版先改什么——先合并分类，再按影响人数乘修改成本排序。
- 要在会上挡掉「谁喊得响就先做谁」时——需要一份明确写着这条不该照做及理由的清单。
不适合的场景
- 反馈总量不到 20 条——样本太小，分类和排序都不稳，先攒量或直接做用户访谈。
- 反馈只来自一个重度用户——不代表整体，先按用户分层看，否则会把产品改成一个人的工具。
示例
输入
20 条反馈：其中 7 条说导出太慢，5 条说找不到导出按钮，3 条要求加批量删除，2 条说表格字体太小，其余零散
你会得到
合并成四类：导出性能 7 条、导出入口可发现性 5 条、批量操作 3 条、可读性 2 条。区分表述与实际：说「太慢」的 7 条里有 3 条其实是等不到反馈以为卡死，属于加载态问题。每条给动作与改动类型，排序时把入口可发现性放前面，因为成本最低且影响 5 人。最后列出不该照做的：批量删除属于低频场景，先观察。
常见误用
- 把反馈原文直接当需求排期——用户说的是症状不是解法，照做常常改错地方。
- 只按出现次数排序，不看修改成本与影响面——喊得最多的一条可能恰好最难改、影响最小。
可以这样改
- 加一条「每条分类注明是界面、流程、文案还是性能」——避免把所有问题都当界面问题来改。
- 把「按影响乘成本排序」换成「分成这周能做、下版做、不做三档」——直接对上排期，讨论能收敛。