• 1452595308@qq.com

Category Archive网站可用性测试

可用性测试中的任务设计方法

lingbo_chan /

可用性是用来衡量产品质量的重要指标,从用户角度来判断产品的有效性、学习性、记忆性、使用效率、容错程度和令人满意的程度。可用性测试是在迭代设计中不断获得用户反馈,根据用户反馈不断优化产品设计的一种方法。其目的是是建立评价标准,尽可能多的发现可用性问题,并指导产品界面的设计和改进,尽可能地提高产品的可用性质量。

如果想进一步了解可用性测试的计划、执行和分析过程,《简单快速的可用性测试》一文会给您一些介绍和启发。本文仅针对可用性测试工作的重要组成部分——测试任务的设计,进行深入讨论。

为什么要单独说说测试任务的设计,这是因为,测试计划的好坏直接影响到测试效果和工作效率,而任务设计则是测试计划中的重中之重,也是最考验用研人员经验度的部分。

参与过可用性测试的童鞋都知道,测试中,主持人经常会给用户布置一系列的任务,通过用户的操作来发现产品中存在的问题。

为什么需要任务设计?

测试任务是在实验室环境中给予用户使用产品的动机,目的是让用户在合理动机的驱动下,展示他们的操作过程。

任务设计如何做?

通常,测试经验较少的用研人员的习惯做法是,对照产品上的各项功能,逐项写成任务,常见的方式是“请你××××”。这种方式本身并没有错,但是容易让人陷入为了让用户使用某项功能而设计任务的错误之中。其实,比功能本身更重要的是用户的使用目标。所以,在设计任务的时候,必须不断地拷问自己:“我设计的测试任务是真的反映了用户的实际目标么?”尤其是在面对陌生产品的时候。

比如,在网易手机邮箱智能版的测试中,我曾经遇到过一些障碍。由于我自己并不是手机邮箱的目标用户,我经常在办公室环境下使用电脑登录邮箱,对手机邮箱几乎没有需求,所以,很难想象用户是出于什么样的动机来使用这款产品的。这时候,我脑里浮现的几个疑问:

  • 什么样的人有可能使用这款产品?
  • 哪些功能最可能是他们的常用功能?
  • 他们会怎样使用这些功能?
  • 对他们来说,功能与功能之间有什么样的关系?

为了厘清头绪,我请教了邮件部门一位长期负责手机产品的同事,从她的反馈得知,对手机邮箱有需求的用户,他们在工作时间户外活动较多,邮件往来频繁。比较突出的一个群体是外贸行业人员,他们经常有关于产品报价的邮件往来。于是,便有了以下的任务设计:

关于任务设计的详细步骤请参看《简单快速的可用性测试》一文。

设计任务时应注意些什么?

  • 全面覆盖所关注的功能范围

在设计任务前预先列一个任务清单,如下图,在任务设计好之后,逐项对照,确 保任务覆盖到所有关注点。

  • 用户操作舒适自然,符合常态

任务的顺序尽量符合典型用户的典型操作流。还是以上面的例子说话,用户在邮箱中的操作流一般是【登录-查看收件箱-阅读未读邮件-处理一些邮件-(写邮件-保存邮件-发邮件)】,尽量避免让用户感觉到突兀。

  • 适当添加一些剧情

前面说过,测试任务是在实验室环境中给予用户使用产品的动机,为了让动机描述得更加合理化,我们经常会把任务设计得“剧情化”一些,帮助用户更好地融入到产品使用中。

如何评价任务设计的好坏?

任务设计出来后,一定要经历1-2次试测。这点和做产品是一样的道理。我们自己不一定是目标用户,所以,任务设计的好坏需要由目标用户来检验。在试测中,如果用户看到任务设计后对你说,“这种情况我平时经常遇到!” 窃喜吧,你成功了!

一句话总结一下任务设计的要点:关注用户的实际使用目标。

可用性测试的权衡之道(二)

Bo-jian

继续讨论可用性测试中各种原则的灵活运用和注意事项。

五.发现问题:真的 VS 假的

