手把手教你如何进行可用性测试汇报-产出汇报篇

可用性最早来源于人因工程，起源于二战时期，设计人员研究新式武器时，研究如何使用，人的能力限度和特性。国际标准ISO 9241-11对可用性的定义是“特定的用户在特定的使用情景下，有效、有效率、满意的使用产品达到特定的目标”。

Web易用大师尼尔森在可用性工程中将其定义为用户能否很好地使用系统的功能；分为五个因素：可学习性（learnability）、效率（efficiency）、可记忆性（memorability）、出错（errors、满意度（satisfaction）。我们软件产品可用性评估属于界面视窗的评估，因此通常采用的是尼尔森的理论。

一、典型用户与典型任务

可用性测试（Usability Testing）作为用户体验研究中常用的一种方法，其核心在于对典型用户执行典型任务的观察记录，以发现产品设计中存在的可用性方面的问题。这里的典型用户，最好就是招募真正使用产品的用户；其次是产品的潜在用户或者意向用户，他们现在可能没使用我们的产品，但是未来有大概率可能使用；再不济就是我们内部自己人以认知预演的方式进行评估。但越是接近真实用户，效果是越好的。

那这里的典型任务，就是产品关键场景下的任务，是指产品的核心功能、用户操作频度最高的功能。作为观察记录的研究人员，通常是由UED专家、产品经理构成，像我们产品的用户很多都是技术人员，在可用性测试的扩展性访谈中，难免会沟通一些技术性问题，所以最好再有一个开发人员的参与。

二、可用性测试汇报内容

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

1. 调研介绍

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

背景：对当前测试产品所处的阶段以及本次可用性测试需求产生的背景进行描述，说明是由于客户需求呢还是产品部需求还是UED验证或优化需求等。

目标：基于背景前提下，描述本次可用性测试期望达成的目标。

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

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

招募用户：介绍招募到的用户所属机构/部门、角色及人数。

测试任务：展示本次可用性测试的任务单，任务总数与涉及功能总数。任务单要素包含角色、任务大类、操作目标、场景任务描述、任务涉及的功能。其中场景任务描述最为关键，需要交代任务的前置场景，让受众能够产生画面感。

2. 结果概述

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

体验度量结果：整体度量指标包括SUS可用性评分与对应的评级、百分等级；用户整体满意度、问题点统计以及效率相关的任务完成率、错误次数、提示次数、完成时间等指标。我们在可用性测试结束后，会发放问卷给参与用户，包含SUS评分与整体满意度。通过SUS评分换算可得到SUS可用性评分、评级及百分等级。如果相同的任务可用性测试不是首次，则可与之前的测试度量结果做比较，以体现产品优化后的效果提升。若没有，则仅展示本次结果。需要说明数据来源与几家客户、几类角色、几位用户、几份有效问卷。

SUS可用性评分：通过将用户打分转换而来，反应总体可用性。

评级：一共为A、B、C、D四个评级，低于D则表示产品可用性极为一般，甚至糟糕。

百分等级：是指测量的产品或系统相对于总数据库【Jeff Sauro（2011）通过446个研究，对于我们目前的产品有一定缺陷，但在没有更权威的选择下，值得应用】里其他产品或系统的可用性程度。比如SUS得分是73分，其百分等级大约为67，意味着比大约67%的产品可用性更好。

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

整体满意度：接受可用性测试的用户对产品的主观感受，我们通过在SUS量表问卷中额外附带的满意度百分制打分获取。

问题点统计与分类：来自现场客户发生思考吐槽、扩展性访谈反馈以及测试完成后的专家回顾分析评估得出的可用性问题总数，并对这些问题进行归类。

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

客户重点评价：包括客户差评与好评，是最为直观的以客户发声方式体现对产品的评价，相信也是报告受众非常关注的点。此项往往在扩展性访谈中获取，且未必能够获取到，因此作为汇报内容的可选项。

问题及分类：得出可用性问题汇总数量、计划落地数量，并从中得出体验优化建议的采纳率。图形化展示问题分布及优先级。

3. 过程分析

对可用性整个过程进行详细的阐述。包括准备工作介绍、用户角色建立、场景化任务具体分析及问题总表与评估结果。

准备工作：说明对招募的用户及约定的可用性测试的时间安排；所使用的测试环及环境数据的准备；文档的准备包括场景化任务表、SUS体验度量与满意度调研问卷、用户行为记录表；测试过程影像保存的方式说明，比如是通过手机拍摄的还是录屏的、可用性测试执行的场所说明，比如真实客户测试的话一般都会在客户现场进行，如果是内部用户的话一般都会在公司的办公场所。

场景化分析：场景化分析是通过描述什么人在什么情况下做什么，存在什么问题，建议如何解决的方式，描述可用性可用性问题及建议。首先对场景化分析做简单的说明，然后交代场景化分析中的用户痛点具体来源。可用性测试中，问题通常来源于任务测试过程中的用户发生思考、请求帮助；任务结束后的扩展性访谈；整个测试结束后的专家分析与评估。

角色建立：通过用户角色模型的建立，让受众了解测试用户的基本特征，包括姓名、岗位、岗位工龄、使用系统的目标、日常系统使用情况。并在后续具体场景中进行角色代入，以便于与受众之间形成共鸣。有几类角色就应展示几个。

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

问题总表及评估结果：过程分析的最后，我们将得出一张问题总表，也就是通过场景化分析最终得出的可用性问题列表。以角色维度，说明任务大类、操作目标、涉及功能、问题描述、建议方案、问题类别、优先级，并对标视频时段/截图，便于问题定位追溯。这部分内容可根据量级决定放在PPT内还是以附件形式展示。

4. 后续计划

后续计划包括方案落地及验收计划、方案验证计划。方案落地及验收计划：主要介绍可用性完成后的后续问题评估结果、执行人等，也即方案落地及验收计划。

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

5. 附件

在产出物的最后，我们附上相关的附件，提升本次可用性测试的信度。大家可以根据实际情况，展示测试中用到的文档如可用性测试任务、测试现场影像、SUS体验度量与满意度问卷收集情况、任务测试记录表等。

本文作者@janinejly 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！