如何在移动应用中有效地收集用户反馈

本文目标：本文从用户体验、开发、运维、成本等多维度分析了移动应用中多种主流的反馈形式，并深入分析了每种反馈形式的适用场景，目的是帮助移动应用开发团队更加合理的使用反馈机制、改进产品。

移动 APP 中获取用户反馈的重要性

根据精益原则，开发一个移动应用，应该是“设计 - 开发 - 上线 - 反馈 - 修改 - 重设计”这样小步迭代的过程，从而保证以最小的成本开发一个成功的 APP。用户反馈作为产品生命周期中必不可少的一环，是决定 APP 走向的重要依据。

Brian Harry 关于软件中收集用户反馈重要性的文章中指出：

反馈帮助你理清对自己的认识。反馈帮助你从新的角度看世界。反馈帮助你纠正偏离的方向。反馈帮助你更好地学习。反馈让你和你的工作更加出色。不论你是否遵从某种特定的敏捷开发实践，早而经常的反馈是让你更加成功的重要因素之一。

与传统的网站应用类似，移动应用中获取用户反馈主要有两种方式：直接反馈和间接反馈。直接反馈，即通过提供调查表、弹出框等形式鼓励用户直接说出自己的想法。间接反馈则是基于用户的使用习惯，间接获取有价值的信息，比如分析界面跳转流程，页面停留时间，按钮的点击频率，用户留存、活跃周期等。本文只讨论第一种。

直接反馈的形式多种多样，隐藏在”设置“里的邮件反馈往往太隐蔽，同时缺乏上下文，让用户不知所措，需要在小小的手机屏幕上输入大量文本信息也是一个很大的限制因素；长长的调查表则让用户望而生畏；频繁弹出的弹出框则让用户抓狂。同时，Alex Adamopoulos 在《反馈的问题》中分析了反馈的代价，他认为，任何一种反馈机制的引入都是需要团队付出相应成本的。因此，如何衡量嵌入的反馈回路是否带来了相匹配的经济利益，如何最大化反馈回路的价值，成了团队不得不考虑的问题。在成本方面，为了降低反馈机制的引入所必需的设计、开发、运维等成本，市场上的第三方服务也比比皆是，比如蒲公英 SDK 。

在给自己的移动产品选择最适合的反馈形式时，产品经理、设计师、开发人员往往都面临着一些挑战，比如：多种反馈形式该如何选择？是自己开发呢，还是选择第三方服务？在反馈前、反馈中、反馈后不同时期团队应该做哪些事情？现有的团队能力是否能满足要求？对于反馈模块所涉及的设计、开发和运维成本能否承受等？

本文从反馈的时间线出发，帮助产品经理、设计师、开发人员等理解给移动 APP 增加一个反馈模块应该考虑哪些问题，以及不同反馈形式的特点、适用场景、开发和运维成本等，帮助大家做出最明智的选择，让小小的反馈模块可以发挥最大的作用，真正帮助产品的成功。

获取反馈前

一：明确目标

产品经理应该非常清楚 APP 是一个什么样类型的软件、现在处于什么阶段、需要从用户那里收集什么样的反馈。

举两个最常见的例子：业务类 APP，比如银行或保险类，更加注重业务本身，更多情况下是想要知道用户对于新推出的业务是否满意。而工具类 APP 更加注重用户对于功能和设计的体验，比如 Uber 进入中国市场后想第一时间知道 APP 的功能和交互设计是否满足中国人的使用习惯；房产类 APP 增加一个”管理自己喜欢的房产的收藏夹“功能后，用户在使用的过程中是否真的带来了便利。

二：考虑成本

项目经理应该非常清楚不同类型的反馈形式会影响到哪些方面，比如需要涉及哪些角色、各自具备什么样的能力，需要花多长时间等，以此来计算成本、组织团队和安排交付计划。

反馈模块主要涉及三部分工作：第一是设计和开发 APP 端作为用户输入反馈内容的入口，第二是设计和开发作为管理员查看和管理反馈数据的后台系统，第三是人工对收集到大量数据的处理与分析，以及与用户的互动等。

所涉及到的成本主要体现在：

