【UXRen译#39】用户体验中的“神牛”:测试

testing

神牛,引申为神圣不可侵犯的事物
名词,一个被不合理地捧上神坛,不能被批评的思想、习俗或者制度。

 

在用户体验圈子里,测试是指责不得的。测试的好处不证自明。任何不做测试的人都是白痴。尽早测试,经常测试,更多的测试,无时无刻不在测试。

杀死一头神牛是一项由来已久的实践。它赋予你一个询问“如果我们不按照我们惯常的方法来做会怎么样”的机会。人们应当自由地做出新的抉择,检视当前的事实。在我看来,是时候来讨论测试这头神牛的合理性了,尽管很少有设计师想要讨论它。

测试并不总是一个好主意,实际上,有时候测试会扼杀创新或伟大的设计。
——Glen Lipka (2013年5月31日)

不要误解我的意思。我认为测试有它的作用。我只是认为设计师或执行官经常会不正确地运用测试,或者用一种适得其反的方式运用它。这里有一些使用过程中的例子/轶闻,以及关于测试好或不好的理由。

 

A/B 测试

做得正确:最好的测试类型是你能用大样本量来做。我在Intuit公司与Avinash Kaushik共事的时候有这样一个例子。他向我展示了这种大样本量的测试是如何真正起作用的。例子:一个购物车设计上的改变。假设好的预期变化会被记录下来(例如:设计的变化会降低购物车的跳出率)。接下来,改变后的设计将在足够长的一段时间里展示给大约10%的受众,以使结果具有统计学意义的置信度。测试结果将会显示哪种设计效果更好,“控制组”(原来的设计)还是新的设计。胜出者将成为新的冠军。这个例子就是我实实在在做的事情,我在2006年为Intuit多赚了1300万美金。耶!

做得不正确:Quicken.com网站想测试一些东西。我看到了他们要测试的东西,并觉得这个改变很糟糕。所以我制作了和原来的测试并行的额外测试。测试结果显示,我建议的改变会给Quicken.com带来每年25万美金的额外收入。市场执行官拒绝把它作为新的控制组。原因?在测试之前,她没有看到过这个我建议改变的测试方案。这是自负。测试无法说服人类接受测试的结果。如果人们的自负心理否定测试的结果,为什么在一开始还要费劲做测试呢?

完全做错:Quicken(在那个阶段之后)雇了Razorfish重新设计整个网站。我告诉他们我可以免费做这件事情,并且能做得更好。很显然,他们不相信我。不管怎样,他们付给Razorfish 75万美金,然后有了一个新网站。我看了一下,说:“这个网站会失败。”(我有非常合理的理由来证明我的断言)他们测试了这个网站,结果悲惨地失败了。购买量下降了60%。损失了数百万美金。他们把网站撤掉了吗?没有。他们保留了网站。

有人会说他们的决定是更好的全局最优解。如果不是他们在18个月之内把新网站撤掉,然后重做了一次,之后再重做一次,我也许会相信这个说法。由于人的问题,测试无法帮助这家公司避免上百万美元的损失。愚蠢的人类。

总结:总体而言,大样本量的测试是最好的测试类型。如果决策制定者拒绝接受测试的发现,测试就会走上错误的道路。

 

焦点小组测试

做得正确:在开发一款新产品/服务的开始阶段,你通常能够获得关于目标受众人格特征的洞见。我们在Marketo做了这件事。我们邀请市场人员参加圆桌会议,询问他们各种有趣的问题。从这些小的焦点小组访谈当中我获得了对他们超乎预期的了解。这帮助我为他们设计了一个很好的服务解决方案。它也帮助我加强了对他们的共情的聚焦点。

做得不正确:一个有名的故事。1980年代,SONY举办了一场焦点小组访谈,询问被访者有关黑色和黄色的音乐器材(例如Walkman和便携式立体声响)相互之间比较的各类问题。绝大部分被访者的答案是黄色的更好。访谈结束时,研究人员说:“出去挑选一件我们的致谢礼物吧。任何你喜欢的。祝你今天愉快。”外面放的是黑色和黄色的电子器材。被访者挑选了什么颜色的礼物?全是黑色的。人们并不总是对他们过去的/当前的/未来的偏好的最佳评判人。Predictably Irrational(《怪诞行为学》)是这方面的一本伟大的书籍。

