编者:可用性测试作为用户体验研究中常用的方法，其核心在于对典型用户执行的典型任务的观察记录，从而发现产品设计中的可用性问题。本文作者对可用性测试进行分析，希望对你有所帮助。

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

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

可用性测试作为用户体验研究中常用的方法，侧重于典型用户执行典型任务的观察记录，以发现产品设计中的可用性问题。这里的典型用户，最好是招募真正使用产品的用户；其次，产品的潜在用户或意向用户现在可能不会使用我们的产品，但未来有很大概率会使用。最糟糕的是我们自己人用认知预演来评价。但是越接近真实用户，效果越好。

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

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

1.调查和介绍

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

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

目的:基于背景，描述可用性测试的预期目标。

测试人员:参与可用性测试研究的产品方成员，一般由UED、PM、开发等组成。

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

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

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

2.结果摘要

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

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

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

评级:有A、B、C、D四个评级，如果评级低于D，说明产品的可用性极其一般，甚至很差。

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

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

总体满意度:用户通过可用性测试对产品的主观感受是通过SUS量表问卷中的附加满意度百分位数得分获得的。

问题点的统计和分类:测试完成后，从现场客户反映、广泛的访谈反馈和专家的回顾性分析评估中获得的可用性问题的总数，并对这些问题进行分类。

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

关注客户评价:包括客户的差评和好评，是客户声音反映产品评价最直观的方式，相信也是报告受众非常关注的一点。这一项往往在扩大访谈中获得，也可能没有获得，所以对于报告内容是可选的。

以及问题分类:得到可用性问题的汇总量和计划落地量，进而得到体验优化建议的采纳率。问题分布和优先级的图形显示。

3.过程分析

详细阐述了可用性的全过程。包括准备工作的介绍、用户角色的建立、场景任务的具体分析、问题总表和评估结果。

准备:解释招募用户的时间表和约定的可用性测试；准备用过的测试回路和环境数据；文档的准备包括场景任务表、SUS体验测量与满意度问卷、用户行为记录表；如何保存测试图片，比如是手机拍摄还是屏幕录制，进行可用性测试的地点，比如真实客户测试一般在客户现场进行，内部用户一般在公司办公室。

场景分析:场景分析通过描述谁在什么情况下做什么，存在什么问题，以及如何提出解决方案来描述可用性问题和建议。先简单解释一下场景分析，再解释一下场景分析中用户痛点的具体来源。在可用性测试中，问题通常来自用户在任务测试过程中的思考和寻求帮助。任务结束后的扩大采访；全程测试后专家分析评估。

角色建立:通过用户角色模型的建立，受众可以了解测试用户的基本特征，包括姓名、岗位、岗位工龄、使用系统的目标以及系统的日常使用情况。并在随后的特定场景中进行角色替换，从而引起观众的共鸣。应该显示几种类型的角色。

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

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

4.后续计划

后续计划包括计划落地和验收计划以及计划验证计划。计划落地和验收计划:主要介绍可用性完成后后续问题的评估结果，实施者等。，即计划落地和验收计划。

方案验证计划:指再次优化产品可用性测试的计划说明，或优化落地后招募用户回访的计划说明。

5.附件

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

本文由@janinejly原创，人人都是产品经理。未经许可，禁止转载。

图片来自Unsplash，基于CC0协议。