判断发现问题的真假,初看上去似乎不是个困难。多数或全部参与者都遇到的问题毫无疑问是明显的可用性问题。或许有人会建议,根据参与者中发现该问题的人数比例来判断:比例高是真问题,比例低是假问题。前半句话可以接受,后半句话则有待商榷。
虽然可用性测试是相对严谨的用户研究方法,但是其对无关变量控制的严格程度和真正的心理学实验还是有一定的差距;并且心理学实验对每组参与者数量的最低要求是30人,这样得出的结论(数量比例)才具有推论至一般的意义。而可用性测试一般才8人左右的参与人数(尽管招募的参与者在质的方面非常具有代表性),但却无法把可用性测试中出现的所有数量比例简单推论至一般。8个参与者中有1人发现某个问题,不代表现实中出现同样问题的真实用户只有12.5%,更不代表这个问题不是真正的/严重的可用性问题。

问题的真假除了根据问题出现的次数比例,还有很重要的考虑点是:用户“错误行为”背后的认知/思考方式是否合乎逻辑?

这里顺便借用一下诺曼《设计心理学》里谈到的理论:概念模型——系统表象——心理模型。概念模型可认为是产品设计人员对产品的设计思想;系统表象可认为是产品展现出的交互界面;而心理模型则是用户按照既往经验对如何操作该产品的设想。从这个角度来认识,可用性问题则是“概念模型、系统表象、心理模型”三者的不吻合或矛盾。

 

通过分析用户行为背后的认知是否符合逻辑,来判断发现的问题的真假,主要体现在以下几点:

1.“概念模型、系统表象”的不一致

产品设计人员突然发现,界面的交互形式根本没有反映出他原先的设计思想!

2.“系统表象、心理模型”的不一致

(1)用户的思维方式受已有的同类产品的影响,并内化接受,而新产品的“系统表象”和已有同类产品并不一致。

(2)用户在日常生活经验中形成了许多并不科学地通俗理解世界的方式(比如通俗物理学、通俗心理学),但产品设计人员没有意识到用户在以这样一种“自认正确”的错误方式来理解和使用产品。

如果发现的可用性问题属于以上情况,那么即使只有一个参与者碰到,它也非常可能是一个真正的可用性问题。

例如:让用户登录购彩网站,查看自己上次购彩结果。大多数用户点击【个人中心】去查看,有2个用户点击【开奖公告】去查看,发现只有开奖号码,没有任何购彩结果信息后,再去点击【个人中心】。仅2个人出现了稍微的偏差,而且很快就找到了正确的页面,这貌似应该不算什么问题。

但若追究其行为背后的逻辑,并与其他用户的反馈(“我上次买的号码没有直接显示出来?”“这里看不到开奖的号码啊?”)联系起来,可以判断用户的心理模型和产品的系统表象不一致。用户希望能同时对照着开奖号码和自己买的号码很方便地核对,而网站却割裂两部分放在不同的页面,因此需要将这2个用户碰到的问题当作真正的可用性问题来对待。

六.研究方法:定性 VS 定量

可用性测试,很多时候被认为是一种定性研究方法;但也有人说它是一种定量研究方法。究竟是怎么回事呢?

个人认为,可用性测试实质上结合了定性和定量两种方法的特点,到底哪种成分更多,要看你的使用目的以及细节上如何操作。

定量研究的思路是基于对一定数量样本的测量,以将研究所得的结论推广至总体。除了强调样本的代表性,还对样本的数量有具体的要求,同时会考虑抽样误差、置信度、置信区间的度量。并且定量研究过程中非常注重对某些自变量操控、及无关变量的控制。

而定性研究重视对主观意义的理解(如背后隐藏的原因),采用解释建构的方法,比如访谈法等。

 

平时工作中以“形成式可用性”测试为主,即便它稍微偏向于定性研究,但在允许的范围内,我个人还是尽可能地遵循着定量研究的方法去实施。这样整个测试过程的严谨性能得到保证,结论的客观程度相对更高(近几个世纪来,量化研究一直是科学研究的主要范式,也正是这个原因)。具体做法如下:

1.在任务的设置上:因为参与者可能存在差别较大的亚群体,不可能要求完成完全相同的任务。但必定会设置大部分基本的、都需要完成的公共任务,再针对不同亚群体设置少量的特殊任务。在后期统计分析的时候,基本的公共任务则可以进行数量化的统计,并横向比较。

2.在测试过程中:关注参与者完成任务时的相关行为,用数字来记录(以0、0.5、1分别表示失败、帮助/提示下成功、成功)。主试尽量少地言语及体态姿势的干扰,只在必要时进行适当地言语交流。

