可用性测试是我认为最有效并且有说服力的一种调研方法，其实在工作中很少会有机会做完整的可用性测试，这可能跟你公司的重视程度和项目的紧急程度有关。不过有机会我还是建议多做一些这样的调研，通过调研去探索你的假设、去验证你的方案。

之前在HTC有做过一次为期一周的可用性测试，收获颇丰，目前再次把这些过程梳理出来，方便以后吹水用。*再啰嗦一句，不管是哪一类调研，最好自己掌控全部方法和过程、自己观察过程、分析结果，因为亲眼见到的都不一定是真的，何况别人总结的呢。*

什么是可用性测试

> 理论：可用性测试就是邀请真实用户或潜在用户使用产品或设计原型，对其在使用过程中的行为进行观察、记录、测量和访谈，进而了解用户对产品的要求和需要，并以此作为改进产品设计的出发点，提高产品的可用性。

可用性测试的流程和注意点

测试计划和招募

这是移动可用性测试最重要的阶段，这个阶段需要明确五大问题：

1. 测试计划——为什么测试？

对于有些疑问，多动动脑子，答案可能就显而易见，而有些争议，即使磨破了嘴皮子，也还是各执己见，不相上下。

探索型（形成性测试）即为让用户通过使用产品，找出产品的可用性问题，进行优化；(这个方式个人用于产品访谈）

验证型（总结性测试）即为有几种（UE/UI）设计方案，通过用户使用，最终选择最优方案（经常用这个方式做可用性测试）

我们通过形成性测试来发现产品设计研发过程中的可用性问题，及时修复，从而优化产品体验；在总结性可用性测试中，我们的目标是通过多个指标来评估产品的整体体验，通常在产品开发完成后进行。

2. 测试计划——在什么环境下进行测试？

这是一个很有趣的话题，在移动互联网时代，我们可以在任何时间、任何地点使用移动设备，情境相对更为复杂。这里我们定义的移动情境，即用户使用移动应用和产品时的环境和状态，广义来讲可以是任何影响用户与移动设备、应用进行交互的事物。诸如导致用户分心的内容、多任务并行的场景、操作时的手势、低电量的情况和网络连接环境等都是典型问题。

> Harrison et al.在建立新的移动可用性测试模型PACMAD时，就将情境因素引起的认知负担纳入了其中。

> - 第一类可称为环境情境，包括用户所处的环境、文化规范及所正在进行的活动；

> - 第二类可称为任务情境，即用户的使用目标、注意力水平及多任务状态；

> - 第三类可称为设备情境，包括用户所使用的移动设备本身（设备参数、用户对设备的熟悉程度等）、网络连接情况和运营商。所有这些包围在用户和设备之间的交叉空间，即移动界面。

如果产品处在设计初期，需要关注产品整体层面的问题，如导航的合理性、页面逻辑关系等，这个阶段可能只有低保真原型可以用于测试，此时移动情境的重要度可以降低。

如果产品的设计已经基本完善，开始进行细节的修改迭代，且有可用的高保真原型或现成产品，此时需要提升移动情境的重要性。

还要根据产品使用环境评估移动情境的重要程度，例如：滴滴打车，目标用户则会更多地在真正的移动情境中使用产品，会受到更多移动情境的影响。

如果评估产品使用环境及研究目的后，发现移动情境非常重要，那么建议着重采用真实环境下的测试方案。但事实上，研究发现大多数的用户其实是擅长想象，并能理解他们可能与移动设备会产生交互的情境的。我们很少有条件可以在真实的环境下去做调研。**所以，哪怕条件非常简陋，几乎不能考虑情境因素，也不要放弃做可用性测试。因为哪怕只是坐下来和用户沟通，看看他们如何使用产品，或者进行简单的远程测试，也会有很多收获的。**

3. 招募哪些对象进行测试？

招募测试者是重中之重。理想的测试者是我们的目标用户，所以可用性测试要努力寻找到目标用户作为测试人员，最简便的，假如同事（非同部门）或者好友也是目标用户，可以选用同事或者好友作为测试人员。为了方便招募，我们需要准备一些小礼品作为奖励，保证对测试者有一定的吸引力（HTC的发布会邀请函—金属质感）。选择被测试者时，还要做筛选工作，除了基本人口特征外（性别、年龄、职业之后等），还要关注用户常用平台（iOS Android）、对产品熟悉程度、对行业了解程度等。

招募人数是行业争议较多的问题，之前我们做调研招募了大概15名被测试者，后来发现其实有点多了，这样战线较长，并且整理起来也比较耗时。其实8-10个人之内就可以看出问题了。

4. 测试的系统和功能是什么？

测试一些功能点，测试界面设计，测试流程设计，测试设计中有争议、有疑问的地方。

5. 测试内容准备、测试环境、工具准备

- 人员：1名主持人（讲解步骤和中途帮助）；1-2名记录员（察言观色、记录笔记）；1名招待（承上启下）

- 工具：摄像机；软件记录工具  Android ： Mobizen +AirDroid；iOS：Display Recorder 或者 Magitest ；录音笔、纸笔、测试设备

录像主要是记录用户的表情和动作。有时候，用户的表情和动作可以传达很多东西，通过把这些信息记录下来可以，设计师偶尔可以挖掘到一些闪光的设计点。也可以查漏补缺，找到当时未能及时记录的内容。

> 测试设备也是个有意思的事情，有研究者指出，要保证被试者能自然地完成任务，就应该尽可能地让其使用自己的设备。使用被试者自己的设备，一方面可以更真实地模拟使用情境，特别是测试中会涉及其他产品的情况下，例如，使用用户个性化的输入法、或是分享到其使用的社交产品中，都可以真实反映被试者如何与产品互动以及如何实现切换等；另一方面，相比统一的测试设备，使用被试者自己的设备测试，可以覆盖不同的移动系统平台、不同的屏幕大小和分辨率，可以提供测试设备的多样性，保证了测试的生态效度。

但是我本人不认同这个观点，我们需要根据自己的测试目的，再决定使用什么设备。

例如如果我们只测试自身产品的操作流程，和视觉问题，就可以使用我们准备的设备，因为这些设备上可以实现预装一些录屏软件和测试版本，没有其他应用也排除了其他推送通知等干扰。

但如果要测试一些同类软件或者看用户对不同软件的某一种通用功能或交互的话，就可以使用用户自己的设备，因为用户最为熟知自己的系统和使用习惯，这能保证使用非常自然。

- 用于测试的产品：上文说到了，形成性测试和总结性测试我们的测试目的是不同的，所以测试方法也可以不同，本人更倾向在总结性测试中使用可用性测试这个测试方式，因为毕竟向很多陌生人完整并正式的测试，所以不希望自己产品的完成度不足导致测试结果出现严重偏差。所以个人会使用已经做好的demo版本进行测试，这需要事先找研发进行demo的制作（交互稿一般无法达到很高的完成度，即使可以它和真实的软件还是有很大差别）。或者我们对已有内容进行可用性测试的归纳总结，发现的问题和改进方案，在未来迭代中进行优化。

- 环境：针对所需考察的场景（一般为室内会议室or休息区）

虽然让用户在一个放松的环境更利于测试，但是休息区往往人员流动较大，比较嘈杂，所以个人更喜欢在会议室，如果要营造休闲放松的氛围，可以准备一些零食，适当调整座椅摆放方式，并通过前期引导让用户放松下来。

- 脚本：设定任务不宜过于过多，有1-2个简单问题（给被测试者增加信心也能当作情绪基调测试），5个左右完整任务。流程的测试就是根据任务来进行的。把产品的需求文档罗列出来，最好根据场景把问题串联起来，再列出你这个问题主要想观察哪些细节，预想用户可能回答的答案，考虑关联性问题。**写完测试脚本之后，可以和利益相关者（开发、视觉、交互等）讨论一下，请他们校验一下测试脚本。**

预测试

预测试是绝对必要的，为了不在真正的用户面前尴尬，这个环节必不可少。他能帮助我们验证设置的脚本是否能合理的展现我们的测试目的，是否缺少关键内容，会提前得到接收到用户可能出现的反应，以便在真正测试时可以有准备的应对。还能帮助我们形成语言记忆，不至于忘掉重点测试内容。

除此之外，主持人还要和记录人员事先沟通好，在测试时候有哪些地方需要特别注意用户的操作，如何与用户接触，当测试者进行不下去任务的时候怎么办，发现用户情绪不对了如何去安抚，是否需要终止任务等状况。

建议整个预测试环节按照真实的场景进行预测时，包括测试完看视频找到问题所在。

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

- 设备的问题。举个例子，录音设备放置的位置会影响录音的效果

- 测试脚本的问题。测试问题是否足够清晰

- 访谈的切入以及问题的提问

- 记录者的记录

正式测试阶段

1. 事先接待被测试人员：通常联系被测试人员的人和招待的为同一人，和蔼可亲的形象和谈吐可以让用户放松，便于更好的面对测试和提出问题。事先和被测试者沟通好时间，并且安排被测试者测试前休息和测试后的沟通

2. 正式测试前的沟通：主持人可以事先做一些暖场的介绍，说明下本次测试的目的，并且告知用户应该如果去操作和表达自己的想法，规则告知后，需要告诉用户我们会通过录屏录像录音的方式进行事后的总结，希望用户同意并理解。（有必要的话，需要准备保密协议）

3. 正式测试阶段：首先可以询问产品使用习惯、产品偏好、上网情况等，帮助用户快速进入状态，并且了解基本特征。然后再根据你的脚本内容进行测试，如果用户不好理解问题和操作，需要给用户一个模拟的场景帮助用户更好理解你要用户完成的内容，如果聊着聊着跑题了，尽快委婉的引导用户回归话题，脚本顺序可以在过程中有所变化，记住要随机应变，不要硬生生的像考试一样。主持人要多观察用户的神情以及动作，遇上用户有疑问的表情的时候可以询问理由，但是尽量不要提供帮助，可给予适当鼓励**让用户自己表达想法尤其关键！**，记录人员需要记录：用户做了什么动作和步骤（重点）、用户说了什么关键的话。

4. 测试结束：主持人可以跟用户了解下本次测试的感觉，用于接下来调研时的注意点，需要对用户表示感谢并送上礼品，有必要可以转移到休息区聊聊其他话题，最后要把用户送到公司门口。

5. 注意事项：测试过程中注意：切记引导性过强（想到之前在HTC，同事成功引导后并哈哈大笑德场景…）；操作行为是重点（用户的语言可能带有欺骗性，应更多关注“用户行为”，鼓励用户“出声思维法”，**要求用户在操作时，将完成任务时所有的思考、行为、感受都描述出来**）。

偷图一张说明：

测试结果分析和输出

测试的目的就是为了找到问题，优化产品，所以测试结束后的总结也是非常重要，我们可以从定性和定量两种方式来对结果进行总结。

定量的方式中，我们可以通过一些基础指标和这个产品测试特有的特定指标来衡量，整理一个表格，将所有记录的问题汇总，通过录像、笔记，把问题记录在黑板上黑板，全部贴上，然后找出可以马上改进的问题，先把这些问题处理。接下来把大的东西进行仔细的考虑，后续与产品，交互等一起进行改进：

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

关键问题:  若该问题未得到解决，用户将无法顺利完成操作任务

重要问题:  若该问题未得到解决，将影响许多用户的操作，例如操作时感到迷惑、多次尝试不成功，甚至导致用户放弃操作。

次要问题：用户在操作时可能感到麻烦，但是仍然会继续完成操作。这类问题可以稍后再修改。

- 致命错误个数：看看有哪些阻碍用户完成任务的错误

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

- 主观感受：比如是否足够简单，是否容易找到信息

- 意见及建议内容：喜欢哪些地方、不喜欢哪些地方

一定记住，当发现某个可用性问题时，需要考虑这个问题是局部的还是全局的，其他模块是否也会出现同样的问题。

撰写可用性报告（网上方法）

可用性报告本人经验很少，特意从网络摘抄一则非常实用的报告书写方法。

可用性测试报告应当包括以下内容：背景介绍，测试方法，可用性测试的结果、发现以及建议。

1. 背景介绍：**简要介绍**你的测试目标（网站or手机应用），此次测试的时间、地点，使用的设备，测试的关键执行步骤，测试过程中遇到的重要问题以及合适的解决方案。

2. 测试方法：具体包括的内容有：测试任务，被测系统或界面的类型，所采集记录的数据指标，任务场景描述。另外，简要描述被试者的整体情况、用表格展示其人口统计学信息（例如年龄，职业，网络使用情况等）

3. 测试结果：

分析录像设备、录音设备、速记员等所记录的信息、日志。包括完成率最高和最低的测试任务，统计单个被测试者、单个任务的成功率，以及所有任务的平均成功率，（可用表格展示）。

- 每个测试任务完成的人数以及百分比（可使用条形图展示）

- （针对完成了测试任务的人）每个测试任务所使用的平均时间

- 满意度调查结果

- 被测试者的一些重要评论

4. 结论和建议

列出数据分析（定性数据、定量数据、测试过程中的记录等）所得出的结论和建议。每个结论都应当有数据支撑——即在测试中实际观测到的用户行为，用户评论或者实际统计到的数据。在展示结论时，可以使用一个表格来汇总所有的结论与建议，也可以按照不同场景对应的结论逐一说明。

- 客观呈现报告的结果，哪怕测试结果是负面的。

- 在展示测试结果或者结论时，描述清楚、具体。

- 尽量针对每一项测试发现给出相应的改进建议。

除了说明一些问题所在，也要指出现有系统中一些好的设计，以便告诉开发与设计团队，在后续版本中继续保持这些优秀的实践

重要观点结合图例、视频来说明

- 用屏幕截图形象化地展示测试界面：尤其是出现问题的页面以及好的页面。

- 用短片（秒拍）的形式描述具体问题。视频记录能够更清晰的呈现问题并且说服读者。

失控的可用性测试场景

找了一些网上说到的测试场景的失败案例，可以研究下为什么出现这些问题。以便自己少犯同样错误。

- 其他人员进入测试环境

测试阶段用户会沉浸在测试场景中，突如其来的打扰会影响用户的操作行为，如果不是针对用户在复杂环境中的加试，一定尽量避免这种情况，如果真的是Boss进来查看你的进度，那么要及时和用户说明情况，并且迅速让用户回归到测试场景当中。

- 严重跑题

这个是最常见的问题，因为你聊一个问题时候，你鼓励用户去说出问题或者你询问用户为什么这么操作时，有些用户会说出很多想法，并且跟你随机产生很多新的建议，这时候就要注意及时的回归话题，比较难做到既不直接打断又做到快速回头的效果。总之尽量转移回来，绝不要告诉用户，“我们跑题了，来跟我回来”

- 用户早到和迟到

这类问题其实也比较常见，因为我们每个用户可能会访谈30-40分钟，间隔相对较短，所以每个用户等待的时间相对也较短，如果是很热门的产品，用户也会提前来公司参加，所以招待的同事需要事先在休息区将用户安置。尽量在上午和下午只安排两组用户进行访谈。

如果遇到用户迟到问题，可以看用户的重要程度，如果是个行业的意见领袖，可以等待或者再单独约时间进行即可。

尾巴

支撑一个设计拙劣的系统所需要的成本永远要比在开发过程中改进这个系统所需要的成本大得多。