引言：可用性测试作为用户体验研究中常用的方法，侧重于对典型用户执行的典型任务的观察记录，以此来发现产品设计中的可用性问题。本文对可用性测试进行了分析，希望对你有所帮助。

可用性最早源于人因工程学，起源于二战。当设计师研究新武器时，他们研究如何使用它们，人类能力的极限和特征。国际标准ISO 9241-11将可用性定义为“特定用户能够在特定的使用场景下，有效、高效、满意地使用产品，以实现特定的目标”。

易用的Web大师Nelson在可用性工程中将其定义为用户能否很好地使用系统的功能；有五个因素：可记忆性、效率、记忆、错误和满意度。我们软件产品的可用性评估属于界面窗口的评估，所以通常采用尼尔森的理论。

1.典型用户和典型任务的可用性测试是用户体验研究中常用的方法。其核心在于典型用户执行典型任务的观察记录，以此来发现产品设计中的可用性问题。这里的典型用户，最好是招募实际使用产品的用户；其次是产品的潜在用户或意向用户，他们现在可能不会使用我们的产品，但未来使用的概率很大；最坏的情况是，我们自己的人通过认知预演来评估它。但是越接近真实用户，效果会越好。

这里的典型任务是产品关键场景中的任务，指的是产品的核心功能，也是用户操作频率最高的功能。观察记录的研究人员通常由UED专家和产品经理组成。很多像我们这样的产品用户都是技术人员，在可用性测试的可扩展性面试中难免会交流一些技术问题，所以最好有另外一个开发人员参与。

二。可用性测试报告的内容可用性测试输出报告的具体内容包括调查介绍、结果总结、过程分析、后续计划和附件五个部分。

1.第一部分调查介绍，首先介绍本次可用性测试的背景和目标、人员和流程、测试任务。

背景：描述目前测试产品所处的阶段以及本次可用性测试需求的背景，说明是否出于客户需求、产品部门需求、UED验证或优化需求等。

目标：根据背景，描述这次可用性测试的预期目标。

测试人员：参与可用性测试研究的产品方成员，一般由UED、项目管理、开发等组成。

测试流程：描述本次测试的流程，一般采用可用性测试的标准化流程，即资源准备-任务设计-用户招募-前测-正式测试-测试报告。

招聘用户：介绍招聘用户的组织/部门、角色和数量。

测试：显示本次可用性测试涉及的任务列表、任务总数和功能总数。单个任务元素包括角色、任务类别、操作目标、场景任务描述和任务中涉及的功能。其中场景任务的描述最为关键，需要对任务的前台场景进行说明，让观众有画面感。

2.结果总结。第二部分是整个可用性测试的最终结果，包括体验测量结果、关键客户评价，以及通过用户反馈和专家分析整理出的可用性问题概述。

体验测量结果：总体测量指标包括SUS可用性得分、对应评级和百分比等级；整体用户满意度、问题统计、任务完成率、错误数、提示数、完成情况等效率相关指标时间。可用性测试结束后，我们会向参与的用户发放调查问卷，包括SUS评分和整体满意度。SUS可用性分数、评级和百分比可以通过SUS分数转换获得。如果同一个任务可用性测试不是第一次，可以和之前的测试测量结果进行对比，以反映产品优化后的效果提升。如果没有，将只显示这个结果。解释数据源和几个客户，几类角色，几个用户和几个有效问卷。

SUS评分：通过换算用户的分数来反映整体的可用性。

评级：共A、B、C、D级。如果低于D，说明产品的可用性很一般，甚至很差。

百分比评级(Percent rating):指被测产品或系统相对于通用数据库中其他产品或系统的可用性[Jeff Sauro(2011)通过了446项研究，对于我们目前的产品来说存在一些缺陷，但在没有更权威的选择的情况下，值得应用]。例如，SUS得分为73，其百分比等级约为67，这意味着它比约67%的产品更可用。

下图显示了SUS评分、评级和百分比之间的关系(SUS评分(Bangor等人)):

