编辑导语：可用性测试是一种常用且高效的测试方法。在本文中，作者根据实践经验，系统地总结了可用性测试的全过程。感兴趣的朋友过来看看，希望能帮到你。
您在工作中是否经常遇到这些问题：
我们感觉产品不好用？在使用过程中会不会出现什么问题？你满意吗？设计过程中有一些混乱。不知道实际用户是如何理解和操作的。产品开发出来后，想在上线前检查一下。产品是否可靠，是否适合上线？今天介绍一种常用的设计验证方法，3354可用性测试。
通过今天的文章，系统总结了可用性测试的全过程。来看看吧~
1.什么是可用性测试？可用性测试是一种常用而有效的测试方法。在我们的交互工作中，我们需要做一些简单的可用性测试来检查设计的合理性。
作为用户研究的一种类型，它与产品和研发的关系最为密切。d，经常在我们产品上市前后使用。
通过观察有代表性的用户，完成产品的典型任务，它可以发现产品可用性问题并加以解决，目的是改进产品，让产品更容易使用。
它在时间上介入得越早越好。通过可用性测试，可以提前预测风险，上线后可以避免修改。
在测试内容上，我们不仅可以测试低保真度和高保真度的可用性。有时候为了获得第一手资料，我们也可以对竞品进行测试。
二。可用性测试类型可用性测试类型分为形成性测试和总结性测试。
1.3-5个测试人员的小样本是主要形式，测试只需要1-2个小时左右。其核心目的是快速发现和优化问题。
2.总结型不同于编队型，它的样本量更大，通常在30人以上。作为一种定量评价方法，经常被大型第三方研究公司使用。
在互联网的工作环境中，因为有更多快速迭代的敏捷研发；在实际工作中，我们经常使用形成性可用性测试方法，这种方法侧重于发现问题，可以更好地与R & amp我们产品的d周期。
三。可用性测试场景在我们的日常工作中，可用性测试主要用于发现以下四种场景。
1.了解问题产品在体验过程中是否存在问题。
2.检查目标，看看当前的设计是否符合用户的期望和设计目标。
比如我们想通过页面中的设计来引导用户使用一个功能？
那么他在实际使用中会注意到这个指导并使用它吗？
他们在使用这个功能的时候会不会遇到一些障碍？
3.评估产品评估用户对产品的满意度。比如公司想给产品增加一个新功能，在正式开发之前，想测试一下用户是否满意。这个场景也适用于可用性测试。
4.了解用户可用性测试可以帮助我们的设计师和产品经理更深入、详细、直接地了解用户，了解他们的使用习惯和认知。
四。可用性测试流程概述可用性测试是一个持续循环的过程，大致可以分为五个阶段：测试准备、测试预热、正式测试、结果分析和最终优化方案阶段。
1.准备充分的可用性测试可以得到更好的结果。备考期间，我们要完成七步准备。
确定目标测试方案，测试脚本，招募用户，材料，工具，测试场地，考前提示：虽然要准备的东西很多，但是这些东西做好之后，后续的过程就会轻松很多。
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 协议