• 设计：作为 APP 中反馈内容的入口，也就是对最终用户可见的部分，对于设计的用户体验要求比较高；而作为后台数据管理平台，设计更应该注重实用性，数据分析功能强大、操作简洁而流畅应该是考虑的重点。
• 开发：由于移动应用前后端开发技术的不同，往往是两个开发团队（团队组成跟所用开发技术密切相关，跨平台类 APP 一般所用技术跟后台开发技术比较类似，而原生 APP 的开发技术则相对独立）。如果前后端都需是自行开发，就需要两个开发团队的人共同参与。由于 APP 端仅仅提供反馈内容的输入功能，开发成本相对较低；而后台管理界面需要对收集到的大量反馈数据进行汇总分析和管理，因此开发成本相对较大。不同的反馈形式对于开发人员能力的要求、所需开发时间等都不尽相同，需要具体分析。
• 运维：收集到大量反馈数据后，需要人工对数据进行分析、汇总、分类，提取有价值的信息，从而决定后续的设计和开发如何调整。同时，需要及时对用户的反馈进行回应，让用户感受到自己的反馈是有价值的。

三：确定反馈形式

移动应用中常见的反馈形式主要有下面几种：

1. 邮件方式，即用户从 APP 中打开邮件客户端，通过书写邮件的形式表达自己的反馈。

这种方式最大的优点就是成本低。交互单一，不需要额外设计；开发方面仅仅是 APP 端几行代码就可以搞定，并且不需后台支持。同时，可以直接获取用户的邮件地址，方便回复，因此有利于客户关系的维护。考虑到大多数情况下，能主动选择这种方式提供反馈的用户往往是比较忠实的用户，因此最有可能收集到有价值的数据，甚至是意想不到的点子。

缺点主要在下面几个方面：缺乏上下文，需要离开 APP，有可能造成用户流失；收集到的反馈散落在邮箱里，查看、跟踪、数据分析等都非常不方便。

适合于预算有限、开发时间要求短、开发团队能力有限（通常不具备后台开发能力）的情况。

2. 在用户给予反馈之前做一个小小的选择：是”喜欢我们“，还是”想吐槽“？如果是前者，就会引导用户在 App Store 打五分并写下好评；如果是后者，就在 APP 中设计一个简单而通用的反馈表单，允许用户将文本、图片等信息发送至指定后台。

淘宝 APP

“好事不出门，坏事传千里”。心理学中有一个术语叫“负面偏好”， 相比于正面的信息，我们的大脑通常对负面信息有更强烈、更持久的反应，从理论上来讲我们更加容易受到负面消息的影响。这种方式在获取反馈的同时，还能极大增加 APP 的好评率，同时最大程度降低负面评价的影响范围。与邮件方式相比最大的优势是所有反馈结果可以在自己的后台统一管理，方便查看，以及对反馈的状态跟踪等。

苹果在即将发布的 iOS10.3 版本中将会允许用户在 APP 内进行打分和评论，并自动同步到 App Store。这样就不需要用户离开 APP 去评论了，大大减少了因为评论而流失用户的比率。同时 iOS10.3 还将允许开发者对 App Store 中的评论进行公开回应，加强了与用户之间的粘性。从这就能看出来苹果对开发者和用户之间的反馈闭环的重视程度了。

当然这个也带来了额外的成本，主要体现在后台管理平台的开发上面，需要团队具备网站开发的能力。一个包括最基本数据展示、归类、报表分析、状态跟踪等功能的后台至少需要一个高级网站开发程序员半个月以上的开发工作量。（选择第三方服务的除外）

适合于预算充足、团队具备网站开发能力的情况。

3. 调查表

微信 APP

由于邮件和通用反馈表单通用性太强，除非用户非常清楚自己要表达什么，否则很难有针对性的获得有价值信息；同时，需要手动输入大量文字，在手机上操作非常不方便。很难对收集到的反馈数据进行快速归类。因此，有一种更加智能的方式就是调查表，通过提前列举一系列有针对性的问题，让用户通过勾选方便的进行操作。不仅操作方便，用户易于接受，也能非常高效的获得针对确定问题的答案。同时，后台更容易对结果进行统计分析。

这种方式提前需要确定现阶段迫切需要收集反馈的点，然后设计好问题和表单。如果问题太长，容易引起用户的排斥心理。设计表单和问题是一门比较深的学问，原则是通过最少的提问获得最大的信息量，因此对产品经理有很高的要求。

开发方面，可以嵌入类似金数据的网页类型的表单，不仅可以大大降低前后端的开发成本，同时提供强大的后台数据分析功能。

4. 图片（截屏）、语音、文字多媒体相结合形式的反馈

蒲公英 SDK

