功能解析用户反馈模块搭建附原型模板

　　用户反馈功能，可以说是我们的产品，尤其是移动端产品，必不可少的一个功能了，这个功能是获取用户直接需求的重要途径。我们今天就一起来研究一下，此功能模块是如何搭建的吧
　　场景
　　我们先来看一下用户使用此功能模块的场景：用户在使用产品的过程中，遇到了某些问题，这些问题可能是产品使用方面的，也可能是业务理解方面的；
　　总之，用户使用产品时遇到了障碍。这个时候，用户是多么迫切希望能够有一个途径，帮助自己解决问题，因此用户反馈功能应运而生。
　　较真一下，将此功能以反馈二字命名，总感觉有些怪怪的。个人觉得反馈更像是一个单向的过程，只是AtoB，to完以后，就没有以后了
　　这让我想起了在电视剧中看到的那种意见箱，里面也经常塞得满满的，都是人民群众的反馈意见信，结果呢？大家脑海中可自行脑补此场景
　　所以，与其说是用户反馈，我觉得用户更希望得到的是一个留言互动的功能：自己有问题提出来，可能由于现实情况的制约，不一定能够及时得到解答，所以可以是留言；
　　但每一个提问题的用户，都肯定希望能够得到回复，不然人家还提问题干嘛，直接卸载拉倒，所以用户也希望能够得到互动！
　　好了，我们回归主题。既然大家都叫做用户反馈，那我们也随波逐流吧，此篇文章，我们讨论的内容，依旧叫做用户反馈
　　产品参考
　　本来写这段内容的时候，情不自禁的想写竞品分析四个大字，可转念想了一下，小弟配不上啊
　　因为笔者查看的都是淘宝、支付宝等这些互联网班级里面的尖子生，我一个渣渣辉，岂敢跟大佬们谈竞品。（小弟只是学习学习，膜拜膜拜，参考一下大佬们的产品，抱紧大佬们的大腿，仅此而已）
　　笔者一共参考了9个产品，分别为：淘宝、支付宝、知乎、智联、BOSS、马蜂窝、抖音以及qq。
　　我们选取其中的三个产品，一起来分析一下吧：
　　1。马蜂窝常见问题与反馈
　　1。1分析对比
　　我们可以看到，马蜂窝此处的功能是比较简洁的。我们来解剖一下，其实从功能上进行归类，就只有两部分，一是问题的列表，二是留言反馈功能。
　　其中问题加入了问题类别的字段，然后留言反馈是以对话框的形式。
　　1。2功能框架
　　我们给这三个界面脱去美丽的外衣，来看一下他们的骨头架子，就是这样的：
　　俗话说，没有对比就没有伤害，只看这一个产品，我们无法评判，我们就继续往下看吧
　　2。BOSS直聘帮助与反馈
　　2。1分析对比
　　首先相同的是，界面上都是问题类别的列表。
　　然后BOSS上面，增加了搜索框的功能，就是笔者自己标注的那个地方，因为一个界面无法截全。
　　这个功能做的还是很有必要的，大家想啊，如果一个用户的问题很清晰，然后在问题的列表框中，一时半会又没能够找到自己的问题，然后咨询客服吧，又不能得到及时性的回复，此时直接搜索自己的问题，快速地寻找现成的答案，就显得非常必要啦。
　　第三点有所不同的是，此处的反馈采取的是信息列表的形式。
　　2。2功能框架
　　又到了脱的环节了，我们来看一下：
　　通过以上两个产品的分析对比，我们可以看到反馈的形式有两种，一种是对话框的形式，另外一种是信息列表的形式。笔者思考了一下，得出如下两条结论，不知道大家是否赞同：
　　信息列表的形式，相较于对话框而言，便于数据的收集与整合，是常见问题的数据来源基础；
　　对话框本身让人感觉是一种一问一答的及时反馈形式，在没有AI客服的情况下，我们最好采用信息列表的形式，来处理这种延时性的用户反馈。
　　3。淘宝问题反馈
　　3。1分析对比
　　淘宝将用户反馈的处理方式分为了两类，一类是及时性的AI客服，另一类是延时性的问题反馈；
　　在联系客服中，首先展示的依旧是猜你想问，此处和常见问题的功能如出一辙；
　　我要反馈界面中，不仅有问题描述和图片，还加入了问题类别。
　　3。2功能框架
　　我们可以看到此处简直是骨骼惊奇呀！
　　想得到及时性的反馈，可选择AI客服功能；没有及时性要求，或者AI客服无法解答的，可选择问题反馈功能。
　　并且强大的AI客服，聊天对话功能可以说是自带搜索能力；界面上无处不在的各种问题引导，不仅能帮助用户准确定位问题，还可以帮用户拓展知识；
　　我要反馈界面中的问题分类，将数据进行了第一次的过滤，减轻了人工的维护成本。
　　试问，一个用户反馈功能，除了以上内容，我们还能加入其它的么？简直是完美！
　　BUT，偏偏这么完美的功能中，还是让我发现了一个槽点：
　　大家看，就是这里，笔者刚刚提交过一个问题反馈，但在我的反馈中，却没有找到我提交的记录看此处字面意思，也许是提交的内容如果没有受理，那么就不会显示出来？
　　笔者想不大明白，淘宝是出于何种考虑，将此处功能设计成这样。但是笔者切身感受，此处以用户体验的角度，批评一下淘宝同学
　　好了，以上我们对于三个产品进行了分析，大家如果有兴趣的话，可以自行查阅其它产品，其实内容已经是大同小异了
　　接下来我们思考一下两个问题：
　　一个完整的用户反馈功能模块，都需要包含哪些功能呢？
　　为什么不同产品的用户反馈功能会有这么大的差别呢？
　　用户反馈功能框架
　　ok，我们来直接说结论，看结论的过程中，大家可自行体会，以上两个问题是否解决。
　　我们根据用户反馈模块中，数据量级的大小，将用户反馈功能分为三个阶段，笔者也想不到什么高大上的命名，就以阿拉伯数字命个名吧
　　第一阶段
　　定义：
　　产品的初始阶段，无用户反馈数据的积累，用户反馈的数据增量也不是很大，此阶段可采用人工线下回复的方式。
　　框架：
　　说明：
　　最简单的一个框架，我们可以看到，不少新上架的小型APP，会采用此种框架。
　　文字描述是必填项，图片和联系方式都是选填项，此种框架，只能等待着工作人员进行线下回复，前提是，用户还需要暴露自己的联系方式。
　　第二阶段
　　定义：产品已经有了一定量的用户反馈数据积累，此时可以将积累的反馈进行归纳总结，整理成常见问题，对于新的问题，可采用线上人工回复的方式。
　　框架：
　　说明：
　　常见问题可以包含搜索和分类，这个两个功能我们文中提到过，不再赘述。
　　至于换一批的功能，其实说的是一种交互体验，一个界面的空间有限，如果常见问题比较多，我们总不能让用户一直下滑加载吧，直接一个换一批按钮，简单好用
　　既然此阶段采用的是线上人工回复的方式了，那么用户提交的反馈内容，需要有一个地方来查看历史记录吧，这也正对应了，我们开头提的互动二字！
　　说到此处，对于我们的支付宝同学，笔者也想叨叨两句支付宝在用户反馈的功能中，竟然没有历史记录可以查询就是我们前面提的AtoB，to完以后，就没有以后了的情况。
　　此处，笔者作为支付宝的忠实用户，对此功能设计，进行点名批评
　　第三阶段
　　定义：产品有大量的用户反馈数据积累，此时我们可建立AI客服系统，进行自动回复。并且，当问题超出AI客服回答范围时，可转人工客服进行回复。
　　框架：
　　说明：
　　此处就强调一点，无论是通过信息列表，还是通过对话框的形式，反馈的历史记录是一定要保存的，绝不能够to完以后，就没有以后了
　　另外说一下，客服系统，可以说一个专门的领域，我们此处不展开
　　结语（小福利）
　　笔者自己总结整理了一下用户反馈的原型模板，大家可下载查看。
　　本篇文章如果对您有所帮助的话，也希望您能够赞赏一下晓庄同学，这将是笔者不断前进的动力源泉。当然，有任何不足之处，也希望大家能够批评指正
　　另外关于原型总结方面的知识，有兴趣的同学，可前往查看笔者的另外一篇文章《以封装的思维，来做原型》。
　　链接：https：pan。baidu。coms1EhMNNon861MccOKaj1g；提取码：s460