A/B测试是一个非常有用的工具，不止能用来优化着陆页，还能用于更好的产品设计。
　　经典的A/B测试中，你是指标驱动的，你会想着测试多种变量来优化数据指标。这种情况下A/B测试非常有效，但也局限于转化明显的注册等流程。这篇文章里会提出一些不一样的策略，把指标作为指示，最终辅助产品设计过程，而不是驱动它。
　　我将描述的策略包括：
　　· 在不降低用户数据的情况下更新产品
　　· 通过测量和删除没用功能来简化产品
　　· 做出用户喜爱的设计
　　我们开始吧…
　　在不降低用户数据的情况下更新产品
　　产品团队会不断推出小的版本更新来应对客户需求和市场变化。当更新影响产品的关键部分，特别是主要注册流程或核心算法时，确保不会降低用户数据通常很重要。
　　比如，你正在做一个新的社交网站，需要添加集成 Facebook 的“查找朋友”功能。如果你构建和测试它，你很可能发现，因为没有经过优化，新功能让用户数据变得很糟糕。经典的A/B测试通常会舍弃表现糟糕的新设计，但与其过早的杀死它，你可以使用A/B测试来迭代完善新设计，每次提升几个百分点，知道它能替换原有的设计。
　　如果你知道集成 Facebook 的这个功能在产品设计中很重要，你要做的就是把它留下，但只要10%的用户看到它。然后持续对设计进行小优化，在 CTA 和其它点上进行调优，直至新设计和原始设计变现的一样出色。
　　这样，你可以更新产品而不会对产品数字造成负面影响。不同于经典的A/B测试，只是为了选出最优解，你同样可以用A/B测试作为衡量新设计的标准，持续优化，直至可以替换现有版本。这样，你是设计主导的，因为你知道你想以特定方式来优化产品，但你用A/B测试来做安全保障，以确保把没准备好的东西推给全部用户。
　　通过测量功能使用来简化你的产品
　　有一个重要的设计原则，“ Do less，but better. ”我会详细解释我的产品功能哲学，包括许多产品团队努力删除功能，甚至量化未使用的功能。
　　例如，你可能有一个建议用户关注你的网站的旧版功能，然后想用 Facebook 的“好友搜索”替换。有时候这种功能的替换是很难决策的，因为不清楚有多少人真正使用它，以及如何影响他们的整体行为，特别是对新用户。
　　使用A / B测试来处理这个问题的一个好方法是运行A / B测试来删除该功能，并返回以下信息：
　　· 有多少人看到这个功能？（根据测试时间段内试验中添加的人数与活跃用户的百分比）
　　· 已经删除这个功能的用户那些指标受了影响？（只要得到中性或正面的指示，就能安全删除）
　　· 如果一些指标不好，你能通过添加一些新设计来抵消吗？
　　与产品更新过程类似，这里的重要概念是，你需要你需要在设计层面（简化 UX）执行特定操作，并使用A/B测试作为辅助设计目标的工具。这种情况下，不是为了得到更好的指标，目标是为了更好的设计，只要指标是中立或更好的。
　　做出用户喜爱的设计
　　在为产品建立关键指标时，通常需要做出重要的假设，比如你的用户中有多少人邀请他们的朋友，或邀请了多少朋友等。通常，整个产品策略都依赖于确保某些类型的指标能起作用——这可能意味着吸引眼球的病毒式商业与基于终身价值和广告业务之间的区别。
　　从产品的角度来看，这表现为试图找出“邀请朋友”或“导入通讯录”或“订阅 Pro 版本”有多突出。要构建一个伟大的 UX ，你经常想做一些尽可能低的突出，同时要确保它易于被用户访问。
　　A/B测试可以在这上面大显身手，因为你可以测试多个版本，来看采用哪个版本。如果你想证明一个模型是可能的（例如，在最好的情况下，我们能让20%的用户邀请他们的朋友？）然后你可以做一个弹窗，要求用户邀请朋友，看看是否和你的猜测接近。这里的关键不是你真的会用令人讨厌的弹窗来关闭试验，而是帮你做一个敏感分析是否可能，看看你的模型的现实价值。
　　你可以与上面列出的其它方法一起使用这个技巧，以便最终采用高度突出的版本来进行迭代，直到被100%的用户所接受。
　　最后的想法
　　所有这些想法都分享的是，你使用A / B测试作为一个工具，以帮助一个更广泛和更强大的设计POV，而不是随从任何更好的指标结果。正如其他人之前讨论的，数据指示与数据驱动的区别。您在产品中想要做的许多功能具有很多定性价值，即使短期的定量收益很难测量或根本不存在 – 使用这些先进的策略，您可以继续推出戏剧性的新设计，但没有损害您的业务所依赖的指标。