3.在报告呈现:对任务完成情况(效率、完成率)统计呈现,对不同任务的完成情况进行比较,对亚群体间的任务完成情况进行比较,对所有可用性问题按数量化指标进行排序等。或者比较迭代前后独特问题的频次是否减少,以及严重程度高的等级里面可用性问题数量的变化情况。

4.测试过后,我们通常还会收集用户自我报告式的数据,作为“感知可用性”的一个总体反映。

(1)推荐使用系统可用性量表(SUS),因为有研究表明SUS在少量样本时即可产生较为一致的评分结果。

(2)为减少用户在填写这些量表时的反应心向,不要求填写任何个人信息,且主试最好暂时回避。

(3)只统计分析所有参与者SUS量表总分的平均值,切勿再拆分比较亚群体之间的差异,因为即便信效度再高的量表,当样本量极小时都会变得很不靠谱!

七.问题优先级:单指标 VS 多指标

除了在可用性测试过程中,最终报告也必须体现出量化、客观地特点。例如,报告发现的可用性问题的列表,我也会以量化的方式排列出问题的优先级别。

这样做的好处在于:首先,发现的可用性问题肯定有一些比另一些更严重;其次,考虑到产品和设计人员的精力和资源总是有限的,必须帮助他们梳理出最亟需整改的问题。站在别人的角度考虑问题,这样他们才能更“友好地”接受我们的报告。

可用性问题列表的排序,涉及到采用单指标还是多指标、以及指标分为几级的问题。

 

先就量化的客观性而言,“出现频率”指标是最客观、最易量化的;而其它三个指标都需分析人员的主观判断。

就指标的代表意义而言,“严重程度”、“出现频率”与用户体验最相关,与用研人员的职责也最相关。另两个指标可能更多地是产品人员的职责。

就指标的价值而言,多个指标的综合显然比单一指标更有价值。

基于上述考虑,实际工作中我会选择“严重程度”和“出现频率”两个指标的综合,作为可用性问题的优先级指标。“严重程度”分为3级,而不是5级(分析人员主观判断时,3级指标的误差率要低于5级指标);“出现频率”采用计算的具体数值,而非4级分类。这两个指标合并时,采用1:1的权重,具体公式为:

问题优先级=严重程度的级别+出现频率的具体值×3

八.报告呈现:优点 VS 问题 VS 建议

当产品设计人员辛辛苦苦做出的产品却被你报告上罗列的各种问题批评得一无是处时,即便理智上认可你的成果,情感上也很难接受。因此报告中列出哪怕一条最重要的优点,也会让产品设计人员感到欣慰、感受到你中立的态度,增加对报告的接纳程度。列出优点的另一个好处是,在测试中被参与者多次自发提及的优点确实带给用户某种惊喜;当你在报告中再次强调时,可以避免在后期迭代开发中丢失掉原本的优点。

问题的列举肯定是报告中非常重要的部分,但切勿罗列出清单就草草了事,因为:

1.某个(些)问题和另一个(些)问题是有关联的,但是报告中的问题列表部分却割裂了这些联系。

2.产品设计人员无法一直参与旁听/观察可用性测试的过程,导致对报告中文字描述的问题缺乏感性认识。

3.只提问题却不提供解决方案,就不是“建设性地提问”!

因此,我们需要在可用性测试报告的后半部分提出针对重要问题的解决方案。其目标并非是强迫产品设计人员一定要采纳我们提出方案,而是:(1)把一些相关问题联系起来看,(2)加深报告阅读者对于问题的感性认识和背后原因的理解,(3)使整个报告的思路更清晰、完整,(4)我们还可学到一些交互设计和产品的知识。

 

总之,可用性测试施行起来既简单又复杂。简单是因为不管你如何施行,终究能发现一些问题;复杂则在于发现可用性问题的质量、重要性、对测试的利用效率、对产品设计人员的帮助程度可能相距甚远。一次成功的可用性测试体现在从前期策划、测试过程、后期报告等整个过程中是否遵循了这些原则,并在某些难以两全的原则面前做到合理的权衡取舍。

 

可用性测试的权衡之道(一)

Bo-jian

对于可用性测试,业内人士存在一些普遍认可的原则。它们神圣地如同自然科学里的理论,似乎我们只能对其言听计从、俯首称臣才能践行出“好的可用性测试”。其实,即便是科学,它的一个特征也是“可证伪性”——理论的正确性总是存在前提条件的。真理再向前一步就成为谬误!
可用性测试中的原则同样如此,需要根据目的、资源、环境的不同,灵活把握、权衡取舍,而非一味恪守某一个或某几个原则,也许这才是可用性从业人员经验重要性的体现。

