如何通过A/B Test来选择更好的设计方案

“我觉得这个文字应该放在左边、图片放在右边……”

“我觉得这里的配图，用人拿着产品的比单独产品的好……”

“这个流程到底是分两步走，还是一步完成呢……”

……

不知道大家是否经常遇到类似的「难题」，比如需求方或者boss有不同的设计意见，大家互相都说服不了对方，或者觉得双方说得也有点道理；再比如，自己感觉几个设计方案都不错、拿不定主意……归根结底，就是说不好「到底哪种设计方案会有更好的结果」。

想回答这个问题，有一种可靠而有效的实验方法——A/B Test，它既可以帮设计师为自己输出的设计方案正名，又可以让产品研发团队避免因争论设计方案细节耗费大量时间，并真正地评估到产品改版方案有无提升。

What – 先来简单了解下 A/B Test

A/B Test 也叫“拆分测试”或“水桶测试”，是一种比较同一页面、功能或产品的两种（或更多）方案中哪一个更好的方法。是将不同的方案分别展示给几组特征相同的用户，然后持续跟进关键数据（如转化率），从而判断哪个方案可以得到更好的效果。

简单来说就是用控制变量法，控制用户特征、时间等无关变量不变，将不同设计方案作为自变量，观测关键数据指标这个因变量的值。

When – 什么时候适合用 A/B Test

其实前面有说到，想要回答「到底哪种设计方案会有更好的结果」这个问题的时候，都可以考虑用 A/B Test 的方法。具体来说可以有这些情形：

• 需要在几个设计方案中进行抉择时：

「设计方案」的范畴可大可小，小到不同的设计元素，如色彩、按钮样式、文案等等，大到页面布局、任务、功能、产品/活动策略，乃至整个产品的体验。比如，想知道发满100减30、满150减45哪种优惠券可以更加促进转化、拉动 GMV时。

• 想要了解用户的喜好时：

例如，当产品要调整内容推荐算法，想知道哪种算法更能引起用户的点击欲望与兴趣时。

• 与现有方案进行对比时：

当想要测试改变现有设计后，是否会产生积极效果时。

• A/B Test 不受产品形式的限制：

无论是App、网页、PC 客户端，乃至硬件中都同样适用，只是对应的测试方案、收集监测的工具和数据指标会不同而已。

Why – 为什么 A/B Test 是有效的

A/B Test 在这几个方面的表现让它成为一种实用有效的测试方法：

• 了解用户：

我们设计师也好，业务产品侧也好，其实都在靠直觉和判断猜想来选择用户会喜欢的方案。虽然我们可能做过用户研究，但一方面用户可能不会具体、直接地说「我想要个红色的按钮」，另一方面用户就算说得如此具体了、也不一定会按照说的去做。

A/B Test 可以帮我们从真实的用户行为中了解信息，了解用户喜欢什么、会避免什么。

• 建立共识：

没有数据的支持，我们永远也不知道具体场景下到底哪个产品或设计决策是对的，我们有的只是假设、猜想。而 A/B Test 可以作为决策、验证猜想的工具，帮助团队选择设计方向，验证（或否定）做出的决策。

• 保持产品的持续发展：

A/B Test 后确立的方案，至少会是能想到范围内最好的方案，可以保证更高的转化率、更高的活跃、更好的沟通、更棒的设计。

How – 怎么用 A/B Test

第1步：选择要对比测试的内容（自变量）

前面说到了，测试的一处内容可大可小，随我们的目标来定就好；但必须是一处内容，如果有多处内容变化，需要用多变量测试的方法。唯一需要注意的就是，变量的差别越大会越快地得到结果，如果要测试的方案之间差别很小的话，可能需要的测试时间会长一些。

选择测试内容的时候，要尽量选择未知的、高风险的问题，像前人已经做过深入研究、比较普适的方案（比如给按钮增加动效会促进点击转化）就不用再花力气去研究了，再像一些风险不高、影响不大、收益也不会太高的地儿，也不要浪费过多时间精力研究。

