让我们跟AB测试相忘于江湖【UXRen译#255】

作者: Patrick Stafford   |   翻译:Lily Zhou(周改丽)   审校:June

译者按:正所谓“方向不对,努力白搭”,A/B测试需要服务于最终的设计方案,如果只认定某一种方法而不能根据测试目的灵活变通,恐怕,所谓测试真的只是固有认知加固和“偏见测试”。

 

最为基础的A/B测试是设计团队工具包中多产且重要的武器,但它并不是唯一。

很多时候,我们总是习惯性选择常用的方法。但其实,有时我们的确需要使用一些A/B测试之外的工具,不仅仅是出于多样性的考量,而是因为,A/B测试可能并不是你测试方案是否可行的最好方式。这完全取决于你要测试的是什么,以及,你为什么需要测试。

一个成熟的设计团队应该有一套完整的测试方法。那么,让我们来看看为什么A/B测试并不总是奏效,以及,还有什么其他更棒的替代方案。

图片来自WOCinTech Chat

 

为什么A/B测试并不总是行之有效

我明白,用A/B测试来推动大规模的改进是很有吸引力的,尤其是当利益相关者步步紧逼的时候。建立实验文化理念,有助于企业健康发展。

但是一味采用A/B测试也会带来一些问题,这就需要理解为什么A/B测试并不总是行之有效。

  • 首先,A/B测试可能需要很长时间。
    根据你的进度,你可能几周都看不到结果。这段时间你也可以尝试其他备用方法,同时,也需要思考A/B测试的机会成本。
  • 大多数时候,选择什么方法都是基于你自己的考虑。
    还是回归到最初问题:想想你在测试什么,以及为什么要做这个测试。如果不是在测试某种具体的输入信息,如用户测试,那么,很有可能你只是在测试你自己的偏见。当然严格来讲,这也没什么不对,但认识到这一点是很重要的。
  • 许多人不知道如何正确地执行测试。
    一个好的管理优化者在这种时候便能凸显他的价值,如果团队中有一个不太熟练的程序运行者,他们所犯的小错误很有可能导致严重的后果。执行错误的测试,过早结束测试或者不恰当的分段测试,都有可能引火上身。
  • 你不能为了测试而测试,这一点至关重要。
    你不能提供两种完全不同的方案,然后试图找出导致结果的原因,因为导致这个结果不同的原因很可能多种多样。经验欠缺的团队在做A/B测试时经常会犯这类错误,至于结果? 很多都是猜测而已。
  • 不合理的A/B测试还会成为你做好产品的绊脚石。
    它的诱人之处在于,你可以一直测试,看起来像是在探索,但你从未实际探索到任何有用的东西。速度才是一切。持续等待直到百分之百确认完美,其实是一个UX团队经常陷入的陷阱,而这一陷阱通常会带来很大的损失。

那么,其他类型的测试还有什么呢?根据你所处的环境、设计团队以及你的商业需求,下文所提及的这些测试方法,都可以被拿来使用。

 

1、β环境测试(Beta environment testing)

A/B测试的弊端之一在于,你无法真正做范围很广的测试,你所做的测试越多,意味着你后期分析要承担的风险就越大,β环境测试能提供一个范围更广的测试工具。

“理解你在测试什么并且明白为什么——以及这将会输出什么样的结果。”

对于设计师和文案来说,这简直就是梦想成真。你可以尽情创造真正想要的设计和文案语言,而不用担心同类测试的问题。

如果你在测试之前告诉用户这是一个β环境,并且给他们选择的机会,用户往往会变得更加宽容。另外,你可以明确要求用户反馈:请填写这个表格,把任何可能出现的错误都展示出来。这可是其他测试所获取不到的。

当然,这一测试方法也还是有一些局限,这个测试工具并不是对所有人都适用,但如果可以用这一方法来做测试,你应该尝试。

 

2、多臂赌博机测试(Multi-armed bandit tests)

如果你之前并没有听过这个方法,那你可能需要花费一点时间去理解。摒弃之前的特定页面相同流量下的两个或多个不同版本间测试,取而代之的是,接纳各种各样的挑战者,然后挑出流量最多的那一个赢家。