一.任务设置:精细 VS 宽泛

制定的任务过于精细,一般原则上是反对的。理由很清楚,如果你的任务精细到一步一步“引导”用户进行操作,那太不符合用户现实中的使用情境,平时没有人在旁边“引导”用户的每一步操作;而且过于控制用户的操作步骤,用户缺乏真实使用时的灵活性。

是不是我们设置的任务只能是宽泛的,不能细化呢?这就必须根据研究的目的来做抉择。如果产品处在设计的初期,我们需要关注一些宏大的问题(如:网站的整体架构、导航和分类的合理性、页面的逻辑关系),此时就需要通过宽泛而有弹性的任务,来查找宏观层面的问题。如果产品的设计已经非常完善,开始进行细节的修改迭代,此时就需要通过设置相对具体的任务来查找特定的细节问题(如:对某个命名的理解、按钮的使用、链接的点击、表单的填写)。按照《Don’t make me think》一书的观点:一般用户使用互联网产品时满足于能用就行,不会寻求最好的使用方法;只扫描网页,不会仔细阅读。所以,如果完全宽泛有弹性地设置任务,虽然更吻合实际使用情况,但是很可能用户直接跳过你想考察的细节。

实际工作中,由于时间和资源的限制,无法做到每个产品从设计初期到上线前后进行多次可用性测试。可能在一次的可用性测试中即需要同时关注宏观方面和细节上的问题。此时,还是需要和产品经理、交互设计师反复沟通,确认测试的主要目的,同时通过对任务设置精细程度的权衡把握,使次要目的也尽量得以满足。

不过,即便是想考察细节的任务,也要尽量避免“直接指导操作”式的语言描述方式,这样能让任务与真实使用情境不会相距太远。例如:想考察豆瓣读书页面【想要】按钮是否能被看到、是否具备可点击感。下面列出两种表述方式,以作对比:

A.请找到您喜欢的那本书,并在该页面点击【想要】。(×)

B.请找到您喜欢的那本书,并在该页面对其作个标记。(√)

二.任务数量:多VS少

任务数量的多少与可用性测试考察范围有关,与任务的精细程度也有关。如果对网站全站进行考察和只对其中某个页面、某个操作流程进行考察,所需的任务数量自然不一样。在同样的考察范围下,如果任务设置得越精细,所需任务数量也就越多。

Lindgaard和Chattratichart(2007)的研究发现任务数量与发现可用性问题比例存在显著的相关关系(r=0.82,p<0.01)。为了尽可能多地发现可用性问题,我们就尽量多地设置任务给用户吗?

此时要考虑任务数量过多可能带来的弊端:学习效应和疲劳效应,尤其是靠后的任务更可能会受影响。心理学实验中处理此问题的方法是顺序平衡,抵消影响。但是可用性测试中设置的场景和任务存在特定的先后次序,不适合采用顺序平衡的方法。基于我们的经验,还是通过对测试的任务数量进行控制,确保正式测试环节最多不超过1小时,加上前后的欢迎语、访谈、问答等,整个过程不超过1.5小时。

此外,任务数量的多少还会间接影响到测试所需参与者数量的多少。

三.用户人数:5个足够VS  5个不够

Nielsen的研究发现,5个用户可以发现80%以上的可用性问题。这个结论得到许多人的推崇,因此称之为“魔法数字5”。这个结论的来源依据是每个用户平均可以发现30%的可用性问题,且假设所有问题都有同等被发现的概率。不过,当设置的任务数量过多,且任务的精细程度和难度多种多样时,这个前提有可能不成立。

Lindgaard和Chattratichart(2007)的研究发现测试用户数量与发现的可用性问题比例并不存在显著的相关关系。这个结论似乎又支持我们选择少量用户进行测试即可。

其实,在用户招募阶段,比用户数量更需要重视是用户的代表性的问题。能否招募到有代表性的用户将直接影响可用性测试的成败。如测试一个医疗软件产品,招募到医护人员和患者作为测试用户,那5个用户可能就足够了;但如果只招募到医学实习生来测试,就必须超过5个以上的用户(即便这样,也未必能推论到整个产品的用户群)。

