在可用性测试中,最主要的两个角色,一个是受测(TestParticipant),另一个是测试员(TestFacilitator)。这回小兔来说说测试员(TestFacilitator)在可用性测试时应该做些什么、说些什么。之前有翻译过TestFacilitatorGuide(可用性测试开始前),那么开始之后该如何呢?这里有一篇文章,拿来作为例子说说,小兔也和自己的做法对照比较一下,好借鉴改善。
WAISiteUsabilityTestingQuestions
文章包括了四个部分:Pre-testQuestions(测试前问题)、ParticipantTasks(受测任务)、Post-testInterview(测试后访谈)和Post-testSurvey(测试后问卷)。这是WAI(WebAccessibilityInitiative)网站可用性测试,测试员(Facilitator)在测试时提的问题和任务的设计。
Pre-testQuestions(测试前问题)测试前的问题是用来了解受测的,WAI的这个例子里,可以看到问题关于受测对于可及性(WAI的主要内容)的了解、平时访问的相关站点、阅读习惯、工作背景等,以及大概的心智模型。了解受测,才能在之后明白受测的行为,便于进一步分析产品的可用性问题。我们在招募受测时也会做一些甄选,但是都比较简单,而测试前提一些问题可以了解得更真实具体些。根据产品的特性,我们可以设计不同的问题。另外,小兔把测试前的问题作为“暖场”,虽然准备问题提纲但并不严格照问。比如一次一个受测是QQ联系的,我就从他的六位QQ号聊起,询问他的网龄等等~有时甚至可以闲聊两句,让受测放松了,会表现得更自然,也比较容易ThinkAloud
ParticipantTasks(受测任务)这当然是测试的主要部分。WAI的这个例子里比较特殊的是Task1和Task2。Task1测的是网站的首页,类似的一些提问方法曾经在UPA也学到过。首页是网站给用户第一印象的关键之处,通过Task1的这几个问题可以了解到受测对于网站的大概认知;而基于WEB的浏览往往不一定居于特定的任务,所以Task2是给用户自由浏览的时间。应该说,大部分时候我们浏览网站可能也是没有什么目的的,小兔也曾愁过测试任务的问题,没想到和WAI一样的做法呢:)之后的每个任务都设计了一个场景,让用户找寻相应的信息。意料之外的是之后的任务还有8个之多,我依然没有明白为何需要这样的数量,如果某个任务的场景和受测背景不符咋办呢?难道是8个任务里选做的?@_@
Post-testInterview(测试后访谈)如果说测试的任务是观察受测行为的话,测试后的访谈就是了解用户的想法。经过对网站的一番体验之后,受测对网站也有了实际的了解,小兔也很喜欢在测试后问这些问题,尤其是在产品早期进行可用性测试、有较大改动空间的时候,不妨问一些开放式的问题,对于设计的改进有不错的参考作用。
Post-testSurvey(测试后问卷)这个问卷有些类似SUS,但我们可以看到不止是SUS的问题,除了评价网站的可用性之外,有一些可以用来验证是否达到我们的设计目标。比起访谈的好处是,这些的结果可以量化。不过对于小规模的可用性测试来说,这些数据缺乏科学性,仅用来参考。
|