实习负责的事情之一就是处理收集到的用户反馈，用户反馈这部分工作感觉比较琐碎。所以这篇文章就是回顾一下关于用户反馈这部分的工作流程，算是在整理用户反馈这部分的总结。
总流程如下图所示：
1.用户反馈的渠道
也就是说用户可以在哪里提出自己的意见呢
（可以延伸拓展一下，各家产品的反馈系统是如何设计的
）
下面这种图来自 知乎-张亮大大，算是列举的比较全面了
2.收集反馈
从渠道汇总用户的反馈，这些渠道比较分散，那么有两种处理的方式：
（1）将所有渠道集成在一起，所有渠道的反馈都会查看并做处理。
参考worktile----做法
这个团队采用了纷云这款团队协作工作，纷云亮点之一在于----第三方服务集成，可以将多渠道集成在一起，做一个汇总。
（2）筛选出几个高质量的渠道，重点维护
同样是参考 知乎-张亮大大
建立一个或者多个指标去衡量渠道的反馈价值，然后主要维护高价值渠道。
指标可以包括但不限于：
反馈数量多
反馈质量高
表达清晰
3.反馈处理
在收集到了反馈之后，应该怎么处理这些反馈呢？
反馈处理流程如下：
分类 ——> 提取
（1）首先将收集到的反馈进行分类，一般有如下分类：
-
Bug
-
功能建议
-
吐槽
-
其他
同时要注意反馈频次的记录，以了解用户比较关心什么
（2）提取
-
Bug。排列优先级，哪些是比较紧急的，哪些是可以靠后修的
-
功能建议（比如说 现有功能的优化（enhancement）、新功能（new feature）） 。要探讨用户提出这个建议的背后原因是什么，要明白为什么用户想要它，而不是只盯住这个功能，深入挖掘把建议转化成需求。
这里有一个很著名的例子----福特汽车公司创始人亨利·福特说，如果在汽车时代早期询问客户想要什么，“要一匹更快的马”。如果听用户的，那么我们根本造不出汽车来，用户需要的就是一匹马。
用户压根不知道自己需要什么，直到你把它摆在面前，乔布斯如是说。
所以需要透过用户的表面需求，去思考用户这种需求背后的动机是什么。 再举个例子，比如说你朋友说了句“走，去吃麻辣烫”，他的需求可能是 就想吃麻辣烫了；肚子饿了，纯粹想填饱肚子；麻辣烫的兼职服务员里面有个他喜欢的妹子 等等好多可能的需求。 -
吐槽。分析用户吐槽背后的原因是什么，思考有什么方法减少用户的负面反馈
同时在分析反馈的时候，要注意以下几个方向：
（1）用户场景：用户在什么情况下，做了什么操作
（2）用户画像：对用户进行画像，看看是目标用户 还是 普通用户 还是边缘用户提出的，是不是符合我们对用户的定位
（3）环境信息：什么设备，什么操作系统，可以方便我们定位并还原反馈
（4）联系方式：方便我们做反馈，也便于后期跟踪
4.提取需求，进行需求管理
针对上部分得到的需求，根据产品的目标（阶段性的和长期性的），做优先级的排序，然后放入下一个版本的需求文档中
5.版本迭代更新
这部分就是跟开发过需求，真正进入一个开发阶段了
6.通知用户
这里是说，新版本修复的问题以及添加或者优化的功能 可以告知用户，以release note的形式。或者对于曾经提过反馈的用户，再一一做一个回复，告诉这些用户，反馈已经收到，并且认真的落实了呢。（通知用户这一步，并不一定是放在版本迭代之后的。有可能在收到用户反馈之后，提出的反馈已经在迭代计划中，那么就可以马上回复用户，告知一个大概的时间。这里就看运营人员的文字功力了。）
总之，要让用户感到被重视，感受到产品的真情实意~~
我经历的用户反馈整理
由于目前产品还处于初期，产品界面上还没有设计用户反馈系统，用户反馈主要来自于：
- 公司内部（主要是美工那边，美工会做样板间、会入模型）
- 种子用户（一些长期合作的用户）
- 市场部（总归还是卖出去了一些，哈哈。有一些是竞标得来的用户，有一些是喜舍杯参赛的用户）
对于得到的用户反馈，都会放在quip（一款团队协作软件）上共享，主要设置了这么几个字段：问题描述、截图、来源、版本号、时间、反馈类型（bug、enhancement、new feature、usage）、status（是不是解决了）、jira link（因为我们使用bug系统是jira），大概是这些。
每次版本迭代的需求来源会从用户反馈中选取部分，就我这次经历的迭代来看，在画layout界面的标尺功能，被很多用户提出来。我们后续又对该需求做了进一步的挖掘，添加了尺寸、网格、垂直、吸附等功能。
整篇文章的架构参考了 人人都是产品经理---白啦 这篇文章，但是结合自己的经历以及网上收集到的资料，形成了这篇文章。我列举的这篇文章写的很棒，思路很清晰~可以去围观。
我是萌萌的小尾巴~~~下面是我的个人公众号：产品新人学习路（i-pm-road） ，主要是分享一些学习产品的心路历程可以关注下哟，欢迎大家一起学习、交流哟。因为坚持，变得愈发优秀
网友评论