由此看来,招募用户的人数和任务的数量、精细程度、用户的代表性也是息息相关的。参考Tom Tullis(2009)和本人经验:当可用性测试范围限定在一定的范围(20个任务内、或30个网页之内),且招募到很强代表性的用户,那么5个足够了。如果存在着差别较大的亚群体,争取做到每个亚群组有5个左右的代表性的用户(当然,目标用户的特征及分类应该是在可用性测试之前的用户调研阶段就解决的问题);一次测试最多不会超过12个用户。

四.用户表现:行为VS言语

在可用性测试中强调对用户操作行为的关注,是毋庸置疑的。因为:

1.用户的行为指标更明确、具体、客观,易观察和记录。

2.如果完全把关注点放在用户的操作行为上,那么就无需跟用户进行多余的(指导语之外的)语言交流。类似于心理学研究规范,对实验或测试中的指导语进行统一,对一切无关变量(包括主试的语言、体态表情)进行控制,以减少对研究过程的干扰。

3.即便你直接询问用户某些问题,也极可能得到错误的答案。30年前Richard Nisbett和Timothy Wilson的实验、2年前Peter Johansson在《science》的文章,都证实了某些情况下人们无法解释清楚自己行为的真正原因。另外,用户还可能揣摩主试的喜好,回答他们认为主试期望的答案。

因此,有必要强调在可用性测试过程中关注的重点永远应该是用户的操作行为,而且尽量减少任何无关变量的干扰。但这个原则被有些人引申到极端,认为只有观察用户的操作行为才有意义,其他信息都是无需关注的,甚至轻率地怀疑用户的话都是不可信的。

可用性测试的主要目的虽然是发现问题,但也需要了解问题背后的原因,而仅仅依靠观察用户的操作行为是无法获悉所有问题背后的原因的,此时,我们就希望用户能采用“出声思维法”,出声思维就是集中于如何与产品进行交互的意识流。如果测试中的氛围比较平等、自然、融洽,用户又特别愿意表达,那么用户就会在进行任务操作同时,表达他们想做什么、打算如何做、背后的原因是什么。此时,不仅是操作行为、用户表达出来的想法和原因、以及语言中透露出的疑惑、失望、不满、惊讶、犹豫等情绪同样是需要我们加以关注的。但是,有些用户比较内向,不善于主动表达自己的想法,此时就需要主试跟他进行简单的交流,以引导用户说出背后的原因(注:不是引导用户说出你期望得到答案)。

所以,在实际的可用性测试,基本应该以关注用户的行为为主,少量、适时地进行询问交流也是需要的。但这个度如何把握呢?

1.当用户出现犹豫、惊讶、任务失败(过程节点上出现自然而然地稍微中断/暂停)的时候才进行简单的询问。

2.询问采用一般疑问句的句式,重复用户刚才的行为表现(要具体客观):“你刚才没有……,是吗?”——虽然没有直接问“为什么”,但暗示了希望听到他进一步的解释。

3.如果用户没有自己主动说出原因,可以“顺便”问一下“为什么?”或通过身体前倾、目光注视等非语言方式来暗示用户你希望能听到更多内容。若用户很快、坚定地说出原因,则该理由的可信度较高;如果用户犹豫、或难以说出原因,就不要继续追问。

除了上述的语言、情绪、行为都需要得到关注,还有一种特殊情况是需要听懂用户“没有说的”语言。例如,我们预计网站的某二级导航标签和一级导航标签存在分类逻辑上的不合理;但用户在测试中,导航相关的操作步骤进行得很流畅,用户也什么都没说。这通常表明用户认为这些是理所当然的、不影响操作的——此时你需要听懂用户“没有说的”语言。如果你简单粗暴地打断用户并询问:“你觉得这两个导航标签如何?”,则变成了一种诱导性地提问。

总结一下关于此部分内容的实践应用:

1.用户的操作行为永远是可用性测试的重点。

2.鼓励用户采用“出声思维法”。

3.适时、少量地向用户提问,禁止对同一个问题反复追问“为什么”。

4.采用真正地“倾听”技术保持和用户的交流状态,而非通过过多的话语。

5.开放、不预设立场地观察、倾听用户“没有说的”语言。

在可用性测试中考虑需要遵循的原则时,一定要理解它的适用条件,以及它和其它原则之间的互相影响,并结合本次用户研究的目的、资源、环境综合考虑,以尽可能形成一个最优方案。由于博文长度所限,先总结这么多,在下次的文章中会继续总结其它几方面的原则。

 

