Web易用大师1.可用性测试汇报内容汇报的具体内容汇报

可用性首先来自于二战期间的人因工程。当设计师研究新武器时，他们研究了如何使用它们、人类能力和特性的限制。国际标准 ISO 9241-11 将可用性定义为“特定用户在特定使用情况下为实现特定目标而有效、高效和令人满意地使用产品”。

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

一、典型用户和典型任务

可用性测试是用户体验研究中常用的一种方法，其核心在于对典型用户执行典型任务的观察记录，以发现产品设计中的可用性问题。对于这里的典型用户，最好招募实际使用产品的用户；二是产品的潜在用户或预期用户。他们现在可能不会使用我们的产品，但将来很有可能会使用我们的产品；认知排练方法。但越接近真实用户，效果越好。

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

二、可用性测试报告内容

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

1. 研究介绍

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

背景：描述当前测试产品所处的阶段和可用性测试需求的背景，并说明是由于客户需求、产品需求、UED验证还是优化需求等。

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

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

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

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

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

2. 结果概览

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

体验测量结果：整体测量指标包括SUS可用性评分和相应的评分、百分比评分；总体用户满意度、问题点统计、效率相关任务完成率、错误数、提示数和完成时间。可用性测试结束后，我们会向参与的用户发放一份问卷，包括SUS分数和总体满意度。SUS 可用性分数、等级和百分等级可以通过SUS 分数转换得到。如果同一个任务可用性测试不是第一次，可以与之前的测试测量结果进行对比，以体现产品优化效果的提升。如果不是，则仅显示此结果。有必要说明数据源和几个客户易用性测试 文档测试，几种类型的角色，

SUS 可用性分数：从用户分数转换以反映整体可用性。

评分：A、B、C、D 总评分，低于 D 表示产品可用性非常平庸，甚至很差。

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

SUS 可用性评分、评分和百分位评分之间的关​​系如下图所示（SUS 评分评分（Bangor et al.））：

总体满意度：接受产品可用性测试的用户的主观感受。我们通过 SUS 量表问卷中的附加满意度百分比得分获得它。

问题点统计与分类：从现场客户的思考和投诉、延伸访谈反馈、测试完成后的专家回顾性分析评价中得到的可用性问题总数，并对这些问题进行分类。

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

客户重点评价：包括客户的负面评价和正面评价，是以客户声音的方式最直观地反映对产品的评价，相信也是报告受众非常关心的一个点。该项目通常在延长采访中获得，可能不可用，因此对于报告内容是可选的。

问题与分类：获取可用性问题的汇总数量、计划实施的数量，获取体验优化建议的采纳率。问题分布和优先级的图形显示。

3. 过程分析

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

准备：说明招募用户的时间安排和约定的可用性测试；使用的测试回路和环境数据的准备；文档编制包括场景任务表、SUS体验测量与满意度调查问卷、用户行为记录表；测试过程中如何保存图像的说明，例如是手机拍摄的还是屏幕录制的，以及进行可用性测试的位置。比如真实客户测试一般会在客户现场进行，如果是内部用户，一般会在公司办公室进行。地方。

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

角色建立：通过用户角色模型的建立，观众可以了解测试用户的基本特征，包括姓名、职位、服务年限、使用系统的目标、日常系统使用情况等。并且在后续的具体场景中，进行角色替换，以形成与观众的共鸣。应该显示几种类型的字符。

基于场景的分析：包括场景任务描述、涉及的操作角色和功能、经验测量结果、问题描述和解决方案建议。如果被测任务之间存在线性关系，可以将它们以任务流的形式连接起来，方便观众对整体流程的理解。这里的经验测量结果是对单个任务的记录和分析，包括任务完成率、错误/提示次数、任务完成时间、问题点的统计和分类。我们还需要列出场景测试中的问题/痛点，并一一给出建议。对于问题，我们可以使用外部链接标记所拍摄的视频或图片，从而专注于问题的真实场景。有几个测试任务，

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

4. 后续计划

后续计划包括计划实施与验收计划、计划验证计划。解决方案实施验收计划：主要介绍可用性完成后的后续问题评估结果和执行者，即方案实施验收计划。

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

5. 附件

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

本文最初由@janinejly 发表于人人都是产品经理。禁止任何未经许可的复制。

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