前言：又到了周末，闲话少叙。书接上文。这篇开始就进入用户测试了（本篇文字较多）。这之前先简单回顾一下前篇内容：我们做好了准备工作，包括测试目的、时间、方式、文档准备、环境搭建。这些都会在测试时让我们如虎添翼，一个都不会白费的（相信我~认真脸~）。一切就绪，是不是迫不及待想喊：action！不要急......

图片来自百度

PS：我这没有讲招募用户的环节。1、招募用户可以找第三方服务公司，向他们提你们关于测试用户的要求，例如：年龄、性别、区域、职业等人口统计学要素，当然是最贴合产品的目标用户人群最好。但多数情况下，不需要如此大费周章。2、找几位大致符合预期的用户即可，可以是同事、陌生人等。3、如你们团队有稳定的用户库或产品售后服务群的话，从中选一些合适的人也是不错的。我们的主要目的是发现产品中的问题，5~8个样本即可发现75%的问题。

慌慌张张——测试一大忌

前面已经做了“充足”的准备工作，但仍不能保证测试中不发生其他情况。测试中经常会有一些突发情况、偶然事件影响甚至打断整个测试过程，这点要有一定的心理准备。

例如：笔者初次做用户测试时，组内只有我跟另一位同事。他年纪同工作经历也丰富许多，基本上准备地很完善。但我没有相关经验，且由于临近国庆想早点完成测试过假期。所以直接就开始进行用户测试。但前两位测试用户遇到了同个问题——设备长时间离线（后排查发现隔壁忘记通电了~）。一度导致测试现场十分尴尬，记得给被试连续上了三次热水等我们调试......

所以，测试前一定要进行一两次预测试，确保测试正常进行。古语有云：凡事预则立，不预则废。如果团队内有经验丰富的同事，可以烦请准备一些突发情况预案给新同学用以参照。如果预测试没什么问题，然后就可以择机进行正式测试了（恭喜哦说明你很棒！）。

正文一：小小心心——可以“预测的试”

图片来自百度

1.1预测试目的

想必小伙伴们上中学时，化学、生物实验总有一环叫做预实验对吧。这里的预测试概念及目的也相近，只是操作更简便。目的是发现前期准备所疏漏的内容，调整优化测试条件和效率，以保证正式测试正常地推进，从而产生正当的效果。

1.2角色介绍 和流程

其实整个测试过程有如一台小的戏剧，有情节、场景、角色、记录者等内容。大家有各自的角色，不同角色按照不同的故事情节、在各自场景内发挥自己的角色特长，将这整个过程如实记录下来就是我们的整个测试过程了。预测试就像先导预告片，宣传的同时也获取观众的反响，并适当调整该剧的策略。这里不再多言。下面是角色和流程简介：

主要流程

1、角色组成：

主试员（主导本次测试及用户访谈，在用户身边观察并记录测试情况）

被试员（招募来的测试用户）

观察员（在其他房间或位置通过视频或其他形式观察用户的操作，全程作观察笔记并与主试员沟通）。

2、流程简介：

主试欢迎被试，介绍在房间里的每一个人

邀请被试坐到测试用的电脑（设备）前

解释测试的大致目的——请被试尝试使用某一个网站（或者是某一个测试产品）

问被试一些个人简介性的问题，请被试在一张免责表上签字

解释出声思考法（把自己在使用产品时所思所想都自言自语说出来）

询问被试在测试开始之前是否有任何问题，并且回答那些不会使你遗漏你想要了解的被试信息的问题

告诉被试从哪里开始

被试开始使用该网站（或者其他产品）。主试可以问一些初始问题，或者给被试第一个脚本（或你准备好的任何东西）

被试根据脚本来继续，并且出声思考。笔记记录人员记好笔记

一个脚本一个脚本的进行，直到被试全部完成（或全部尝试过），或者安排的时间已经到了

询问一些结束性的问题，并感谢被试，给被试一定的报酬，并送被试离开

预测试和正式测试的整体流程基本一致，上述内容也完全适用于正式测试。

1.3方式&技巧

这里其实很简单，找同事简单过一遍完整流程即可（完整完整完整）。在过程中如发现异常、奇怪、失误、遗漏、多余的环节，在不影响测试进程的情况下记录或适当标记，待走完流程后依序进行调整修改。

可能小伙伴会觉得这些有问题的地方不好判断，这里分享一下我们团队常用的方式。希望能帮你找到并定位其中的问题。按照这几个方面去准备预测试，只要没啥大问题（有也不认！机智！）就可以安心找人进行正式测试了。具体方式有以下几点：

1、判断整体时长。测试脚本和任务小贴士描述了当前测试的主要内容结构。以它们作为基本条件，对预测试的整体时长进行计算和判断。据个人经验，两个主要功能点的预测试时间如少于15分钟则过短了。多于30分钟则为过长。预测试很少会进行这么久，除非过程中不断出现问题。（PS：此处时长不包含深度访谈）这一步大致能发现测试脚本测任务贴士是否恰当。

