如何在不伤害忠实用户的情况下推出新功能

“敏捷； 提前释放； 经常释放。” 我们知道演习。 但是，经常推出功能在战略上是否明智？ 尤其是当您正在构建的产品达到一定规模时，您可能不想在每个新的次要版本中冒着应用程序完整性的风险。

你的产品可能发生的最糟糕的事情是忠诚的用户，多年来一直使用这个小功能的客户，突然无法以同样方便的方式使用它。 这种变化可能会赋予用户更多权力，但体验会变得不那么简单。 沮丧和焦虑迅速而突然地进入社交媒体，客户支持的压力每分钟都在增加，以做出有意义的及时响应。 当然，我们不想推出新功能只是为了意识到它们实际上伤害了忠实用户。

SmashingMag 的进一步阅读：链接

• 我们如何开始以两倍的速度发布功能
• 网站启动清单 – 上线前的 15 项基本检查
• 以用户为中心的移动设备网页设计方法
• 如何启动任何东西

我们可以通过在推出我们产品的新版本时更具战略性来防止这种情况发生。 在本文中，我们将研究产品设计师和前端工程师在将功能发布给整个用户群之前彻底测试和部署功能的策略，以及如何避免用户体验问题逐渐蔓延。

在深入研究实际测试策略之前，让我们退后一步，检查一下关于如何设计、构建和最终部署新功能的常见误解。

新功能误解

每当为现有产品设计新功能时，主要关注点通常是应该如何将其准确地集成到现有界面中。 为了实现一致性，我们设计师经常会研究现有的模式并应用已建立的设计语言来使新功能在 UI 中很好地呈现。 然而，问题的出现并不是因为组件在视觉上不能协同工作，而是因为当它们以意想不到的方式组合时会变得令人困惑或模棱两可。

也许界面的副本在网站的相关但遥远的区域中是模棱两可的，或者同时积极使用两个功能的结果从技术角度来看是有意义的，但不符合用户期望或具有重大性能影响并损害用户体验.

事实上，在设计中，正是这些众多的组合很难彻底预测和审查。 在设计过程中解决问题的一种方法是考虑异常值 - 事情更有可能出错的用例。 如果用户名很长，用户个人资料会是什么样子？ 当使用十几个收件箱标签时，未答复电子邮件的概览是否仍然显而易见？ 对于刚刚注册并且收件箱中只有几封电子邮件的用户来说，新的过滤器是否有意义？

设计异常值：用户界面堆栈

一旦我们确定了异常值，我们如何准确地设计它们？ 一个好的策略是研究用户界面的不同状态。 “用户界面堆栈”是 Scott Hurff 提出的一个想法，用途广泛且复杂，当我们设计界面时，通常在 Photoshop、Sketch 或 HTML 和 CSS 中制作像素完美的模型是不够的——我们必须考虑各种边缘情况和状态：空白状态、加载状态、部分状态、错误状态和理想状态。 这些并不像我们想象的那么简单。

空白状态不一定是空的——我们可以使用服务工作者为常客提供更好的离线体验。 部分状态不必被破坏——我们可以通过渐进增强来改善破坏图像和破坏 JavaScript 的体验。

由于自定义用户偏好和用户的浏览器选择，理想状态可能与我们的“完美结果”模型有很大不同； 例如，由于浏览器的配置，某些内容和 Web 字体可能无法显示。

因此，情况一如既往地复杂、错综复杂且不可预测，我们不能将出错的风险忽略不计，但这并不意味着我们不能有效地将风险降到最低。 通过及早探索异常值和整个用户界面堆栈，我们可以在早期设计阶段防止常见的用户体验问题。 不过，在技术方面并没有变得更容易。

部署中的蝴蝶效应

即使是微小的变化也会导致连锁反应，在看似完全不相关的领域和情况中引入错误。 造成这种情况的主要原因是影响用户体验但我们无法控制的大量变量。 我们确实知道我们使用浏览器的方式，但这并不意味着我们更多地了解用户选择查看我们如此不知疲倦和彻底制作的网站的上下文。