完全做错:在焦点小组测试中,Seinfeld(美剧《宋飞正传》), All in the Family(美剧《全家福》)和其他一些节目的表现很糟糕。在电视节目测试的历史中,它们的测试结果大概是最差的。然而它们最终却位列历史上最好的电视节目。有多少电视节目是因为测试阶段没人站出来为他们抵制测试,从而无法在电视上播出的?测试很可能毁掉了很多有可能会流行的电视节目,与此同时使一些烂节目轻而易举地上了电视。

总结:在需要探索的时候使用测试,不要用测试证明一件事是好还是坏。

 

可用性测试

做得正确:有时候,理解用户为什么在使用我们的设计时遇到麻烦是令人困惑的。是因为布局版式吗?还是措辞?还是心理模型?你如何判断?可用性测试帮助设计师确切地观察到用户在使用过程中发生了什么。这种叫做“走廊可用性”或者“贫民区可用性”的技术基本上应用的是一种非正式的可用性测试的过程。本质上,你抓来一个人,让他使用系统,与此同时你在旁观察。我经常使用这种非常不正式的测试方式。我把用户和非用户都找过来。我在设计的早期就使用可用性测试,并且在设计流程中经常用。但我不记录任何任务完成率或其他的统计数字。可用性测试是用来帮助理解你的设计在其他人手中是怎么被使用的,也是用来帮助你与其他人共情的。

做得不正确:我曾经工作过的一家软件公司做过正式的可用性测试。测试结果在我看来根本没有定论。有很多互相矛盾的发现。产品经理和执行官们都在就测试结果和应该怎么做而争论。他们从其他设计中取出很多部分,制造了一个弗兰肯斯坦怪人,而不是设计出最佳方案。新的设计一团乱,而且比原来的糟多了。他们拒绝相信测试的部分发现(他们说被试者太少了)。另一方面,他们采用了测试的其他一部分发现,尽管那只是一个被试者的使用经历。他们基本上就是采用了他们想要的结论,而抛弃了其他发现。在这样的测试之后不可能诞生出任何伟大的设计,因为参与其中的人们不理解测试是用来做什么的。

完全做错:Intuit公司(抱歉多次提到它)的一位执行官跟我说他想要令人发出“意想不到的惊叹”的产品。我接受了这份挑战,设计了一个很棒的交互界面。设计用的是jQuery,尽管是个很早很早的测试版(2006年)。他们当然对其做了可用性测试。Intuit公司有双面反射镜和录像机。测试的任务完成率很高,一个用户惊叹道:“哇!这真是出乎意料!我喜欢它!”任务完成了,对吗?错。那个执行官说他不喜欢。为什么一开始还要费劲测试呢?当一个设计师做出了很棒的设计,证明它是有效的,然后执行官把它全扔掉,那感觉沮丧透了。

总结:随机地去找被试者,把鼠标放到他们手中。我甚至很幸运地通过远程会议系统GotoMeeting或者屏幕分享软件Join.me来测试远距离的被试者,并且让他们做演示。观察他们的鼠标操作非常有用。不要把结果写下来。不要把测试做得那么正式。保持简单。仅仅探索他们的使用过程。观察他们在哪里遇到障碍,在哪里操作得顺畅。学习,复述。不要让执行官们掺合进来。

 

其他测试技术

民族志:民族志研究有时被称为“跟我回家”,旨在通过观察用户所处的独特环境及其细节来帮助设计。这种方法没什么错,不过要花很多时间。我建议在设计一款新产品/服务的开始阶段使用它,但是别用得太过。它可能成为一场耗时战,并且回报率随时间递减。

眼动跟踪:实现实时眼球运动回放的一项很酷的技术。它有趣,而且能带来一些洞见,不过除非你有一个流量很高的网站,否则做眼动跟踪很可能是件浪费时间或金钱的事情。

多变量测试:我上了几门关于实验设计的课程,学到了比我想知道的多得多的关于这项技术的东西。它是一种把不同元素混合在一起,看看哪一种是最好的“配方”的方法。对电商网站来说这个方法很好,但对商务应用和服务来说就太复杂,而且没什么帮助。我简直不敢相信开展和分析这种测试有多么复杂。这方面的专家是存在的,但这种测试不适合心脏不好的人。

 