总体满意度：用户在可用性测试后对产品的主观感受，通过对SUS量表问卷所附的满意度百分比体系进行评分获得。

点数统计和分类：来自现场客户反映、延伸访谈反馈、测试完成后专家回顾性分析评估的可用性问题总数，并对这些问题进行分类。

任务完成率：通过可用性测试时的观察记录表记录用户是否完成了任务，错误次数，提示次数，完成情况时间。完成率由角色维度的所有用户数据的加权平均值计算得出。由于B端产品的复杂性，可用性测试过程中不可控因素太多，往往无法准确获得错误/提示的数量和完成情况时间。所以我们只是通过专家讨论，把完成率作为报告中的必录项。

客户重点评价：包括客户的差评和好评，是表达客户对产品评价最直观的方式，相信也是报告受众关注的重点。这一项往往是在延伸访谈中获得的，可能没有，所以是报告内容的可选项。

以及问题分类：获取可用性问题的汇总数量和计划落地数量，从中获取体验优化建议的采纳率。问题分布和优先级的图形显示。

3.过程分析详细阐述了可用性的整个过程。包括准备工作的介绍，用户角色的建立，场景任务的具体分析，问题汇总表以及评测结果。

准备：说明时间对于招募用户和协议可用性测试的安排；准备用过的测试环和环境数据；文档的准备包括场景任务单、SUS体验测量与满意度问卷、用户行为记录表；如何保存测试过程图像的描述，比如是用手机拍的还是录在屏幕上的，可用性测试进行地点的描述。例如，真实的客户测试通常在客户的站点进行，内部用户通常在公司的办公室。

场景分析：场景分析通过描述谁在什么情况下做什么，存在什么问题以及如何解决这些问题来描述可用性问题和建议。先对场景分析做一个简单的说明，再说明场景分析中用户痛点的具体来源。在可用性测试中，问题通常来自用户在任务测试过程中的思考和寻求帮助。任务结束后延长面试；全程测试后专家分析评估。

角色建立：通过用户角色模型的建立，让受众了解测试用户的基本特征，包括姓名、岗位、岗位工龄、使用系统的目标、系统的日常使用情况等。并在后续特定场景中替代角色，以引起观众的共鸣。应该展示几种角色。

场景分析：包括场景任务描述、操作角色和涉及的功能、体验测量结果、问题描述和建议。如果被测任务之间存在线性关系，可以以任务流的形式串联起来，便于受众了解整个过程；否则，可以在角色或任务维度中直接展开。这里的体验测量结果是对单个任务的记录和分析，包括任务完成率、错误/提示次数、任务完成时间、问题统计和分类。我们还需要列出场景测试中的问题/痛点，并逐一给出建议。对于问题，我们可以通过外部链接对抓取的视频或图片进行标记，从而聚焦问题的真实场景。如果有几个测试任务，有必要展示几个场景任务分析。

问题总结和评估结果：在流程分析的最后，我们会得到一个问题总结，也就是通过场景分析最终得到的可用性问题列表。从角色维度阐述任务类别、运营目标、涉及功能、问题描述、建议解决方案、问题类别和优先级，并标注视频时间段/截图，方便问题定位和追溯。这部分内容可以放在PPT里，也可以根据量级显示为附件。

4.跟进计划跟进计划包括计划落地和验收计划以及计划验证。计划落地和验收计划：主要介绍可用性完成后后续问题的评估结果和执行者，即计划落地和验收计划。

方案验证计划：是对优化后的产品再次进行可用性测试的计划描述，或者是优化后招募用户回访的计划描述。

5.附件在输出的最后，我们附上相关附件，提及升本可用性测试的可靠性。根据实际情况，可以展示测试中用到的文档，如可用性测试任务、测试现场图片、SUS体验测量和满意度问卷收集、任务测试记录表等。

本文由@janinejly原创发布。每个人都是产品经理。未经许可，禁止复制。

题目来自Unsplash，基于CC0协议。