根据精益开发原则（lean development principles），开发移动应用是一个包含一系列阶段的过程，其中包括：设计、开发、发布、反馈收集、修改直到重新设计等等，目的是确保以最低的成本成功开发应用。用户反馈是产品生命周期中不可或缺的一部分，是决定产品演进的基础。
微软技术研究员Brian Harry在其《软件开发中反馈的重要性》（The Importance of Feedback in Software Development）一文中指出：
反馈有助于整理您对自身的理解。有助于您从一个新角度来看待这个世界，纠正偏离的方向并学得更好。此外，反馈让您更出色，让您更好地工作。无论是否遵循特定的敏捷开发实践，较早和频繁的反馈是让您更加成功的重要因素之一。
这就是Harry在其文章中描述的反馈周期。
与传统的网页应用一样，在移动应用中获取用户反馈有两种主要方法：直接和间接反馈。直接反馈是通过鼓励用户直接陈述他们对应用的看法来收集，通常是以调查问卷或弹窗的形式出现。间接反馈是基于用户行为的分析，比如用户在用户界面中如何移动、在页面上花费的时间、点击频率、用户维系和活跃期等等。本文将着重于第一种反馈。
直接反馈的形式有很多种，各有各的复杂性。电子邮件反馈选项经常隐藏在移动应用的“设置”中，这样就会缺少上下文，很难让用户提供有针对性的看法。在小小的手机屏幕上输入字符信息也是一个很大的限制因素。与此同时，长长的问卷调查吓跑了用户，并且太频繁的弹窗也让用户抓狂。Emergn Limited的创始人和首席执行官Alex Adamopoulos在其《反馈哪里出错了》（What’s Wrong with Feedback）中分析了反馈成本。在他看来，任何反馈机制的引入都需要团队付出代价。有鉴于此，如何衡量一个嵌入式反馈回路是否带来了充分的经济利益，以及如何最大化反馈回路的价值是关键问题。此外，另一个要考虑的因素是第三方服务的可用性，以削减设计、开发和运营反馈机制所需的成本，例如pgyer和市场上的其他参与者。
总之，产品经理、设计人员和开发人员在为其移动产品选择最合适的反馈方式时，经常会面对这些复杂的问题：如何在不同的反馈方式中进行选择？开发一个自有的反馈机制还是依靠第三方服务好？团队在收到反馈的前后应该做什么？团队是否具备开发和运营所需的能力？能否负担反馈的设计、开发和运营成本？
本文旨在根据反馈生命周期，帮助产品经理、设计人员和开发人员了解给移动应用添加反馈模块时应当考虑的问题，以及典型的设计、开发和不同反馈机制的运营成本。因此，它将有助于从最小化反馈模块到完整的调查问卷中做出最便利的选择，并有助于塑造产品的成功。
收集反馈之前
指定目标
产品经理应该非常清楚其应用所属的类别、目前所在的生命周期阶段以及从用户那里需要收集什么样的反馈。
举两个最常见的两个例子：
- 比如，银行或保险行业使用的应用，更关注其核心业务，通常希望知道其客户是否对其提供的服务感到满意。
- 生产力应用，其功能和设计更注重用户体验。一个具体的例子就是Uber，首先，其希望知道其应用的功能和交互性设计是否符合用户偏好。或者，一个房地产管理应用也许希望了解其用户是否觉得一个新的“添加到收藏夹”功能有用。
成本考量
项目经理应当非常清楚不同的反馈机制意味着什么，比如：谁是利益相关者、需要什么样的技能、需要多少的努力等等，为的是计算成本、组织团队以及安排交付计划。
给一个应用添加反馈模块主要涉及三项任务：首先是设计和开发该应用的用户界面，给用户反馈一个入口；其二是设计和开发一个后端系统，用于查看和管理反馈数据；第三是处理和分析通常是那些收集到的通常数量巨大的数据，并与用户进行交互。
这个过程涉及的成本主要体现在三个层面上：
- 设计：用户界面在应用中用于收集反馈，作为对终端用户可见的部分，在用户体验方面有更强烈的要求。对于后端，数据管理平台来说，设计应当注意实用性，着重强大的数据分析功能，易于简单逻辑操作。
- 开发：因为在前后端采用不同的开发技术，所以经常会涉及两个开发团队。无论如何，团队的组成跟所使用的具体开发技术密切相关。一般用于创建跨平台应用的框架、开发语言和工具通常跟那些用于后端开发的类似，而用于本地应用的框架、开发语言和工具更为异构。如果要求独立开发前后端系统，那么就需要两个开发团队。由于应用只提供反馈输入方式，其开发成本相对较低。另一方面，后端管理系统必须为大量的反馈数据提供汇总、分析和管理能力，其开发成本相对较高。不同的反馈方式对开发人员的技能和开发时间有不同的要求，需要具体的分析。
- 运营：在收集了反馈数据后，需要进行分析、汇总和分类，以提取有价值的信息，从而推动应用的后续设计和开发。与此同时，有必要及时回应用户反馈，那样他们会感到自己的反馈是有价值的。
反馈形式的选择
移动应用中常见的反馈形式主要包含以下这些：
电子邮件
在这种场景下，用户从应用打开邮件客户端，通过写电子邮件表述他们的反馈。
用这种方式收集反馈的最大好处是其成本低，单一的基于标准设计的交互。在开发方面，只需要几行代码就能处理这个机制，对后端没有要求。同时，由于有了用户的电子邮件地址，易于回复，这样便于维护客户关系。考虑到大多数时候，愿意发电子邮件提供反馈的用户往往更忠诚，更有可能的是他们提供了有价值的数据，甚至是意想不到的想法。
这个方法的缺点主要是先得退出应用，这可能导致用户根本不提供反馈。此外，收集到的反馈散落于邮件中，不便于后续的审查、跟踪和数据分析。
对于预算有限、开发时间不够、抑或对于后端开发来说，开发能力不足的团队，这种方式就适用。
在征求反馈前，询问用户是否喜欢该应用
这个可以通过给用户一个二选一的选择：“喜欢”或“不喜欢”来实现。
如果选择前者，用户将被引导给个5分，并在应用商店（App Store）中留下评论。如果选择后者，那么就在应用中显示一个简单寻常的反馈表，允许用户发送文本、图像或其他信息到指定的后端。
在获取反馈的同时，这个技术能大幅提升对应用的正面评价率，减少负面评价的影响。这可以用流行的谚语“坏消息有翅膀”来解释。事实上，心理学里有个术语叫“负偏见”，被用来描述和正面信息比较而言，对负面信息我们的大脑如何总是有更激烈和更长久的反应。在理论上，就是我们更容易被负面消息所影响。
与发送电子邮件的方式相比，这技术最大的优点是在后端能以相同的方式处理所有的反馈，也更易于查看、跟踪反馈状态等。
当然，这也会带来额外的成本，主要体现在后端管理平台的开发上，需要团队具备网站开发能力。一个集成了显示、分类、语句分析和状态跟踪基本功能的后端至少需要一个高级网站开发程序员半个多月的工作（使用第三方服务的情况除外）。
当预算充足并且团队有网站开发能力的时候，这种方式是合适的。
调查问卷
微信
电子邮件和一般的反馈有很强的共性，那就是，除非用户很清楚他们想要表达的，否则很难获得有针对性的、有价值的信息。同时，这两种方法都需要输入大量的文本，不方便在手机上操作。此外，这难以在后端对所收集的反馈进行快速分类。与此相比，更有效的反馈收集方法是利用调查问卷，调查问卷列出了一系列有针对性的问题及多项选择答案供用户选择。如果互动是简单的，用户就会很乐意回答问卷。同时，在后端就更容易对结果进行统计分析。
这种方法需要提前确定在应用开发现阶段反馈更为迫切的反馈点，然后设计问题和格式。如果问题太长，容易让用户感到厌烦。设计格式和问题需要深入的了解，原则是利用最少的问题获得最多的信息。
在开发方面，可以用类似网页的格式，这不仅大大降低前后端的开发成本，也提供了强大的后端数据分析功能。
内容丰富的集成了图像、语音、文本和多媒体的反馈
Pgyer SDK
在描述某些复杂场景时，由于用户不方便使用文本反馈，越来越多的应用采用了截屏、在截屏上注释，允许将文本和语音结合在一起反馈，这样用户可以利用应用用户界面的任何部分随时表达他们的想法。这大大增加了用户主动提供反馈的概率。为了更快地截屏，除了系统默认的截屏功能外，很多应用支持“摇一摇”手势来触发截屏。截屏反馈的最大优点之一就是无需使用占用任何屏幕空间的专用控件。
由于对大量收集的语音记录的分析和分类，语音反馈的缺点是操作成本高。一个降低这种运营成本的方式是在应用中进行语音分析。也就是说，在用户录下其语音信息后，应用在语音识别技术的帮助下，首先将其转换成文本信息，然后把结果发到服务器。这将把验证正确性的工作转移给用户，从而影响用户体验。我们正在关注语音识别技术和其他人工智能技术的发展，看看它们如何有利于移动反馈收集。
基于上下文与净推荐值（Net Promoter Score）的反馈
为了在用户体验和反馈效果之间取得平衡，根据上下文设计原则，我们建议采用语境设计（ Design in Context. ）原则。也即：基于特定场景和特定用户，确定反馈机制、其内容、输入方式、出现频率等。净推荐值是常用来判断用户忠诚度的方法。通过一个简要的问题，如“您是否会向朋友推荐本产品？”，把用户分成三类，分别是“推广者者”（Promoters）、“被动接收者”（Passives）和“诋毁者”（Detractors）。一旦分类完毕，就可以继续向“推广者”问其他问题，从而实现“从更有可能提供反馈的用户那里获得更有价值的信息，而无需惹恼一般用户”的理想。因此，这是我们更喜欢的方法。
在用户有了给定功能一段时间后，第一步是要利用净推荐值了解用户对该功能的态度；然后，根据该用户的回答（喜欢或不喜欢），可以问一些更有针对性的问题，所有这一切是一致的，要确保反馈模式具有用户友好的设计（避免有侵略性的弹窗设计）。
这样，可以在短时间内收集大量有针对性和有价值的反馈数据点。这技术特别适合某些功能已经上线了一段时间的情形。
Airbnb
收集反馈时
及时响应用户的反馈
一旦一个应用成功地集成了反馈模块，其产品经理就多了一个责任：持续地查看电子邮件，或者后端反馈管理系统来获取第一手用户反馈。然而，只是“查看”是不够的。无论用户反馈是否正面、提出了建设性建议或批评，用户要花费时间和精力来提供，也会希望知道这些反馈是否被收到、被重视等等。因此，及时响应用户反馈对提高客户满意度是至关重要的一步。
第一步是立即通知用户已经收到了他们的反馈，告诉他们其反馈会及时处理，同时表示真诚的感谢。第二步是根据他们反馈的内容，及时联系用户，这可能是回答客户的问题、或者澄清未来的产品改进计划等等。第三步是在其建议被采纳，稍后会正式启动的时候，通知客户。这不仅仅让他们更好地使用应用，还可以让他们为其建议被采纳而感到自豪。
电子邮件是最不可能打扰用户的方法之一，因此其重要性在于设计任何形式的反馈都要考虑给用户提供电子邮件地址以供后续跟踪。
在苹果公司最近发布的iOS 10.3中，允许用户在不退出应用时就给该应用打分和进行评论。用户的评分和评论会自动同步到应用商店。由于用户无需退出应用就能评论，有望能大幅度降低用户流失比例。同时，iOS 10.3将允许开发人员在应用商店中公开回复用户的评论，加强与用户的关系。从此，可以看到苹果公司强调在开发人员和用户之间的反馈回路。
注意：为了降低开发成本，另一种选择是采用比较成熟的第三方反馈服务。大多数第三方服务不只是提供不同的应用反馈交互界面，还包括强大的后端反馈数据管理功能。这能大大降低开发成本。缺点在于难以定制风格和功能，也不能保证数据安全。因此，对于有自己独一无二的设计和对反馈数据高安全性需要的团队来说，这个选项是需要仔细权衡的。
反馈之后
分析反馈数据，调整应用路径图
Adamopoulos在《反馈哪里出错了》中写道：“面对反馈，我们要有正确的态度。拥抱改变，不要害怕重做”。因此，最后一步是总结、分类和分析可能很多的反馈数据来识别产品中存在的问题，对它们进行分析和优先处理。如果有必要，可能需要更进一步的用户调查和访谈，目的是制定下一个开发和发布计划。
结论
在移动应用中包含一个反馈模块不是一件简单的事情。在开始收集反馈前，应该明确目标和全面考虑构建反馈形式的功能和成本；也应当很准确地定义反馈数据输入、时序和频率。在这之后，可以成功地把该反馈模块集成到应用中。在反馈收集阶段，应当及时感谢用户的反馈，通知他们最近的改进。在收集了反馈后，应当对反馈结果进行大量数据分析，有效地调整产品路径图。只有遵循这些步骤，反馈机制才能发挥其作用，并让用户提供对产品有帮助的信息。
|