现在，虽然像按钮上的填充或逐渐增强的文本区域这样的小改动可能看起来没什么大不了的，但我们倾向于低估这些闪亮的小改动或大规模特性的影响。 每次我们做出设计或开发决策时，这种变化都会对我们正在构建的复杂系统产生一些影响，主要是因为我们正在构建的组件永远不会孤立存在。

现实情况是，我们从来不只是构建一个按钮，我们也不只是编写一个新的 JavaScript 函数——按钮和函数属于一个组件或库家族，它们都在特定的设置中运行，并且不可避免地与其他的系统的某些部分通过它们的属性或范围或名称或团队的不成文约定。

这些“无声”的、几乎不引人注意的联系是推出功能困难的原因，也是为什么预测变化的深远影响往往被证明是一种敏锐的眼力。 这就是为什么尽可能避免不必要的依赖是个好主意，无论是在 CSS 还是 JavaScript 中——它们不会帮助你进行维护或调试，尤其是当你依赖一个你不完全理解的库时.

幸运的是，为了更好地了解更改的影响，我们可以使用浏览器的开发人员工具等资源。 我们可以测量选择器的范围或 JavaScript 函数的范围，有时在开发过程中不断返回以保持更改的范围尽可能本地和最小可能是个好主意。

这很有帮助，但这也只是故事的一部分。 我们有意识地和无意识地做出假设，基于我们自己对界面的体验和我们自己的习惯——经常忘记假设可能（因此，将会）因用户而异。 大多数应用程序确实只有一个界面，但这个界面或其配置可以有几十种状态——视图会根据用户的设置和偏好而变化。

考虑带有可定制卡片的仪表板（分析软件），具有“紧凑”、“舒适”和“详细”视图（Gmail）的邮件客户端，为登录的客户和客人更改的预订界面，阅读体验对于使用广告拦截器或激进的防病毒过滤器的人。 蝴蝶效应影响的不仅仅是代码库； 所有这些外部因素也很重要，并且针对它们进行测试 - 与单元测试或一般的 QA 不同 - 非常困难，因为我们通常甚至不知道要测试什么。

特征验证和局部最大值

我们可以使用诊断和指标来确定需要进行哪些更改，但是仅通过跟踪数据，您最终可能会停滞在我们倾向于称之为“局部最大值”的状态，这是一种设计足够好的界面状态，但完全缺乏创新，因为它总是遵循可预测的、合乎逻辑的迭代。 在开展项目并探索数据时，我们倾向于将特征分为以下四个桶：

• 破碎的特征。 . 看似损坏或效率低下的功能——显然，我们需要修复它们；
• 未使用的功能。 . 按预期工作但很少使用的功能 - 通常表明它们应该被删除或迫切需要创新；
• 意外的使用功能。 . 以与其创造者最初设想的方式截然不同的方式使用的功能——缓慢、持续改进的良好候选；
• 主力功能。 . 被大量使用并且似乎按计划工作的功能——在这种情况下，我们问自己是否有任何方法可以通过并行探索缓慢的迭代过程和完全不同的创新概念来进一步改进他们的用户体验。

前两个桶对于保持界面的功能和可用性至关重要，而后两个桶对于保持用户的参与和高兴至关重要。 理想情况下，我们希望同时实现这两个目标，但时间、预算和团队限制占上风。

尽管如此，一旦选择了新的迭代或新想法，就很有可能立即开始设计或构建新功能。 但在考虑如何将功能融入现有界面之前，首先验证这个想法是一个很好的策略——通过快速原型和用户研究。 实现这一目标的常用方法是使用快速迭代过程，例如 Google Ventures 的设计冲刺。 通过在几天内进行迭代，您可以确定新功能应该如何实现和/或它是否像您最初想象的那样有用。

通过设计冲刺，我们尽早将想法暴露给可用性研究。 在 Google Ventures 的方法中，您将每天有五个用户测试一个设计； 然后，您将迭代并通过新设计的另一轮测试。 涉及所有相同用户的原因是，如果您当天对每个用户测试不同的设计，您将没有有效数据来知道哪些元素应该更改。 您需要几个用户来验证一个设计迭代。

