编辑导语：可用性测试是一种常用且高效的测试方法。本篇文章中作者结合实际经验系统的总结了可用性测试的整个过程，感兴趣的小伙伴们快来一起看看吧，希望对你有所帮助。
在我们在工作中你是否经常会遇到这些问题：
我们用户觉得产品不好用？用的过程中会不会遇到问题？满不满意？
设计的过程中有一些纠结的地方，不知道实际用户是怎么理解和怎么操作的？
产品开发出来后，想在上线前检验一下，产品是否靠谱适不适合上线？
今天将介绍一种常用的设计验证方法——可用性测试。
通过今天的文章，系统的总结可用性测试的整个过程，一起来看看吧~
一、可用性测试是什么
可用性测试是一种常用且高效的测试方法，在我们交互工作中，我们需要去做一些简单的可用性测试来检验设计的合理性。
作为用户研究类型中的一种，它与产品以及研发结合最紧密，常用于我们产品上线前后。
它通过观察有代表性的用户， 完成产品的典型任务，从而找到产品可用性问题，并解决这些问题，目的是为了改善产品让产品更容易使用。
在时间上它越早介入越好，通过可用性测试可以提前预判风险，避免上线后再修改。
在测试内容上我们不仅可以对低保真、高保真进行可用性测试。有时候为了获得一手信息，我们还可以对竞品进行测试。
二、可用性测试类型
可用性测试类型分为形成式以及总结式两种。
1. 形成式
3-5名测试者的小样本为主，只需要1-2小时左右的测试时间，其核心目的在于快速发现问题、优化问题。
2. 总结式
它与形成式不同的是，它的样本量较大，通常在30人以上。作为定量的评估方式，一般大型第三方调研公司会经常使用。
在互联网工作环境中，由于更多的是快速迭代的敏捷研发，因此在实际的工作中我们更多的时候使用以发现问题为主的形成式可用性测试方式，它可以更好的和我们产品的研发周期紧密结合。
三、可用性测试的使用场景
在我们日常工作中可用性测试主要用于发现以下四类场景。
1. 发现问题
产品在体验过程中是否存在问题。
2. 检验目标
查看当前的设计是否满足用户的期望，满足了设计目标。
例如我们在页面中想通过设计引导用户去使用某个功能？
那么他在实际的使用中是否会注意到这个引导以及是否去使用？
他们在使用这个功能的时候会不会遇到一些障碍？
3. 评估产品
评估用户对产品的满意度。例如公司想在产品内新增一个功能，正式开发前想先测试一下用户是不是满意，针对这种场景也是适合做可用性测试做的。
4. 理解用户
可用性测试则可以帮我们设计师以及产品经理更深入更详细更直接的去了解用户，了解用户的使用习惯以及用户认知。
四、可用性测试的流程总览
可用性测试是一个不断循环的过程，大体分为5个阶段：测试准备、测试预热、正式测试、结果分析以及最后的优化方案阶段。
1. 测试准备
准备充分的可用性测试可以获得更好的效果。在测试准备期间，我们要完成7个步骤的准备。
确定目标
测试方案
测试脚本
招募用户
材料工具
测试场地
预测试
Tips： 虽然需要准备的东西较多，但是这些弄好后，后续的流程会轻松很多。
1）确定目标
对整个产品还是只是对新增模块做可用性评估？
改版方案对新老用户会产生什么影响？
改版是否能达到预计目标？
设计的时候存在有争议，想看下哪种解决方案更合理？
某个环节流失率较高，想看下是否是设计上的原因导致？
针对这需要拓展的特殊用户，在设计上是否需要做出调整？
以预期目标为例，比如说这次改版是解决之前遗留的体验问题，是针对某一类用户群体做优化还是想让用户留意到它想突出的体验重点是什么。
2）测试方案
测试方案里面包含了研究目的、关注点、用户招募、经费预算、时间计算、调研人员这几点。
研究目的： 明确测试的目的及范围，它决定了后面测试方案设计；
测试关注点： 需要与设计师协商梳理测试要关注的问题，例如哪些功能及流程需要着重关注，在设计过程中有什么纠结和疑问的点；
用户招募： 我们招募的用户有什么样的要求，需要招几个人，用户的配比如何，通过什么渠道招募用户；
经费预算： 招募到的用户给予什么样的奖励，这里涉及测试成本的一个预算；
时间计划： 对测试有一个初步的时间规划，有了这个时间规划就可以让团队内部成员在参与上进行对齐；
3）测试脚本
测试脚本，也就是给用户找点事儿做。我们可以通过在旁边观察用户结合提问获得我们想要的信息。
在时间上，测试脚本可以预先标明用户到达测试场地后我们进行的流程有哪些，这些流程究竟是什么以及每一个流程预估耗时多久。
除了时间安排外，我们还需测试脚本里面重要的测试场景任务环节的设计。
我们在前面已经收集了此次要关注的点以及还要测试的任务和范围。
我们可以事先把要测试的任务给罗列，把任务融入一些场景后再给到用户。
比如说我们会说，你最近因为工作的需要需要为该设备添加人脸照片，然后你通过我们这个人脸识别系统后台去创建人脸库并选择合适的照片进行添加。
以这样一种完整的任务描述给到用户，用户接到信息之后就可以完成这样的任务。这个场景描述最好是围绕用户真实的使用场景以及体验目的去描述。
在场景任务的设计中我们要注意以下几点：
重点关注主要任务： 产品涉及的细节很多，我们要把重点放在产品的主要任务或者此次有改变的任务流程上。
从用户角度出发： 我们在设置任务的时候要按照用户真实的使用习惯依次往下，不要有着跳跃性或者虚出的任务。
明确起点和终点： 我们在设置任务的时候要对用户的流程有一个预期，比如他这个任务从哪里开始，在体验的过程中达到什么页面或者完成什么操作，就算是任务结束了。
场景化的描述： 任务要有一个场景化的描述，给用户描绘一个贴合实际的场景，让他在完成任务的时候更加贴近真实感。
4）招募用户
招募多少用户合适？
以发现问题为目的的形成式可用性测试一般招募4-5人合适；
如果产品复杂，以及为了覆盖不同的人群差异，我们可以拓展到10-15人；
去哪里招募我们的用户？
公司内部没有参与本项目的同学
公司产品用户库
官微、公众号、门户网站等
第三方渠道
发送通知：
在完成用户招募后我们需要发送一个测试通知给到用户，包含测试时间、地点以及测试设备。在用户招募中，我们有以下几点需要注意：
围绕测试目的，找出与测试目标有关筛选维度；
考虑用户使用行为相关的特征，例如竞品使用情况，使用产品的目的，用户活跃程度；
挑选最核心的维度，转化为用户招募的条件，招募的条件在描述的时候尽量客观化，具体化，可衡量；
学会辨别真假的用户信息；
5）材料工具
测试过程当中要用到的素材：低保真原型、高保真原型或者是线上已经可以使用的产品
操作设备： 测试过程中用户群体使用的设备
工具： 包括测试中在测试过程中需要填写的量表工具
设备： 摄像机或者录音笔用来记录测试者在测试过程中的反应
6）测试场地
我们团队一般在做可用性测试的时候基本上在普通会议室完成，在测试期间控制会议室的人数，以免给用户造成一定压力，保证他在测试过程中的平稳发挥。
7）预测试
在做好前面的准备环节后，尽量留有时间做一个预测试，确保证我们正式测试的顺畅进行。预测试一般可以做这么几件事情。
首先作为测试人员，要对自己的产品做一个走查，记录可能出现的问题，记录下这些问题后再正式的测试。
其次找身边的人来做一下预测试，通过这个可以提前发现测试流程当中存在的不合理的地方，及时对这些问题做优化和调整。
2. 测试预热
预热流程分为暖场、开场介绍、简单介绍、测前体验这4个流程。
1）暖场
测试前的5-15分钟之内，主持人首先要先暖场，缓和他紧张的情绪，拉近用户与我们之间的距离，让其保持放松的状态。
2）开场介绍
主持人向用户介绍一下我们此次的测试目的、规则以及整个流程的时间，向他承诺我们此次测试记录的保密性。
与此同时鼓励同学在测试过程中对思考进行发声，这一步特别重要，要求我们的用户一边操作一边讲出当前正在思考什么，比如遇到的疑惑之类；
3）简单访谈
主持人需要与用户做一个简单的访谈，主要是为了了解用户的基本信息以及产品使用情况，例如使用使用产品的目的、日常的使用习惯，有没有用过比较好的类似产品等。
这个简单的访谈不单为后续数据分析做参考还决定了我们后续访谈环节的题目是否调整。
4）测前体验
做完简单的访谈后，我们可以让用户先随意的浏览以及简单使用一下这个产品，了解用户对这个产品的初步印象如何，品牌心智是否传达，这一步UI同学比较关注。
3. 正式测试
经过了测试前的预热，我们就进入了正式的测试环节，这一环节大概会耗时30至50分钟。主要流程有测试观察、测完评分、测完访谈3类。
1）测试观察
在整个测试环节中，需要注意测试者的行为、想法以及记录现场的观察。
行为： 用户操作的动作、每一步的步骤以及最后的操作结果，这几个都是要去核心观察和记录；
想法： 用户边操作边发生思考时候说的话，这些往往代表了用户的真实想法以及以及对产品的理解，它是后续分析以及整理时候的重要资料（例如：User1：以为从这边进入是注册人脸库，我看阿里、华为他们的产品就是这么做的。User2：这个作为系统配置入口可以理解，但作为人脸库注册入口真不是很清楚。User3：这个没想到是注册人脸库而不是添加人脸照片的，其他软件中还真没见到）；
现场观察： 记录一些比较明显的问题或者简单的分析，虽然这个问题你可能不知道这个问题是什么，但可以记录下当前的现象；
我们要鼓励做：
在行为上，留意用户在操作过程中有什么异常，比如错误操作或者操作迟疑，这些都需要我们后续进行追问。
在表达上，然后我们需要认真倾听用户说过的话，理解这些话的潜台词；
在情绪上，观察用户是否有焦躁等不满状况，假如用户实在无法完成当前的任务，必要的时候我们也可以选择让他们停止当前的任务；
不要做：
避免因用户犯错或者操作过慢而表现出消极的反馈情绪，这样会干扰用户的操作；
避免直接教用户如何使用产品；
避免针对用户提出的问题直接回答我们自身的想法，例如有测试人员向测试者提问为什么这样什么时，我们要引导用户回答他是怎么理解的；
避免用户在任务测试过程中去追问，而是应该等到任务结束后再进行；
避免用户遇到困难的时候去提供帮助，而是应该适当的鼓励；
在测试过程中我们有2关键点要注意：
用户有没有独立的完成这个任务，如果没有则说明当前的任务流程存在问题；
然后看他在完成任务的过程中有没有表现出不满，如果有不满情绪则说明我们当前的设计存在很明显的可用性问题；
2）测完评分
该环节分为多任务评分以及当前任务评分，借助量表的形式，鼓励用户在完成测试任务后对当前的体验的满意度按照1-5进行打分。
及时的打分可以让用户更好的对当前的任务进行反馈，避免因为时间过长导致的细节遗忘。
Tips： 因为SUS计数用的是0-4个距离，为了让总分是100，所以在计算SUS总分时，我们要乘以2.5，这样的结果才是最终产品可用性得分。
3）测完访谈
在用户测试完之后，我们可以与测试者沟通做一些简单的访谈。
测试者操作时候的主观感受；
测试者异常操作时，我们没有及时询问的问题，比如为什么先选中这个元素，而不是另外一个地方；
周围观察的产品团队可能也会对他们所关心的问题做一些询问；
量表评分问卷中，留意用户在哪些项目打高分哪些项目打低分，并针对用户打低分的选项追问其背后的原因；
4. 结果分析
结果分析越早越好！设计师当场就针对问题进行讨论或修改，拿新的方案立即进行测试，快速迭代我们的产品，这样的效果其实最好。我们的结果可以做以下3步。
第一步：将观察到的可用性问题分类 （例如位置、任务）
第二步：按照影响程度、频率、持续性、产品这4个维度对其进行严重程度的界定
5分：问题非常严重，用户几乎无法找到解决方案，以至于最终放弃操作
4分：问题严重，用户遇到困难，但是可以自己找到解决方案
3分：问题中等，用户遇到了困难，但是可以快速适应
2分：问题轻微，用户可以轻易解决
1分：问题很小，基本上不影响系统可用性，但为了系统的完善，可以修改
第三步：Excel结果记录 （撰写报告）
陈述该产品整体可用性如何，有无重大问题；
截图并标注出具体模块、位置的可用性问题，让看报告的人可以快速定位问题所在；
把可用性问题的严重程度进行按照优先级进行排列；
针对当前的可用性问题提出修改的方案和建议；
5. 优化建议
可用性测试的最后，我们要根据测试结果给出相对应的优化方案，把优化的问题做一个追踪表格，问题汇总后，看在下一个版本中有没有改善。
五、写在最后
以上就是有可用性测试的一些总结，希望大家通过该方法更好的验证设计方案的可行性。如有疑问欢迎一起探讨，一起成长~
本文由 @江鸟的设计生活 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
