上回咱们讨论了在App内设计反馈评价类模块的思路,从路径到模块架构、到设计细节,今天想继续聊聊收集到用户反馈后如何整理分析,并转化为对产品改进的建议。
一、明确分析用户反馈的目标
上篇文章中有介绍,在App中设置用户反馈模块,主要是为了了解用户在使用过程中、乃至在完成某个任务的某个界面中的感受或问题,从而为产品改进寻找方向与建议;其次,用户对商品、司机等内容或服务的评价,也可以形成内容闭环,辅助其他用户进行决策、辅助平台进行曝光/分配。
那么我们在分析用户反馈的过程中,也应该奔着这些目标来做:
1、以是否能帮助产品设计开发人员了解用户使用情况、对产品改进是否有帮助为衡量点,筛选用户反馈内容;
2、以应由公司哪些团队跟进反馈问题的解决来对问题进行分类;
3、决策反馈内容的优先级,进而排期推进解决;
4、针对评价类内容,以直观的数据、详尽的图文等形式展示出评价结论/内容。
本文着重介绍反馈类内容的整理与分析。
二、分类整理
根据上面总结的目标,实施过程中我们首先需要对反馈内容进行筛选、分类、打标签,将杂乱的反馈内容条理分类、赋予属性。具体来说:
第一步是筛选用户反馈,剔除恶意差评、同一用户同一任务连续重复评价、无意义数据;
第二步要确定分类标准,先前文章介绍的在反馈模块中可以按照主题/问题类型来进行分类收集反馈,也是便于在这个阶段分类整理反馈内容。
具体分类标准的制定,可以有很多维度:
- 按主题来分,其实就是按照功能点/业务场景/业务线来分,如果是在功能流程中增加了反馈入口,这种是比较贴合的分类方式。
- 按问题类型来分,有情绪表达类、问题类、功能改进类、运营内容改进类、新功能类等等类别。可以根据公司部门结构、运营内容来确定一级类目及具体二级类目。
比如用户就是觉得用得不爽是情绪表达类,情绪背后的原因我们可以关注。再比如产品可用性/体验上遇到的问题、对定价/计费的意见、对平台内容的意见、遇到的bug/性能问题等,都属于按问题类型来进行的区分。
可用性/体验类问题分类的时候可以借鉴尼尔森十原则、用户体验五要素等原则/体系,来辨析问题是违背了哪条原则、属于哪一要素层级,也有助于系统地理解产品、寻找对应团队解决该问题。
第三步,其实是第三点需要关注的事项:用户反馈要与用户属性挂钩,获取用户反馈数据的同时应记录下用户的属性信息,越熟悉产品、使用频率越高的用户越了解产品、提出的意见也会越中肯、越深入。
比如用户使用产品的时长、使用服务的次数、消费过的金额、偏好属性,用户属于僵尸用户/新用户/留存用户/高价值用户,都可以作为关注的用户属性标签,并据此给反馈问题打上权重。
除此之外,还可以使用语义分析的方式,对收集到的文本内容进行分析,可以得到关键因素及其之间的相关关系,在此暂不展开描述。
三、分析、提炼、行动
针对问题类反馈,按以上分类标准对问题分门别类后,就可以逐个分析反馈问题了,分析的时候有几个关键因素:
- 问题发生频率——可以通过反馈该问题的用户数、用户属性,用户描述的发生频率等关键点来分析;
- 对体验影响程度——可以分析问题的严重程度,同时结合用户描述的情绪、满意度来进行决策;
- 影响用户范围——可以通过反馈该问题的用户数、用户属性,对应业务线的成交量、UV、PV等来进行预判;
- 对核心业务/品牌影响——同样可以根据对应业务线的成交量、UV、PV,以及该业务的重要程度来判断;
- 实现成本——这点主要需要与研发讨论判断;
结合以上因素后可以给用户反馈内容排P0、P1、P2、P3以及待调研的优先级,优先排期讨论解决高优问题。
当问题解决后,有途径的话可以反馈给用户、最好是当初提出该问题的用户,这不但可以体现产品的不断迭代优化、提升服务的理念,也有助于体现产品对用户意见的关注,进而拉近用户与产品的心理距离、提升用户对产品的信任。
划重点
本文抛砖引玉,根据分析用户反馈的目标,剖析了筛选、分类、分析反馈内容的关键点:
1、分类标准可以有多个维度,比如可以根据用户使用场景、根据业务线、根据问题类型等维度为问题打标签,便于后期分类汇总、提供给对应团队解决;
2、要关注进行反馈的用户属性,高价值、高频用户的反馈内容会更具深度;
3、根据发生频率、影响程度、影响范围、实现成本等评估问题、排优先级,进而排期解决;
4、问题解决后,可以通过宣传口径、新功能提示模块、评论回复等渠道反馈给用户,传递产品对用户意见的关注、对产品体验的不断追求。
本文原创,未经作者允许不可转载!
更多内容,欢迎关注作者微信公众号:海盐社!
暂无评论
违反法律法规
侵犯个人权益
有害网站环境