2、引导同事“犯错”。多数情况下，进行预测试时不会很仔细。这时可让同事在你不知情的情况下进行一些错误操作或“小动作”。在预测试结束后，可进行交流。这里可以发现两个问题：1、主试员的精神是否集中；2、主试员与被试员的距离是否合适，能否观察到某些细节。

3、快速回忆、致辞。在预测试结束后，深度访谈前，简明扼要地概括被试员的测试操作，简要列举其中有意义的内容，为深度访谈留下引子。这一环节能快速将主试员带入当前测试场景，略带强迫性地使主试员集中于当前内容。如果测试后，一点内容都概括不出、笔记上也未记录任何有价值的内容。则建议下一个方式

4、多人分别测试。如能够判断文档内容、流程布置无明显不妥，在上一种情况发生后可采取多人分别测试。将多项测试按人进行拆分，人员A、B、C可在主试员、被试员间切换。同时测试任务也可分配给不同人。为的是避免单个人员因能力、情感或其他因素导致测试失败。此方式会消耗较多时间，却是带新手的好方法（二三人即可）。

以上四种方式可任意选取，我们团队通常采取2、3方式。偶尔也选用4方式。因为通常情况测试内容不多，故1方式采用较少。

1.4修改测试内容（真发现问题也没辙）

这部分小伙伴浏览一下，知道有这么一个内容打个预防针就好。毕竟谁也不希望在进行到这一步的时候，发现有问题要进行修改。但真要发生了，还是要心甘情愿（硬着头皮）地修改。而且一般问题不大（大也不能认），大问题在前面充足的准备流程中基本已经过滤掉和规避了。

接下来我们就要开始正式测试了,准备开始吧...

正文二：等等待待——终于开始了

要开始测试咯！

2.1预测试的重演？

前面也已提到不止一次，正式测试和预测试在流程上并无明显不同，只在具体细节和内容量上有较大的差异。所以这里也可看出预测试的重要性（要认真对待哦），接下来基本上按照预测试的流程推进即可。在测试结束后主试员根据测试的情况，对被试员进行30~50分钟的深度访谈，然后邀请被试员根据实际情况填写好测试评估表即可。再致辞感谢并送上适当的小礼物即可完成当次用户测试。

在这里稍微描述一下正式测试多出来的测试细节和内容量，以及深度访谈的一般原则。

相较于预测试，正式测试主要目的是发现产品中真实存在的问题，并找到原因。而预测试严格意义上来讲发现的仅仅是测试过程中遇到的问题。二者目的截然不同小伙伴们要注意咯。

细节1——专注于产品，鼓励新的理解。在正式测试中，主试员更多的注意力要集中在被试员如何与你的产品交互，而不是纠结这个环节是不是在正常进行？由此经常就会产生一些“不可控”内容，比如：被试员使用产品的方式出乎你的意料，且这一方面从来没有引起你们团队的注意。这在用户测试中经常出现，而这时主试员应忠实记录下这一过程，并鼓励被试员继续探索。（这一点是很棒的，对于不同的理解一定要支持）。

细节2——不要埋头苦记。主试员在被试员进行操作的时候，有多数时间是在一旁静静观察，但也需要记录下一些内容。如果你只顾着把这些内容记录下来，就会错过被试员接下来的一些操作，这样会导致你的观察记录缺失一部分内容，而这部分内容有时候又是很关键的一些环节或诱因。所以观察和记录要分配得当，观察地仔细，记录地简洁、快速。可根据需要选择记关键词。如有内容遗漏，记得测试结束后及时与观察员交流补充笔记。

关于深度访谈——“ta”只是一次谈话。在这里我对于深度访谈的看法是这样的，这就是一次与用户的直接对话。对话的内容可以使关于使用产品本身的体验和感受，也可以是与产品无甚关联的内容(还是尽量少一些为好)。我们通过这段对话丰富了自己在前面的观察笔记。观察笔记和深度访谈的结论组合在一起，为我们优化和调整产品提供了基于用户视角的依据。除此外，深度访谈就是与用户聊天的工具而已。没有必要过于拘谨和束缚吗，聊得开心最重要~~至于究竟访谈多久，那就全看你跟用户聊得情况咯！

总结：慢慢悠悠——这么快就完了？

这篇文章很快到了尾声，不同于之前的那篇。本篇文字数量大幅增加，且多数都以纯文字类型叙述，很少介绍实际案例。这也是自己准备不够充分，没有找到足够多的实际案例来详细介绍相关的内容的原因。后面如有机会，我会整理一次真实的可用性用户测试案例来搭配进行讲解和说明。总之我们完成了前期的准备工作，然后根据已有的测试结构推进测试进程，其间只要忠实记录这一过程即可（只记录不要随意判断正确与否）。这样的过程循环5~8次之后，你就可以水到渠成地结束本次测试啦。然后就是剩下的收尾工作——对得到的测试结果和数据进行整理和归纳。这个我将在下一篇文章中进行介绍。感谢您的观看。

相关内容转载来源：http://www.usability.gov/refine/usabilitytest.html

——部分内容摘自董建民、傅利民等编著著《人机交互：以用户为中心的设计和评估》P176