由于文本类型的反馈形式在描述一些复杂场景时会给用户带来诸多不便，现在越来越多的 APP 采用截屏、在截图上标注，并结合文字和语音反馈，用户可以在任何时刻、任意界面方便的表达自己的想法，极大的增加了用户主动提供反馈的概率。为了让截屏这一操作更加快捷，除了系统原生的截屏之外，很多 APP 都支持”摇一摇“来触发截屏的功能。截屏反馈设计上最大的优点是不需要占用任何屏幕空间，可以被广泛采用。

语音反馈的缺点是运维成本较大，需要人工对收集到的大量语音进行分析和归类。降低运维成本的一个方法是在 APP 端进行语音解析，也就是在用户输入语音后，先转换成文本信息再发送，相当于把解析工作交给了用户来完成，用户体验上会大打折扣。

由于在手机上发送语音对用户所处场景有要求，因此，语音反馈通常与其他类型的反馈混合使用，允许用户自行选择。

5. 结合 NPS 的基于上下文的反馈

为了在用户体验与反馈效果中达到平衡，作为Design in Context概念的延伸，我们建议采用基于上下文的反馈机制，即：基于特定场景和特定用户来确定反馈的形式、内容、入口以及出现的频率等。 NPS （Net Promoter Score）是常用的一种判断用户忠诚度的方式，通过一个简短的问题“你是否会把此产品推荐给你的朋友？”，将用户分为三类：“推荐者”，“被动者”，“贬损者”。然后再继续向“推荐者”提问更加深入的问题，真正做到了“向最有可能提供反馈的用户获取更有价值的信息，而不惹恼普通用户”。因此，是我们更加推崇的一种方式。

在用户多次使用某个功能后，先通过 NPS 获取用户对于此功能的喜好；然后基于用户的回答（喜欢，或不喜欢），来深入问几个更有针对性的问题，同时确保反馈模块的有一个友好的设计（应该避免弹出框这种侵入性非常大的设计）。

这种方式可以在短期内收集到大量有针对性、有价值的反馈数据，特别适合于在某个新功能上线后一段时间内使用。

Airbnb

收集反馈中

及时回复用户反馈

现在，APP 已经成功的集成了反馈模块，产品经理的工作从此又多了一项：不断的查看邮箱，或者后台反馈数据管理系统，来获得第一手用户反馈信息。然而，仅仅是“看”还远远不够。不管用户的反馈是好评，还是是建设性意见，亦或是批评，他们都是花了自己的时间和精力，也会想知道自己的反馈是否被看见、是否被重视等。因此，及时回复用户反馈对提高用户满意度是至关重要的一步。

第一是在收到用户反馈后第一时间告知用户已经收到其反馈，并且会及时处理，同时真诚的表达感谢。第二是在分析完反馈内容后及时跟用户取得联系，有可能是对用户问题的解答，或者是对其意见的处理计划或结果等。第三是当用户的建议被采纳并正式上线以后，应该通知那些苦苦等待的用户，不仅让他们可以更好的使用 APP，也能感受到自己建议被采纳的喜悦。

邮件往来是一种最不会打扰用户的方式，因此这里要注意，任何一种反馈形式的设计，都要考虑可以获得用户邮箱地址，以便后期跟踪。

Note：为了节省开发成本，还可以选择使用已经比较成熟的第三方服务，大部分成熟的第三方服务不仅提供多种 APP 端的反馈界面，也包括后台强大的反馈数据管理功能，因此可以大大降低开发成本。其缺点是样式和功能很难定制化，而且数据安全性无法保障。因此对于有自己独特设计要求、对反馈数据安全性要求比较高的团队，应该谨慎选择。

反馈后

分析反馈数据，调整 APP 走向

“面对反馈，我们需要正确的态度——拥抱改变，不要害怕返工“。因此，最后一步，便是对收集到的大量反馈数据进行汇总、归类、分析，来发现产品中存在的问题，并对问题进行归类和优先级排序。如果有必要，还需要进一步对得出的结论进行用户调查和访谈，以此制定下一步的开发和发布计划。

总结

总体来说，在 APP 中增加一个反馈模块不是一件简单的事情。反馈前，明确目标，综合考虑功能和成本以此来制定反馈形式、确定反馈入口、出现时机和频率后，便可将反馈模块成功集成到 APP 中。反馈中，及时表达对提供反馈用户的感谢并随时通知其最新进展。反馈后，对反馈结果进行大数据分析，从而有效的调整产品进一步的走向。只有每一步走的踏实，才能让反馈模块真正的发挥作用，让用户越来越喜欢你的产品。

感谢张凯峰对本文的策划，徐川对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。