同时本着控制变量的思想，测试的内容要在同一水平/形式上，比如要测方案 M 和方案 N ，它俩可以是都发布上线的功能，但是不能说一个是线上的功能、一个是低保真的界面，这样测试就会让结果产生偏差。

第2步：确定要监测的指标（因变量）

这里要根据第1步中确定的测试内容来选择能衡量它好坏的指标，通常在 App 设计中可以是转化率、使用时间、交易额等；在其他产品，如无人机中关注使用频率、飞行高度、故障情况等。

根据公司具体业务情况，来确定测试中的监测指标。

第3步：确定测试的参与者

还是本着控制变量的思想，不同的方案要在同一时段展示给特征尽量相同的用户，尽量让分发的渠道也相同。总之，要控制一切可以控制的变量。

参与者的数量可以根据测试内容差异大小、产品用户规模、成本等因素来决定，保证参与者数量可以得出有统计学意义的结论。因为肯定无法对全体用户进行该测试，作为抽样测试要能代表整体，需要有统计学意义。

第4步：制作测试材料，在工具平台上发起测试

这个我们设计师可以作为了解，现在有很多成熟的测试平台，如 Google Analytics’ Experiments，可以支持 A/B Test 的实施。

只需要在平台上设置待评价的方案、检测数据目标、发布的用户、置信水平（确信在什么概率的情况下重复实验会得到相同的结论）、实验持续时长等内容即可。

第5步：观察测试结果，直至停止测试

在有明确的测试结果后，就可以尝试停止测试了，通常是至少7天后可以停止；如果有条件的话可以30天后，排除工作日、周末、月初、月末等时间点的影响。如果行业有特殊的时间节点，如大促、旺季淡季，也要考虑在内。

第6步：分析测试结果

一般 A/B Test 的工具会明确地显示出测试的结果，也就是某一个方案更优。如果一直没有明确的区分，可能是方案间的差异较小，需要更多的用户来测试才能得到有差异的结论；也可能是方案间本身就没有明显差异，此时要视情况决定是否终止测试。

若没有工具直接给出测试结果，也可以通过假设检验的方法计算各个方案在监测指标上的数据表现有误显著差异。得到测试结果后，一方面，我们可以按照它来做决定了，可以选择表现最好的方案推进；另一方面，我们也可以规划后面的测试了，看有没有其他的元素组合或者改进方案会让用户更喜欢、数据表现更好。

此外，为了提升我们的设计思维、更好地理解用户，我们还要去探索 A/B Test 的结果是「为什么」。A/B Test 只能告诉我们用户怎么做的，但并不会告诉我们用户是怎么想的、为什么会那么做。

我们一方面可以继续思考、假设，再用测试检验我们的假设。或者通过可用性测试、大声思维法，观察用户的行为、倾听用户操作时的想法。

Notice – A/B Test 的作用范围是有限的

• 只是目前最好状态

通过 A/B Test 的定义我们可以发现，在测试之前我们先要给出几个方案，再从中选择最优。也就是说，它只能帮助我们找到目前提出的方案中最好的那一个，但不一定是最适合整个产品的方案。为了找到再好一些的方案，还需要提升设计者的认知，并且配合其他用户研究、产品设计方法探寻。

• 不一定能总结成经验规律

A/B Test 能发掘出在整个设计中某个部分是很棒的、可以拉动指标数据，但这只意味着在所测试的特定的产品设计中起作用，换做其他情境，不一定就是有效的。

划重点

本文简单介绍了如何实施 A/B Test 来在多个产品设计方案中做抉择，（更多地是捍卫自己的设计！让业务产品侧心服口服！）设计师要把握好明确测试内容（自变量）、选择监测指标（因变量）、确定参与者、制作测试材料等环节。

此外，设计师要利用 A/B Test 帮助自己理解用户，在得到测试结果后剖析用户行为背后的原因，通过更多的扩展测试来寻找其他更优的设计方案。