规范意见箱操作的通知（小功能也有大门道）

2015/11/20

阅读（1119）

评论（2）

收藏（8）

加入人人都是产品经理【起点学院】产品经理实战训练营，BAT产品总监手把手带你学产品

反馈是几乎所有应用的标配功能，往往藏在“设置”或者“关于”里面的小角落。意见反馈在产品开发中的作用是不能忽视的，这几乎是所有应用最好的用户意见收集入口，但是不同应用对意见反馈的处理各不相同。最近在做反馈系统的梳理工作，也包括意见反馈页面优化，将这一段的分析整理成此文。

本文仅仅分析常见应用意见反馈的不同形式，并没有展示意见反馈的优化设计方案。需要讨论者请私下联系。

0.【邮件型】

很多国外应用和国产老牌应用的用户反馈方式都是：点击“反馈”按钮 >> 进入邮箱服务 >> 自动填写收件人和一部分正文内容（机型等信息） >> 用户补全信息 >> 发送邮件。

邮件类的设计思路应该来源于投递举报信，在开发者和用户没有那么多沟通途径的时候，邮件是不错的选择。再加上一定的过滤和筛选，通过邮件来管理用户反馈也能在一定程度上提高效率。

邮件类的劣势在于，国内大多数用户对于邮箱（特别是手机端邮箱）的使用熟悉度不高，大多数邮箱应用（特别是android系统自带邮箱）的界面不友好。因此本类不做深度讨论，面向国内人群的应用也不建议采用邮件类的反馈方式。

1.【原始表单型】搜狗输入法

表单类实际上是邮件类的升级：

1. 不需要填写发件人
2. 通过修改表单格式，相当于固定了邮件正文格式，更方便管理

但是表单类也存在问题：

讨论具体案例：

搜狗输入法的意见反馈是最标准的反馈表单：

1. 反馈内容（必填）
2. 联系方式（选填）
3. 附件（搜狗是词库，其他应用还可以添加截图等）

相比邮件的形式，表单类形式无疑先进不少。但原始表单类仍然有以下问题：

1. 填写仍然是一个高门槛的操作，反馈内容的编辑自由度如此之高，那么用户一定会反馈一大堆“垃圾”、“不好用”等评价
2. 联系方式选填，就意味着仍旧联系不到任性不填的用户，当然能获取到用户手机号的话另说
3. 表单类的意见反馈是面向开发者的功能，不是面向用户的
4. 需要人工审核每一条意见反馈，不便于定位问题

本来意见反馈的作用就是开发者收集用户意见，便于后续迭代。因此本文将优先讨论意见反馈面向开发者的功能。

为了方便开发者收集用户反馈，表单类进化出各种形式：

2.【分类表单型】网易云音乐

网易云音乐讲问题分为三大类：产品建议、程序错误、缺少音乐，分别对应产品、开发和音乐库。可以想象网易云音乐对这三类反馈的处理方式：程序错误类有反馈就解决，产品建议一周一评估，参考其中有价值的意见，缺少音乐类型的建议可以作为版权投资的指导建议。

但是对于用户量更大的产品而言，这种分类可能仍然太粗线条了。以程序错误为例，播放过程中程序闪退和界面显示bug就是完全两类问题，网易云音乐的反馈处理人员需要手动筛选才可以。

对于中小型产品，每天用户反馈数目不多，产品经理只需要定时查看一下用户反馈就可以了。对于大用户量的产品，一天的反馈数目可能成百上千条，反馈内容涉及不同产品线，对应不同的产品经理，如果只有一个人处理反馈，按网易云音乐这种粗略分类的方式，该员工可能要花数小时才能将一百条意见筛选、分类、递交给不同产品组。

为了优化该流程，有一些应用会提供更细分的问题分类。

3.1 【细分表单型】360手机卫士

360手机卫士列举了九个主要问题类型，其中前七个类型应该来源于历史反馈最集中的几个问题。