网站可用性测试的七个步骤

1.可用性测试的过程

可用性测试的过程主要有七个步骤:测试前思考、制作测试原型、撰写测试脚本、招募测试者、设置测试环境、预测师、正式测试以及测试结果统计分析。这七个步骤有些事可以并行的,有些是需要严格按照前后顺序执行的。七个步骤组成的流程图如下:

可用性测试过程

下面我就针对这七个步骤,谈谈具体要怎么做。

2.测试前思考

不论是做哪个平台的可用性测试,比如PC端、移动端或者是WEB端的可用性测试,最最重要的就是要先理清楚一些基本问题。基本问题就是最经典的5W问题:

  • 为什么要进行这个测试(why)?测试可以验证一些设计中的疑惑,或者找出现有的界面、流程设计上的问题,具体问题要具体分析。
  • 什么时候在哪里做测试(when?where?)?时间一般是需要和测试者协调的;地点一般选择在安静的会议室即可,如果公司有专门的实验室那就最好不过了。
  • 谁要作为测试者(who)?这里可以在招募测试者会详细讨论,不过测试者一般是跟我们的persona接近的人,或者换个说法,测试者一般是我们的目标用户。
  • 我们要测试什么(what)?测试一些功能点,测试界面设计,测试流程设计,测试设计中有争议、有疑问的地方。

当然这些问题其实都不太难,但是这些都是至关重要的问题。如果没有经过这个步骤的思考,整个可用性测试做下来就会像无头苍蝇,没有一个总的指导。

3.测试前期准备

在想清楚以上的问题之后,需要为可用性测试做一些准备工作。主要工作有:①招募测试者; ②撰写测试脚本; ③制作测试原型。

这三个过程不分先后,条件允许的情况下(人力物力充足时)也可以同时进行。

3.1招募测试者

招募测试者算是可用性测试最重要的一个环节之一的,测试者是否合适直接关系到测试结果的好坏,测试结果直接关系到能否发现产品现有的问题。所以招募测试者是重中之重。理想的测试者是我们的目标用户,所以可用性测试要努力寻找到目标用户作为测试人员。寻找的途径如下:

a)最简便的,假如同事(非同部门)或者好友也是目标用户,可以选用同事或者好友作为测试人员。

b)其次,大型公司都会有自己的用户资料库,可以从这个库里面寻找到测试人员。

c)又或者说,委托第三方机构帮忙寻找测试人员也是允许的,不过效果可能不如自己寻找的。

d)当然,现在的应用一般都会有自己的微博、微信、官网或者论坛,这些是非常好的寻找测试者的渠道。我们可以推送招募测试者的公告,让用户填写一份调查之后,我们再筛选得到我们想要的测死者。公告中要注明奖励,一般为小礼品的奖励,保证对测试者有一定的吸引力,同时又不至于让他们会为了这个礼物对个人信息造假。其次,对于测试者,我们需要进行一个筛选【3】。首先需要用户填写必要的个人信息:比如姓名、电话(邮箱)、空闲时间;然后根据调查选择其他一些个人信息:性别、年龄、职业之后,最后留几道问卷题目进行筛选。

筛选的维度主要有:

  • 平台。如果测试的产品与平台有关,比如是Android或者iOS,需要在这里进行一个筛选。
  • 对产品的熟悉程度。比如我们想找一些初级用户和一些高级用户,可以选用“使用时间”这一项来衡量用户对产品的熟悉程度。

3.2撰写测试脚本

测试脚本的好坏直接关系到结果的好坏。在撰写测试脚本之前,我们需要先确定一些结果分析的维度。一般的维度有:a)任务完成度b)致命错误c)非致命错误d)完成任务的时间e)主观情绪f)偏好和建议。对于这些维度的解释具看第文章的最后一部分“测试结果统计分析”。

由于分析的维度会关系到脚本的问题,所以在确定分析维度之后,我们可以对功能点进行任务分析。把所有需要测试的功能点列出来,对每个功能点进行任务设计。对于任务而言,用户最主观的感受就是两个:界面和流程。所以测试脚本又可以从这两个维度去细分。

需要注意的是,可用性测试中,问只是其中的一部分,观察是另外一个重要的内容,所以测试脚本不仅仅要有问的问题,还有需要撰写工作人员观察的注意点。同时可以在撰写完测试脚本的同时,把总结大纲也写出来,方便后期总结的时候统一结果展示。