相关阅读:Netflix 是如何做A/B测试的

这一测试相当于是一个更聪明的A/B测试版本。你不需要浪费时间在那些不起作用的创新点,而是把精力放在最有成就感的挑战者身上,你的工作更高效了,同时,也需要更多的探索和学习。无需几周,就可以得到一个最终胜出的版本。

听起来还不错是吧?没错。不过它有一点缺陷:“技术复杂”。当然,也有一些方法可以通过优化服务来运行测试机制,但是这一过程相对比较复杂。你需要一个真正懂行的人。

另外,重要的是要理解这些类型的测试之所以有效或行不通的原因:多版本测试并不是必经之路,这只对于不同的文章标题样式和CTA(call to action)按钮怎样设计这类问题有所帮助。

 

3、用户研究

很多人认为,可用性测试不能替代A/B测试,但其实在一定程度上是可以的。

有所区别的是,可用性测试不是通过大量的测试,然后基于设计进行A/B测试,只是延伸一下用户研究。招募更多的用户,然后循序渐进地开展研究。你很难直接定义出哪个版本在技术方面更有优势,但是你能得到针对每个版本更为具体的反馈。

相关阅读:一份关于设计调研的快速指引

那么,可以把可用性测试理解为一个类似的替代物么?其实不然,我们都知道,很多时候,测试可行的设计方案不一定在实际使用中也表现良好,但如果你希望获得比较深入的用户反馈,那这也不失为一种可行之法。

 

4、“投票打分”

“投票打分”像是用户测试的一个近亲,它也能给你提供一些有用的信息。当用户想要离开你的新体验的时候,紧跟上去询问,你喜欢那一部分?不喜欢哪一部分?从1到10打分的话,能打几分?

显然,这存在一些问题:选择偏好也可能意味着,持负面意见的人会更愿意站出来评论,当然这也是不科学的。

但是如果你把它和其他一些方法相结合,比如截屏和热点图等,它就可以为你的下一个设计提供指导。

图片来自Inside Design: Weebly

听了这么多之后,是不是觉得A/B测试好像没有什么用武之地了?当然不是,当你需要对网点设计做出重大调整时,当你需要变更价格的时候,还有当你想要知道一个微小等具体的调整是如何影响转化率的时候,A/B测试还是十分有效的。

你只是需要更有洞察力、更果断、也更会深思熟虑。搞清楚你在测试什么,为什么测试,以及你测试之后想要得到的结果。一旦你有了这些概念,你就可以挑选出最能准确测量预期结果的测试方法。

 

作者介绍:

Patrick Stafford是一位经验丰富的文案和记者,曾供职于MyOB、普华永道和Private Media等,作品见诸于滚石、大西洋、Polygon和 Lifehacker等媒体。他的公司Stafford Content为毕马威、SelfWealth、Data Republic 等企业服务。他不喜欢咖啡,喜欢电子游戏和阅读。

 


更多译文:

如何对视觉设计进行测试和有效评估
用户体验度量:数据臆测不如用户观察
平面设计的10个基本原则
全球12名资深设计师的失败设计案例和经验之谈
客户访谈的最大错误:把观点当成事实
全部250+篇译文>>

 

申请加入UXRen翻译组>>

uxren-fanyizu-00

 


翻译:Lily Zhou(周改丽) 审校: June

作者:Patrick Stafford

原文标题:《Let’s go of the A/B test》

原文链接:https://www.invisionapp.com/blog/let-go-a-b-testing

发布日期:June 29, 2018

版权声明:

  • 本文版权归:UXRen翻译组 所有;
  • 微信公众号转载说明:
    1)由于近期微信审理严格,若是该文章未在UXRen公众号上首发,请不要转载;
    2)公众号转载时,请在文章底部贴上UXRen公众号二维码。
  • 网站转载说明:
    1)文章标题必须保留“UXRen译”字样;
    2)转载文中必须保留:“UXRen翻译组”、“作者”、“译者”及“审校者”信息;
    3)转载文末必须保留本译文网页链接地址;
  • 如未遵照上述规则转载,视为侵权,UXRen社区保留随时追责的权利。

发表评论

您的电子邮箱地址不会被公开。