测试是如何影响设计师的

这是我要杀死这头神牛的核心原因。我相信测试削弱了产品的吸引力,令设计师放弃了制作出精彩的东西的责任。开发一个新的在线应用程序时,你需要设计出人们将会爱上的解决方案。这需要洞见、创造力、勤奋的工作以及技巧。不需要任何类型的正式测试。

正式测试令人们觉得他们可以把任何东西都扔进测试里,然后从结果中挑出最好的组合。测试降低了设计师从执行官和同事那里获得的信任。它使设计师的角色从原创的思想者沦为统计员。它使执行官认为任何人的意见都具有平等的重要性,测试结果完全是运气决定。在一个被测试统治的世界里,设计师没有独特的技能。

在Intuit时,Avinash在我们的第一次会面时跟我说:“你(对设计方案的好坏——译者注)什么也不知道。只有测试能给予我们真相。”我的回复是:“谁来决定哪些设计方案被测试呢?”谁来做设计工作?结果Intuit公司(在2006年的时候)是个“委员会全体参与设计”的工作环境。由于非设计师人员运行测试流程,糟糕的设计方案被用来测试。谢天谢地,Avinash让我把我自己的测试放进这一堆测试中,但如果我不是那么强势和自信的话,我可能永远不会制造出哪怕一个值得做的测试。

设计师应该跟很多人交流和合作。当你从多样化的渠道中获得不同的参考意见时,你的设计会更出色。然而,设计师同样需要对自己的工作感觉到自主权。他们需要对某种意义上的成功负责。否则他们会把责任推卸给组织里的其他人。我遇到的大部分设计师都缺乏自主权。他们被组织里的其他人压制了。

研究和测试有它的作用,但不能为此牺牲设计师的技能和努力。设计师需要创造出伟大的产品,多少测试也无法诞生出一部iPhone手机,或者一部特斯拉,或者Marketo。视野和灵感是必须的。我没有在大部分产品、网站或服务中看到它们。然而当我发现它们的时候,并非测试使然,而是设计使然。

 

测试一个新的复杂特性

我领导一组UX设计师们设计一款商务软件产品。大部分时候,我们的目标是在最短的时间内完成一项满足一系列复杂的要求,并且用户也喜爱的设计。这属于离谱的要求。我们运用“走廊可用性”测试,并与工程师和产品经理合作。我们在设计规范上全力投入,并详细说明特性的每个细小功能。每一个边界情况和系统行为都被恰当地定义了。然后我们发布了这项特性。

这一刻我们可以测试这项特性并把它改进得更好。我们可以打磨任何瑕疵。不过,业务永远有新的特性要加入进来,而这需要设计和灵感。产品经理有责任规划产品路线图。如果他们不想把改进现有特性作为优先项,那么设计团队不会在这些事上面投入了。

作为一家快速成长的公司,我们不断在快速占领新的领地,建立新的能力。我们的支持小组从消费者那里获得反馈。此外,论坛和“意见”版块是获得用户反馈的好地方,更别说用户小组座谈了。我能从这些渠道中清晰地听到问题。我通常同意用户的意见,或者想到了改进UI的办法。即使“打磨”现有的功能被作为工作优先项,测试看起来也不比这些已有的渠道能提供更多细节信息。

 

总结

测试是为实现不同目的的各类迥然不同的技术的巨大组合。这篇博客很可能是我写过的最长的一篇。有众多书籍在谈论测试这个话题。最终,我认为测试被过量使用,并且经常被误用。很多人未经充分的思考和关注,就假定测试是好的。

我的目的是让人们思考这一问题,并且让设计师们回归到设计工作。我不确定这篇博客是否完成了以上任意一项目的。也许我可以对这篇博客的效果做个测试。

 

译者:秀秀;审校:任爽;发布日期:2013年6月3日 
原文作者:GLEN LIPKA
原文链接:http://commadot.com/sacred-ux-cow-testing/
顶部图片来源:http://tmfassociates.com
版权所有:UXRen翻译组 (转载请注明出处!)
 
 

1 条回复

  1. 头像 小仙女儿说道:

    有用,很赞

小仙女儿进行回复 取消回复

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