特别的,在设计的时候有疑惑的点,或者有争议的点,在可用性测试也可以得到较好的验证。

写完测试脚本之后,可以和利益相关者(项目经理、产品经理、开发等)讨论一下,请他们校验一下测试脚本。

界面:

a)当前界面有什么?

b)每个东西用户觉得是什么?

c)可以操作吗?

d)用什么手势操作方式?

e)操作之后会怎么样?

f)界面显示的内容足够吗,有没有缺少什么东西?

流程:流程的测试就是根据任务来进行的。把产品的需求文档罗列出来,然后给每个需求配上一个合适的场景,当然也会出现一个场景覆盖多个需求的情况,这也是允许的。然后让用户在场景下去进行任务,观察用户,然后随时提问用户,随时准备回答用户的问题。

以上两点适合所有的可用性测试,但是对于版本更新类的可用性测试,我们还需要了解这个更新对于用户来说的接受度如何,所以需要增加一些对比性的问题:比如说:新旧版的操作流畅度、界面表达对比感受。

最后需要注意的是,一次可用性测试能涵盖的范围有限,所以要限制脚本问题的数量,以及对脚本的问题进行优先级的排序。

举个例子,之前做过一个微信端的众筹平台。我就可以设定以下任务:

测试脚本样例
3.3制作测试原型

可用性测试的原型一般是高保真的Demo,可以用Prott,Flinto,proto,墨刀等来制作,制作力求真实还原应用的最终实现效果。制作高保真Demo是一件耗时耗力的工作,所以在制作的时候可以适当忽略一些动效、界面等。不过做出来的Demo最终也可以给开发参考,所以辛苦也是值得的。甚至于,可以请求开发人员制作原生的程序Demo(针对安卓平台),程序Demo体验会更加好。

当然,纸面模型也是另外一种非常好的工具。纸面模型需要把纸面模型都只做出来,然后把所有的弹出窗口、下拉菜单等控件也制作出来。然后设计师充当wizard of oz来辅助用户完成任务。即用户对着纸面模型来操作,然后设计师实时反馈用户的操作。这样子要求设计师非常熟悉测试的应用,同时,测试的时间也会大大增长。同时,动效作为设计的一环在这里无法表现出来,所以结果可能会不如高保真Demo来的好。总之各有利弊,根据实际情况来考虑。

4.设置测试环境

测试环境是指测试的时候需要使用的记录设备,通过把测试过程记录下来可以更好地分析用户的行为,特别是用户自己都没有觉察出来的一些东西。

首先,最最重要的一点是录音,录音一方面是在整理访谈记录的时候可以帮助设计师回忆访问的场景,然后填补一些缺失的笔记。另一方面,录音也可以作为一种存档的材料。同时,录音也存在简单、易操作、隐蔽等特点,使用录音笔或者现在随处可见的智能机即可完成录音。所以强烈推荐进行可用性测试的时候一定至少要录音。

录音之外就是录像,如果有录像的话,录音的步骤就可以省略。录像主要是记录用户的表情和动作。有时候,用户的表情和动作可以传达很多东西,通过把这些信息记录下来可以,设计师偶尔可以挖掘到一些闪光的设计点。

除此之外,用户的屏幕记录也是一种方式,通过用户的屏幕、加上用户操作的动作,表情,可以真实还原用户的使用场景,方便后期的分析。

录像和录屏的操作比较难进行,主要的设备可以参考如下【5】,具体可以查看相关的链接:

  • 摄像机:记录动作和部分表情
  • 眼动仪:可以追踪眼球的焦点轨迹,不适合移动端
  • 鼠标轨迹记录:记录鼠标轨迹,只适用于PC端
  • QuickTime (iOS):仅记录屏幕
  • Mobizen (Android):记录屏幕、手势
  • Display Recorder (iOS):手势、声音
  • SCR (Android):记录屏幕、手势、表情、声音
  • Magitest (iOS):记录屏幕、手势、表情、声音
  • Mobizen +AirDroid (Android):现场观察并记录手势、表情、声音

5.预测试

预测试是正式实施可用性测试前的一次模拟, 模拟有助于发现问题,这时候邀请同事即可。把正式测试的流程走一遍,包括设配的调试、访谈切入、问题的提问、记录者的记录等,然后把记录的录音、视频等放出来看看效果如何,效果不如意的时候再进行调整。