点进“手机卡慢”的选项，手机卫士还会给出一些手机卡慢的解决方法。当然大段的文字描述不是好的交流形式，但至少比网易云音乐更进一步，希望在用户反馈之前，先帮用户解决遇到的问题。注意第一页最下方的绿色小字，360安全卫士提供了“常见问题及解决方法”，这就是从用户角度出发，对意见反馈的改进。不过考虑到大段的纯文字描述和移动端体验糟糕的论坛原帖，该处仍有很大的优化空间。

这也提醒我们从用户角度来分析意见反馈。从使用场景来分析，用户在什么情况下会进入意见反馈页面。用户主动进入意见反馈页面有两种主要可能：

1. 使用过程中遇到某种不便，又不至于卸载该应用，遂进入意见反馈寻求帮助
2. 使用过程中得到极大愉♂悦，向开发者表达感谢

在日常工作中，表达感谢的用户反馈数量极少，用户更习惯在社交网络上完成表达感谢的工作，还能顺带秀一下自己使用优质应用的优越感。

当用户遇到不便时，用户的需求有哪些？按我的理解，优先级从高到低排列分别是：

对于用户而言，某个或者某些功能难以使用的时候，首先想到的就是“那群傻X开发者赶紧优化这功能啊”，言辞之中自然带有发泄情绪的色彩。除非给与用户一些物质奖励，否则反馈报告对于用户而言几乎毫无价值——得不到开发者任何反馈不提，用户遇到的麻烦甚至不知道什么时候能够得以解决。总之对于用户而言，这种情形下得到帮助的需求远远大于反馈问题的需求。

3.2 【帮助反馈型】百度手机助手

百度手机助手将帮助的功能放在极为明显的位置，用户点进帮助与反馈的页面，发现里面绝大部分的区域是常见问题及解决方案，只有点击上方“我要反馈”按钮时，才会进入原始表单型的问题反馈页面。

在考虑用户发泄情绪的需求，与其说让用户发泄情绪，倒不如说安抚用户的情绪。用户心情平静下来，相对而言就不太会反馈一下“垃圾”“不好用”等无意义的话。

4【情感化设计型】享应

享应是我一直很喜欢的一款应用。除了很方便发掘优质应用以外，享应的设计和交互细节也做得很棒，而建议反馈页面更是给人以惊喜。

个人觉得很多开发者进入一个误区，情感化设计就等于卖萌耍贱。以享应为例，使用这种体验优质的应用的用户素质也不会低到哪里去，用户来反馈问题往往也是真的想反馈什么问题，相对来说纯吐槽的比例会小一点。但是对于其他应用，类似于悬浮窗、常驻通知栏、广告等对用户造成打扰的功能功能，甚至是涉及到支付等财产相关的问题时，卖萌耍贱就显得开发者不那么专业化，反而会造成负面影响。

以微信为例，这种面向普罗大众的应用，就不能用卖萌耍贱这种往往只有年轻人会接受的方式来进行设计。大家还记得“点赞太容易，当面夸太难”这句文案吗，当初看到的时候几乎泪目。这就是走心的设计，是从普罗大众都会使用的功能点切入，引出另外一个普罗大众都会遇到的社会化问题。这种情感化设计就是神级的情感化设计。惭愧本人曾做过一段文案编辑，写下无数的卖萌耍贱的文案，但却从来没有写出过走心的文案。有时间单独谈谈本人对“点赞太容易，当面夸太难”的理解。

在我做出产品优化方案之后，同事提出了一个非常好的意见，他建议把情感化设计应用到收集联系方式的地方。比如用漂亮小姑娘的头像来诱骗用户留联系方式等等。可惜在现有的设计上这样添加可能会导致页面排布比较混乱，丢失重点，如果有机会重做，一定要把这一点考虑进去。

谈到微信，就不得不说一下微信的意见反馈。微信的意见反馈是我体验过的产品中，交互最多、流程最长的意见反馈。

5【选择型】微信

微信把各种问题提炼出关键词，通过三步选择，进入最后的问题描述。这种方式好处就是问题定位比较准确，运营人员的工作量肯定大大减小。