我们在冲刺中应用了一个稍微不同的模型。 当我们开始开发新功能时，一旦构建了早期的第一个原型，我们就会将设计师、开发人员和 UX 团队聚集在同一个房间里，邀请真实用户进行测试，然后在紧凑的时间表内进行迭代。 第一天，第一批测试人员（两到三个人）可能会安排在上午 9:00 进行 30 分钟的面试，第二组在上午 11:00，下一个在下午 2:00，最后一个一个在下午 4:00 左右。 在用户访谈之间，我们有“开放时间窗口”，当我们实际迭代设计和原型时，直到某个时候我们有了可行的东西。

这样做的原因是，早期我们想快速探索完全不同的，有时甚至是相反的方向； 一旦我们收集到不同界面的反馈，我们就可以趋向于“绝对最大”的界面。 通过这种方式，我们可以更快地获得关于非常多样化的设计迭代的非常多样化的反馈。 反馈主要基于三个因素：记录用户点击的热图、用户完成任务所需的时间以及体验对他们来说有多愉快。 本周晚些时候，我们将继续与更多用户保持一致，就像谷歌所做的那样，在我们进行过程中永久验证新设计。

到目前为止一切都很好，但有时看似创新的新功能会与现有功能发生冲突，并且将它们放在同一个界面中会使设计混乱。 在这种情况下，我们探讨是否可以将其中一个选项视为另一个选项的扩展。 如果可以，那么我们首先重申其功能和设计。 那时我们必须选择彻底的重新设计或增量更改。 后者风险较小，并且会为用户保持熟悉的交互模式，而如果无法以其他方式实现关键更改，或者增量更改的收益太浅，则需要前者。

在任何一种情况下，都必须关注产品的整个用户体验，而不是产品中单个功能的价值。 一旦您选择了功能并设计并构建了第一个原型，就可以进行测试了。

八级测试

那么，我们如何有效地防止错误和故障蔓延到实际的现场环境中呢？ 在部署功能之前，我们运行了多少次检查、审查和测试？ 我们以什么顺序运行这些测试？ 换句话说，推出功能的最终策略是什么样的？

推出功能的更好策略之一是由俄罗斯主要电子邮件提供商 Mail.ru 的开发主管 Andrew Sumin 提出的。 该策略并不适用于每个项目，但对于为成千上万的客户提供大中型产品的公司来说，这是一种合理而全面的方法。

让我们详细了解该策略，并涵盖功能推出的八个步骤，涵盖 Mail.ru 的产品开发过程：

1. 与开发人员一起测试，
2. 在受控环境中与真实用户进行测试，
3. 与公司范围内的用户一起测试，
4. 与 beta 测试人员一起测试，
5. 与手动选择加入的用户进行测试，
6. 拆分测试和检查保留，
7. 缓慢而逐渐地释放，
8. 衡量后果。

在 Mail.ru 的案例中，最重要的功能是保持完整，无论是什么组成的消息（显然）。 这是界面中最常用的部分，让它不可用或即使几秒钟也不能正常工作是绝对不可能的。 那么，如果我们想扩展 textarea 的功能，可能通过添加一些智能自动完成功能、计数器或侧面预览，该怎么办？

1. 与开发人员一起测试

开发时间越长，解决问题的成本就越高。 再次考虑一下所有决策在产品开发中的关联程度； 产品越精炼，就越需要重新做出决定，从而耗费时间和资源。 因此，从业务角度和设计和开发角度尽早识别和解决问题。

但是，你不能调试一个想法，所以初始测试应该在生产期间，在第一个原型上进行。 Mail.ru 的第一批测试人员是实际编写代码的开发人员。 公司鼓励员工使用该产品进行内部交流（甚至私人交流）； 因此，开发人员可以被视为产品的核心用户。

第一步很明显：设计和构建功能，然后在登台服务器上进行本地测试、审查和推出。 这就是 QA 测试的用武之地，使用全面的工具和任务运行器来尝试使功能和界面崩溃，并可能通过 Gremlins.js 等猴子测试工具实现自动化。