总之,预测试可以帮助发现问题,包括以下几个方面的问题:

  • 设备的问题。举个例子,录音设备放置的位置会影响录音的效果。
  • 测试脚本的问题。测试问题是否足够清晰。
  • 访谈的切入以及问题的提问。
  • 记录者的记录。

发现问题之后去解决问题,才能使正式测试的时候达到更好的效果。

6.正式测试

6.1事前接待

测试前的接待工作是测试人员对公司的第一印象,给测试人员留下一个好印象、一个好心情有利于可用性测试的进行。所以在这里将一些注意点说一下。

首先,可以事先确认一下用户的行程。遇到刮风、下雨、下雪等恶劣天气的时候可以事先送上问候短信。

其次,遇上用户迟到的情况下,也要保持克制。在迟到五分钟到十分钟之后再给用户电话询问情况,如果用户因故取消测试,也要保持友好的态度。

在接到用户之后,送上一杯温水或者温热的饮料,然后让用户等待一下。最后可以有专门的人员先和用户聊聊天,可以打听一些事情。

6.2暖场介绍

正式开始之前有个暖场介绍。首先主持人做一下自我介绍,然后介绍一下测试的目的和时间,需要向用户强调测试的对象是系统,希望用户可以畅所欲言。如果有录音或者录像,需要向用户告知会有此类行为,但是结果完全保密。最后还需要签署保密协议。

6.3正式提问

正式提问分两个部分:个人信息的小问题和可用性测试任务问题。

小问题主要是为了让用户有个适应的过程,可以迅速进入状态。一般可以询问产品使用习惯、产品偏好、上网情况等,之后的测试问题就是主要的可用性测试的问题。这里需要把问题放入到场景中,让用户在场景中去完成任务。或者可以询问用户的使用习惯,然后引导到脚本中的问题。需要注意的是,不一定要按照脚本的顺序提问,可以随机应变,所以主持人要非常熟悉脚本的内容。除了询问,聆听之外,主持人还要观察用户的神情以及动作,遇上用户有疑问的表情的时候可以适当穿插新的问题,但是尽量不要提供帮助,也不要指出用户的错误或指责动作太慢,但是可以询问用户“为什么这么操作”,必要的时候可以选择停止任务。

测试过程中还需要有一个记录人员,记录人员需要记录:用户做了什么动作和步骤(重点)、用户说了什么、写下自己的疑问(适当时候可以进行提问或者让主持人提问)。

6.4结束感谢

测试结束之后,主持人可以问一下用户的想法,同时让记录人员补充提问,所有问题结束之后,需要对用户表示感谢。送上礼品并接受用户的一些交通费报销票据等。最后要把用户送到公司门口。

7.测试结果统计分析

测试结束之后,如果有时间可以立马进行整理,因为时间越短,整理出来的内容就越丰富。必要的时候,可以用录音或者录像来辅助。在撰写测试脚本的时候还有一份总结大纲,根据大纲来整理内容。大纲要具备灵活性,可以记录一下测试现场发现的新问题。

记得只是整理而已,每个测试结束都会有一份整理的资料。最后需要汇总多份可用性测试总结,最终出具一份可用性测试结果,根据这份结果进行相应的改进工作。

我们可以从如下几个维度去分析我们的可用性测试【8】(维度之间可能有交叉):

a)任务完成度。每个测试任务都对应一个目标,只有当用户达到目标之后,我们才认为他们完成了任务。对于每个任务,用户完成的情况如何?有多少用户最终没能完成任务?多少用户需要在主持人提示下完成任务?多少人可以自行完成任务?这些都是很重要的指标

b)致命错误。严重错误指那些阻碍用户完成任务的错误,这些错误非常重要,每一个都要得到足够的重视。

c)非致命错误。非致命错误是指用户能完成任务,但是某些地方会有一些阻滞,会停顿或者思考的错误。这些错误相对来说没那么重要,不过如果发生的次数较多,该类错误也需要得到重视。

d)完成任务的时间。每个任务需要完成多少时间,决定了交互设计流程和界面的设计是否足够友好。

e)主观情绪。用户对于任务的主观感受,比如是否足够简单,是否容易找到信息,可以让用户衡量一下。

f)偏好和建议。可以让用户说出产品中哪些地方很喜欢?哪些地方不喜欢?或者让他们提一下建议。