但是，我们要考虑用户使用场景。什么情况下用户会使用意见反馈功能？是他遇到某个功能不方便，一肚子怒气，找到意见反馈进入喷子模式。也就是说，用户在进入意见反馈之前就几乎已经想好自己要反馈什么内容了，用户本能需要的是一个输入框，而不是阅读大量的文字进行选择。

同时，选项的方式更适合对现有问题的优先级排期，文字输入更容易发现新问题。

微信有先天优势，用户不需要单独添加联系方式了，微信号很方便就能获取。另一方面，有很多自带IM的中小型产品，会将意见反馈以官方客服号 IM的形式结合起来。

6.1【官方客服型】SAME

6.2【官方客服型】新浪微博

新浪微博的用户反馈相当于在对应话题下发一条微博，虽然无伤大雅，但是我觉得蠢爆了。一来里面带的一些信息我不太希望别人看到，二来这样一条微博插在我的微博流里面也怪怪的。不知道微博作何考虑。并且这种方式效率几乎等同于原始表单型，为什么微信就算有微信团队的官方号，也没使用它作为主要的反馈渠道，应该就是出于处理效率的考虑。

官方客服型的优势是显而易见的，就是方便开发者联系用户。顺着用户说的第一句话，交流自然而然发生。缺点也很明显，就是运营人员的工作压力会很大，相比原始表单型，运营人员除了要收集数据以外，还要承担大量的沟通用户的工作。

7.1【偷懒型】数字尾巴

7.2【偷懒型】36kr

我原以为数字尾巴这种直接放一个论坛页面就是挺偷懒得了，没想到36kr甚至直接放上去了自己在fir.im的页面，上面甚至找不到反馈入口。博君一笑。

8.【交互篇】360手机助手

上面的分析仅仅针对样式设计讨论，没有针对交互讨论。对于简单的表单型或者IM型意见反馈而言，交互不过就是点击反馈按钮 >> 进入反馈页面，但是对于一些需要对问题进行分类的意见反馈而言，交互就很重要了。

以360手机助手为例——

作为国内最大的应用市场，360手机助手的用户反馈竟然是这个样子。除去老旧的界面风格不提，其中最值得吐槽的点一共有三处：

1. 共提供qq/手机号/邮箱/MSN/旺旺/飞信七种形式，但是实际上除了前三种，后面四种使用人数微乎其微，并且这里还需要用户手动选择一下。正确的做法应该是只留下手机/qq/邮箱，并且不需要用户手动选择，由运营人员人工识别。
2. 设置分类：这种形式必然导致大部分反馈集中在“默认”分类里面，设置分类形同虚设，必定大大增加了运营人员的工作量。
3. 清除：直接点退出就好了，这属于设计的冗余点，虽然不算严重槽点，但也不排除误触。

这个页面除了输入以外，用户需要进行的操作非常之多，违背了“一页只做一件事”的原则。

同时，该页面提交反馈以后，下一步显示的页面是首页侧边栏，同时toast提示“反馈已提交”。

我认同一个设计方法，就是用户在执行每一个操作的时候，实际结果要和心理预期相近。因此提交反馈之后突然跳转到首页侧边栏的作法，在我看来是非常不好的。当然这是体验层面的工作，无伤大雅，但是用户真的会有错愕感。对于一个用户量级非常大的应用而言，体验问题就不像凭借创意和功能门槛的小产品那么优先级靠后，产品人员要认真对待每一个造成用户负面心理的细节。

个人认为，提交反馈之后，要么跳转到自己的反馈列表，要么弹窗询问继续反馈/回到首页，都是不错的选择。

总结

综合各种形式，结合细分表单型方便运营人员归纳整理，和客服型方便进一步沟通的优点，以细分表单型作为反馈入口，反馈成功后把该反馈工单作为一种消息形式，插入到官方客服的对话当中去，应该是效率最高的方式。

但是考虑到应用的用户量、开发成本等等，对于中小型用户量的应用而言，简简单单采用常规样式就足够了，例如友盟等第三方服务也会提供很方便的IM形式的反馈工具。

作者@红二 授权转载

,