对结果进行监控，然后将其反馈到反馈循环中，以进行特征的下一次迭代。 在某些时候，开发人员会对构建充满信心：更改似乎按预期工作，并且已满足要求。 那是真正的用户测试开始的时候。

2. 在受控环境中使用真实用户进行测试

当第一个工作原型完成后，该功能将在采访中与实际用户进行测试。 客户被邀请完成任务，当他们这样做时，用户体验团队会监控死胡同和问题，并在现场解决这些问题。

但是，不仅新功能正在测试中； 可用性测试的目标是确保新功能不会影响界面的关键组件，这就是用户完成日常任务的原因，例如撰写消息以及打开、回复和浏览收件箱中的电子邮件。 如果新功能和旧功能都被很好地理解，则该过程可以继续进行。

3. 与全公司用户一起测试

显然，来自可用性测试的反馈会促使开发人员引入更改，然后将这些更改反馈给可用性测试人员，反复进行，直到结果似乎对更多的受众有价值。 然后，下一步是让该功能在公司内受到关注：发送一封全公司范围的电子邮件，鼓励所有同事检查该功能并在跟踪器中提交报告、错误和建议。

通过测试，公司内“远程”部门的用户与野外用户之间没有特别大的差异。 甚至内部用户也不知道预期会发生什么变化，也不知道某个功能究竟做了什么，或者它应该如何工作或看起来如何。 唯一的主要区别是可以提示同事快速提交反馈或发表评论。 那是引入投票表格的时候。 测试人员不仅可以使用该功能，还可以添加评论并支持或反对它。 投票必须与产品策略和业务需求进行权衡，但如果用户明显发现某项功能无用或有用，那么这是一种收集反馈并测试产品是否按预期工作的简单而有效的方法。

4. 使用 Beta 测试人员进行测试

如果一项功能通过了公司内部的技术检查、可用性检查和审查，那么下一个合乎逻辑的步骤是将其介绍给部分受众。 然而，该团队并没有将其推广给随机的用户群，而是提交了一项功能供 beta 测试人员进行审查 - 选择参与测试并提交实验性功能反馈的用户。 他们可以对某个功能投反对票或投赞成票，还可以报告错误和提交代码片段。

但是您如何选择合适的 beta 测试人员呢？ 好吧，如果你想鼓励测试人员打破界面，你可能会专注于具有技术技能的高级忠诚用户——必要时能够提供有关错误的技术细节的用户，以及对现有界面足够了解的用户能够预测其他用户可能遇到的问题。

但是，您需要标准来确定用户是否足够先进，可以成为 beta 测试人员。 对于电子邮件客户端，可能是使用 Chrome 或 Firefox（即他们知道如何更改默认浏览器）、在收件箱中创建了三个以上文件夹并且还安装了移动应用程序的人。

5. 使用手动选择加入的用户进行测试

到目前为止，测试涉及到可管理数量的用户、配置和测试报告。 然而，用户、系统和配置的多样性，包括操作系统、浏览器、插件、网络设置、防病毒软件和其他本地安装的应用程序，在规模上可能会稍微令人生畏。

在 Mail.ru 的案例中，下一步是在实时界面中推出该功能，在一个标志后面，并向这一更大的活跃用户群发送一封电子邮件，展示新功能并邀请他们在他们的自己在界面中，通常带有闪亮的“更新”按钮。 为了衡量该功能对实际用户的价值，该团队再次使用投票系统，这里和那里有一些提示，基本上是询问用户是否觉得该功能有用或有用。 请注意，此级别与上一个级别之间的区别在于，手动选择参与的受众要多得多——与 beta 测试人员不同，他们中的许多人根本不是技术人员。

所以，时机和协调很重要。 您可能不会随机选择一天向活跃用户发送电子邮件，因为您希望客户支持团队和开发人员在错误报告流开始出现时可用。这就是电子邮件发送至本周开始时，所有（或大多数）开发人员都可用并且支持团队已准备好采取行动，通过Skype或Slack与开发人员进行了简要介绍并积极联系。 在一家较小的公司，您甚至可以让开发人员在支持台坐几个小时，通过直接与客户交谈来更快地找到问题的核心。

