本文目录结构
一 收集用户反馈的好处
二 用户反馈的收集和分类
三 用户需求的处理
一.收集用户反馈的好处
作为对线上产品用户满意度的了解，收集用户反馈肯定是重要渠道之一。对于用户反馈合理的收集并总结有利于了解当前线上产品的不足，了解用户对线上产品的想法，验证新功能点对用户需求把握得准不准确等用途。对于用户反馈的生命周期，简单说从用户反馈的收集、用户反馈的整理分类（提取关键字和用户主要想表达的想法）、对用户反馈的分析分类和总结、最后进行相对应的处理的一套闭环流程。
用户反馈处理流程
下面我们根据上面的流程对“哔哩哔哩”进行用户反馈的处理。
收集反馈的目的：收集问题，发现新需求，建立与用户反馈的正向作用，
收集反馈内容类别：
用户反馈评价的内容大致分为如下几种：
1.表扬类别：获得肯定（几个字或者一段话），对某个新增功能的评价（验证某个需求功能点是否抓的准）等。
2.bug类别：对产品中一些bug进行反馈（注意用户反馈的时间，版本号，验证是否目前版本还有该bug）
3.用户疑问类别:找不到某些已知更新的功能，某些功能怎么使用等（分析用户疑问类型，是对功能使用，还是某个流程操作存在疑问，来反思是否存在用户使用成本过高的问题，流程复杂等）。
4.功能建议类别：用户希望能添加什么功能，什么功能怎么设计比较好等。
5.吐槽类别：简单几个字，对产品的差评等。
6运营类问题。
收集渠道：微博，贴吧，豆瓣，各大第三方安卓市场（应用宝、小米应用市场等），app
store（酷传、七脉数据等）。
二. 用户反馈收集和分类
下面我们对哔哩哔哩的最近30天（ios平台）的用户评价进行收集和分类。有效评论为64条，主要出现的关键字“ios12闪退”，“2倍速播放在哪里”，“投屏功能”。
通过对反馈的筛选，用户反馈进行主要的分类发现主要是“bug类别”，“功能建议类别”，“用户疑问类别”和“吐槽类别”。四个类别。
（稍后更新补充：这里还需要体现数据的比例，什么模块用户反馈用量大，用户吐槽点最多的）。
1.bug类别
bug类别
我们可以发现问题主要集中在“ios12的适配”上出现问题，出现很多闪退现象、Iphone max上全屏播放视频会卡死、手机投屏不好使等现象。可以发现这种bug都是严重影响用户体验的。
对于bug类别的反馈，我们的处理方式：
首先需要判断是否是已知bug：
①对于已知bug，确认是否在将要迭代的版本上已修复。同时如果具备反馈条件（微博、贴吧等）可以给用户留言评论“已经收到您的反馈，程序猿老铁正在积极修复中，感谢您的建议”等，促进用户反馈的作用。用户反馈越多，对产品的细节打磨越有用途。
②对于未知bug，判断问题出现的概率（及是否能够复现）和严重程度及block程度-是否在将要迭代的版本上解决。（主要思想就是已知高概率bug尽快修复，低概率bug内部测试复测，同时通过线下qq群微信群等进行沟通回访问题产生的条件等）
2.用户疑问类别：
用户疑问类别
对于用户疑问类别的反馈，我们发现主要针对的是“二倍速功能”，用户找不到二倍速功能。我们可以发现在11月11号的版本更新记录中，已经明显的添加“二倍速”功能，但是有非常大的比例用户反馈没有找到。 我们从官方客服了解到，二倍速是不支持iphone7以下机型的。对于满怀欣喜看见更新日志而更新的用户，是否会造成一些误解。从而出现较多的1星2星差评。同时对于学习者而言还需要考虑，为什么用户这么喜欢“二倍速”功能，其他倍速不能满足用户的需求吗？二倍速主要会解决什么场景下的用户需求呢？
更新日志
对于用户疑问类别的问题，我们主要的思路是从用户角度出发，分析是什么原因造成的用户用不明白。是否出现让用户用不明白的设计，主路径是否岔路太多等问题。
3.功能的建议类别：
功能建议类反馈，一般都是用户从自身出发的期望性需求。我们需要从用户使用场景出发，明确需求的目的，是否需要开发和开发优先级别。
功能的建议类别
这里面的反馈主要是增加“2倍速”（对于老机型），画中画功能（pad端），增加字体大小调节功能。
用户提出的建议类别反馈往往是从自身出发，提出的观点和行为。我们需要具体分析用户在什么样的场景下遇到什么样子的问题，希望通过什么样的方法解决。提炼出用户的目的和背后的动机。从而设计出与之匹配的产品功能。
对于功能类别的建议还需要思考：当前存在哪些问题-导入这个需求之后会达到什么样子效果，对现有状态有什么影响-判断功能的使用场景及使用频率-导入这个需求是否增加成本，现有功能元素点是否能满足等。
举例：
当前存在的问题：字体太小，希望增加字体大小调节功能
对现有现状的影响：可能会影响界面的布局效果
用户使用场景及使用频率：需要了解用户对“弹幕”字体可以调节还是app里面的文字需要调节。了解后才能判断使用场景。
现有元素是否支持：不支持，调节系统字体大小，应用字体不会改变。
优先级：低。
4.表扬类别：
对于表扬类别，我们可以观察到用户对新增功能的肯定，对一些设计的肯定。可以从用户反馈角度验证，需求抓的准不准，符不符合预期期望等。
例如5.31版本上线的弹幕防挡脸功能
弹幕避开人像功能
三．用户需求的处理
对于分类总结后的用户反馈，我们需要做进一步的处理。Bug类别的我们需要输出buglist，并拉通测试研发人员处理。这里我们重点对功能建议类问题和用户疑问类问题和吐槽问题进行处理。通过分析用户对功能的建议和观点，以及对用户疑问项的梳理。分析用户使用路径（谁，在什么情境下，做了什么操作）、总结现在出现的问题、以及现在解决问题的方法以便从用户需求中提取出产品需求。
首先我们需了解目前的版本迭代的方向和重点，了解当前阶段的“产品目标”，这样以便我们知道在当前阶段什么样的功能上线比较重要，什么需求优先级比较高，避免上线的功能对某些主线重点迭代功能的数据造成影响。同时不至于在开发资源有限的情况下，做胡子眉毛一把抓的决定。
2018年哔哩哔哩ios端产品迭代信息
通过我们对全年（2018年）的哔哩哔哩的版本迭代分析总结发现，
①频道方面:（5.27/5.34版本中有迭代优化操作）
②动态方面：（5.19.3/5.25/5.26/5.27/5.31版本中有迭代优化操作）
③视频的播放方面（二倍速、投屏等）：（5.19.3/5.25/5.27/5.34版本中有迭代优化操作）
④弹幕的体验优化方面：（5.22/5.31/5.31.2版本中有迭代优化操作）
⑤手机投稿方面：（5.28/5.29/5.33/5.34版本中有迭代优化操作）
综上通过对功能的更新迭代次数以及迭代目的（提高用户基础体验，改善用户生产内容体验等方面）的总结，我们发现其目前的重点优化方面还是在“频道”“动态”两个模块上。细节的打磨上“视频的播放方面（二倍速、投屏等）”、弹幕的体验优化方面、手机投稿方面为重点。所以与之相关的需求优先级先对都较高。
同时根据时间上我们发现目前（12月9日）距离上次的版本更新（11月11日）有一个月的时间。在5.34版本上重点对“频道”主线功能上有优化，可见这部分的功能相关的用户反馈级别比较高，需要重点关注。
1. 对用户反馈的整理：
这里我们需要利用“金字塔模型”思考，沿着用户任务的闭环路径走一遍，起点由具体的场景出发，后面一系列的动机，终点指向问题的完结（解决方案）。
需求场景分析模型
2.总结归纳产品需求
对于用户反馈的观点和行为分析，需要总结出其目标和动机后来制定我们对应的产品功能来解决用户的问题。因为篇幅问题我们就不展开了，我们得到下面8个产品需求。
用户需求到产品需求的转换
3.产品需求处理流程
需求处理流程
通过上面的流程，我们把还没有在需求池内的需求进行需求优先级的排序。
4根据影响面确定用户需求的优先级
我们需要根据影响面因素对各个功能进行优先级的评定，最后综合出一个与功能相匹配的优先级别。
① 用户量和发生频率
登录帐号的发生频率比较高，“记住上次登录帐号”，“记住上次登录帐号形式”可以降低用户的登录门槛，可以方便用户体验更好的登录模式。发生频率和用户量都比较大，见效也比较快。对于“缓存关键字搜索功能”发生频率比较高，很对用户都会选择缓存喜爱的视频，在没有wifi的情况下查看，所以关键字搜索功能可以更加便捷的方便用户查看缓存，赢得更好的口碑。
用户量和发生频率
②开发难度和效果
从开发难度上来讲，因为需要考虑功能的闭环和流程的闭环两点。对于“短信登录登录、第三登录”来说还需要增加绑定手机号的功能，第三方快捷登录与帐号的绑定功能，流程上还有同一个手机号和三方帐号绑定唯一的流程判断等。所以其开发难度最高。
开发难度
③看产品价值
迫切程度：记住上次登录帐号>记住上次登录帐号形式>缓存关键字搜索>hd版本投稿功能>倍速滑动选择功能>字体大小调节>短信登录，第三方快捷登录
优先级排序：
优先级排序
5.总结录入需求池:
需求池
网友评论