6. 拆分测试和检查保留

在到目前为止的步骤中，除了可用性测试之外，所有测试人员都自愿使用了新功能。 但是，如果您默认启用该功能，突然间用户将不得不使用它，这是一种非常不同的组，我们根本没有测试过。

为确保您不会破坏被动用户的习惯，您可以对三小部分用户进行拆分测试并衡量留存率。 毕竟，您要确保新版本至少与前一个版本一样好用。 确定界面中最重要的活动，不仅要衡量用户在推出前后花费了多少时间，还要衡量他们返回之前经过了多少时间。 在 Mail.ru 的案例中，保留需要用户检查他们的电子邮件并撰写邮件。 用户回来的频率越高，留存率就越高，这是用户体验更好的指标。

每个部分的视图略有不同，这使我们能够测试如何在以后向所有用户显示新功能。 对于第一部分，我们添加了新功能并提供了如何使用它的教程。 对于第二部分，我们只添加新功能。 对于第三部分，我们可以保持原样。 对于所有这些部分，我们可以同时实施更改，选择合理的时间范围来运行测试，衡量保留率，然后比较结果。 细分的保留率越高，该设计就越有可能在以后推广给所有用户。

7. 缓慢而渐进地释放

如果某项功能已经走到了这一步，那么它可能已经适用于大部分受众。 这是您可以逐步将其推广给所有用户的时候——通过投票提示来收集反馈。 如果反馈大多是积极的，您可以继续推出该功能，它最终将成为界面不可或缺的一部分。 否则，您将评估反馈并返回实验室进行下一次迭代。

但是，推出该功能还不够：它必须传达给用户。 一种常见的方法是通过电子邮件和社交媒体。 尽管如此，解释该功能在现实生活场景中的价值的快速演练教程也可能会有所帮助。 此外，不要忘记集成建议框以立即收集反馈。

8. 衡量后果

一旦该功能推出，我们可以监控它的执行情况并尝试不同的方法来引起人们的注意，以便用户能够更有效地执行他们的任务。 您可以跟踪最常见的任务或访问最多的页面，然后显示一个小内嵌注释，为用户推荐一种更智能、更快的方式来实现他们的目标，然后衡量用户是否更喜欢这个新功能或常用方法。

不要忘记将反馈反馈给整个团队，而不仅仅是开发人员或设计师，这样他们就会有动力并参与其中，并了解人们如何使用最初只是一个粗略想法的功能。 没有什么比看到快乐、高兴的人完全按照您的设想或以完全不同的方式使用应用程序更能激励人了。 它还将滋养团队后续功能的发展。

审查过程看起来复杂而彻底，但有时只有时间和广泛的用户测试网络才能发现问题。 例如，如果更改会影响传入消息的概览，则任何单元测试都无法发现辅助软件用户可能遇到的困难。 在邮件界面中，您希望无障碍设备首先读出什么：日期、发件人、主题行还是消息本身？ 您重新排列概览中的列的方式可能会改变用户选择访问信息的方式； 因此，允许他们关闭新功能也很重要。

结论

那么，推广策略是什么样的呢？ 您可以从探索依赖关系图开始，以了解您的更改可能影响深远。 然后，您可以在受控环境中与开发人员和真实用户一起测试该功能。 然后，您可以要求同事审查该功能，然后再将其发送给一组选定的 beta 测试人员。 最后，您可以将该功能作为选项提供给用户。 而且，在为所有人启用该功能之前，您可以进行拆分测试以找出引入该功能的最佳方式，然后衡量关键任务的保留率。

显然，部署不是一个线性过程。 在整个过程中，您可能需要后退两步才能向前迈出一步——直到最终获得发布候选。 上面介绍的工作流程可能看起来很慢，而且不是特别敏捷，但是您可以极大地降低用户突然遇到意外问题并因此体验不佳的风险。 在某些情况下，这可能非常值得。