可用性测试 如何进行可用性测试？这里有一份全面的可用性测试指南

可用性测试是通过观察用户使用产品完成的典型任务，找出产品中与效率和满意度相关的问题的方法。那么如何测试可用性呢？这里是综合指南。

什么是可用性？

任何能与人互动的产品都应该有。就一般产品而言，可用性被定义为目标用户可以轻松使用产品来实现特定目标。

ISO9241/11中的定义是:

特定场景中的特定用户可以有效地、高效地和令人满意地实现产品。

人机交互专家雅各布·尼尔森将可用性框架定义为:

可学习性：初次接触这个设计时，用户完成基本任务的难易程度？效率：用户了解了设计之后，能多快地完成任务？可记忆性：当用户一段时间没有使用产品后，是否能轻松地恢复到之前的熟练程度？错误：用户犯了多少错误，错误严重程度如何？用户能否从错误中轻易地复原？满意度：用户对产品的主观满意度，这个设计让用户感觉如何？ 什么是可用性测试？

可用性测试主要用于网站或移动应用的设计评估。其实也可以用于智能硬件的完整体验过程。目标受众中的真实用户通常被邀请在特定场景下通过产品完成典型任务。

在实际使用过程中，观察用户的实际操作情况，详细记录和分析用户在产品使用中遇到的问题，目的是发现产品中的可用性问题，收集定性和定量数据，帮助产品改进，确定目标用户对产品的满意度。

简单来说，可用性测试就是通过观察用户用产品完成典型任务的情况，找出产品中与效率和满意度相关的问题的方法。

为什么要测试可用性？

可用性测试是改进产品的极好方法。

有时候，我们不是产品的目标用户，很多需求和设计方案都是产品设计师自己想出来的。讨论方案的时候总会说:“用户想要……”“我觉得……”“如果是我，我会……”。虽然设计会基于一些经验和设计规则，但这些只是未经验证的主观猜测，不能准确评价设计方案的优劣，往往会导致对立的观点和僵持。

所以，为了了解真相(用户会如何使用产品)，我们要找到我们的目标用户，向他们学习(观察他们是如何使用产品的)，让团队尽快就设计方案达成一致，积极改进产品。

通过可用性测试，我们可以:

了解真实用户如何与产品进行交互并；了解真实用户是否能够完成指定任务；了解真实用户完成指定任务需要多久；了解真实用户对产品与竞品的满意度；确定改进产品可用性问题所需的修改；定性分析可用性并查看是否符合目标；让设计和开发团队在开发前发现问题。 可用性测试类型

可用性测试有三种类型(进行可用性研究的原因):

探索性可用性测试：在发布新产品之前，探索性可用性测试可以确定新产品应包含哪些内容和功能，以满足用户的需求。在产品开发早期，探索性可用性测试可以评估初步设计或原型的有效性和可用性。评估性可用性测试：在发布前或发布后对最新版本的测试，通过评估性可用性测试向用户介绍新设计，以确保其直观使用并提供良好的用户体验。评估性可用性测试的目的是——确保在产品推出之前突出并修复任何潜在问题。比较性可用性测试：比较两种或更多种产品或设计的可用性，并区分各自的优缺点，以确定哪种设计能提供最佳的用户操作体验。

论文原型测试来源:mediamatic.nl

可用性测试方法

产品可用性测试方法分为分析方法和实验方法。

1.分析法

一种让产品可用性工程师和用户界面设计师等专家根据自己的专业知识和经验进行评估的方法。

特点:主观，评价结果是假设性的，时间少，费用少，评价范围广，可以在设计初期进行评价。

可用性检查阶段经常使用分析方法，常见的分析方法包括但不限于:

专家评审:评审由精通设计可用性概念的专家进行，基于自己的专业知识和经验对产品进行评审。

启发式评估:让可用性专家判断每个页面和元素是否遵循既定的可用性原则。

认知穿越:设计师模拟用户在使用产品过程中的每一个操作步骤所遇到的问题，检查用户的任务目标和心理认知是否能成功进行下一步操作。

每个操作都有四个问题:

用户是否知道自己要做什么？用户在探索用户界面的过程中是否注意到操作方法？用户是否把自己的目的和正确的操作方法关联到一起？用户能否从系统的反馈中判断出任务是否在顺利进行？

通过回答每个操作步骤的问题，可以发现可用性问题。

多走一步:认知走一步的变体，使用小组会议，用户、开发者、人的因素使人一步一步讨论操作过程中的每一个交互页面和元素。

一致性检查:让代表多个其他项目的设计者检查接口，看它是否以与他们自己的设计相同的方式运行。

2.实验法

收集真实的用户使用数据，典型的方法是用户测试，问卷调查等方法也属于这一类。

特点:客观、时间长、成本高、评价范围窄。为了进行评估，必须准备原型。

可用性测试阶段(用户测试阶段)经常使用实验方法。常见的实验方法包括但不限于:

卡片分类：通常用于测试分类或导航结构，让用户将一组写有信息的卡片分组，并为其分配名称或标签。卡片分类有助于了解用户如何看待内容以及他们如何组织信息，从而决定在每个页面放置什么，对于页面或功能分类很有帮助。面对面测试：由一个或多个观察者在诸如会议室的固定环境中运行，或者与小团体或个人进行。要求用户完成一组任务，观察者可以随时与他们交互以提出问题或进一步探究。远程测试：在远程测试中，用户在自己的环境中执行一系列任务，通过软件记录完成任务的过程，软件自动记录用户的点击位置和交互过程，并记录他们在使用网站或应用程序时发生的关键事件以及用户提交的反馈。这种类型的测试可以由主持人（使用网络研讨会或电话会议技术）完成，也可以作为自我测试。A / B测试：为网站或应用程序的界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析评估出最好版本正式采用。走廊测试：使用随机的人来测试网站，而不是那些在测试网站方面训练有素和经验丰富的人。这种方法对于在开发过程中首次测试新网站特别有效。纸张原型测试：创建一个粗糙的，甚至是手绘的界面图形以用作设计的原型。让用户通过原型来执行任务，该方法能以极低的成本在编码完成之前对设计进行测试。问卷调查：问卷的优势在于可以收集结构化的数据，且价格低廉，不需要检测设备，结果反映了用户的意见。

分析方法和实验方法的主要区别在于是否有用户参与。

分析方法的参与者是具备可用性知识的设计师和工程师；实验方法的参与者是目标用户或小白用户。在某种程度上，分析方法和实验方法是相辅相成的。

通常，在设计用户测试时，首先在可用性检查阶段通过分析来检查可用性问题，并根据其重要性对检查的问题进行排序，然后在可用性测试阶段使用用户测试来关注观察和验证。

分析方法最大的缺点是，它只得到分析师的假设或意见，当团队不同意时，它不能提供强有力的证据来支持自己的意见。为了结束争论，只能通过实验的方法。

其次，重点介绍了分析方法中的启发式评价方法和实验方法中的一对一用户测试。

可用性测试实验室来源:u-sentric.com

启发式评价1。启发式评估导论

由于专家评审过于依赖自身的专业知识和经验，为了得到更客观的结果，Jakob Nielsen创造了一种基于多年可用性工程经验的启发式评估方法。

启发式评估使专家能够根据普遍接受的可用性原则检查用户界面中的可用性问题，然后根据一系列原则对它们进行分类和评分。雅各布·尼尔森的十大启发式评估原则(尼尔森十大交互法则)是业界最常用的可用性评估原则。

此外，还有格哈德-波尔斯的认知工程原理、温申克和巴克的分类、ISO 9421对话原理等。

2.启发式评价原则

雅各布·尼尔森(Jakob Nielsen)倡导的启发式评估的十个原则如下:

系统状态的可见性：系统应该在合理的时间内做出适当的反馈，始终让用户了解正在发生的事情。系统与现实世界的匹配：系统应使用用户的语言，用户熟悉的词语和概念，而不是系统导向的专业术语。遵循现实世界的惯例，使信息以自然和合乎逻辑的顺序出现。用户控制和自由：用户有时会误操作，要提供任何时候都能从当前状态跳出来的出口，保证能够及时取消或者再运行执行过的操作（支持撤消和重做）。一致性和标准化：不应让用户怀疑不同的词语、情况或行为是否意味着同一件事。保证用户在同样的操作下得到相同的结果。预防错误：提前预防错误的发生，这种防患于未然的设计要比适当的错误提示更胜一筹。消除容易出错的条件或检查它们，并在用户采取行动之前让用户再次确认是否进行该操作。识别而不是回忆：通过使对象，动作和选项等可视化，从而最大限度地减少用户的认知负担，使用户无需回忆，一看就懂。尽量不要让用户从当前对话切换到别的对话时还必须记住某些信息，系统的使用说明应该是可见的，或者适当时可以轻易地检索。灵活性和效率：加速器功能（初次接触的用户看不到该功能）通常可以提升专家用户的操作效率，从而使系统能够迎合无经验和有经验的用户，允许用户能够单独调整会频繁使用的操作。审美和极简主义设计：对话不应包含无关或极少需要的信息，对话中的每条附加信息都会与关键信息形成竞争，并降低其相对可见度。帮助用户识别，诊断和从错误中恢复：错误消息应以简单的语言表示，精确地表明问题，并建设性地提出解决方案。帮助和文档：即使系统在没有帮助文档的情况下也可以使用良好，但还是有必要提供帮助和文档。这样的信息应该易于搜索，针对用户要执行任务列出具体步骤。 3. 启发式评估法的实施步骤

第一步:招募评估者

根据雅各布·尼尔森(Jakob Nielsen)的研究，在一个人的评价中只能发现大约35%的问题，因此需要大约3~5个人才能得到一个安全的结果。有资格担任启发式评估职位的可以是用户体验设计师、交互设计师、UI设计师等。界面原设计者不适合对界面进行评价，因为评价结果可能不够客观，或者问题直接修改而没有反馈。

第二步:制定评估计划

产品的所有功能都很难评价，需要提前决定评价界面的哪些部分，评价哪些原则(Gerhardt-Powals的认知工程原则，Weinschenk和Barker的分类，ISO 9421对话原则等)。).

第三步:实施评估

最好对界面进行两次评估:第一次检查界面的流程是否正常，第二次详细检查每个界面是否有问题。应禁止评价者之间的讨论，以避免评价结果受到权威人士的影响。

第四步:召开评估者会议

评估人员完成自己的评估后，应召开一次集中会议，报告评估结果。在会议上描述问题的同时显示界面更有效率。

启发式评价的优势在于，通过对个体评价的二次筛选，以及评价者之间的讨论，可以发现一个人无法发现的跨度较大的问题。

第五步:总结评估结果

总结了所有的评价结果后，就可以整合评价问题列表了。多个表达式可能有问题，需要适当整理问题列表。

步骤6:输出总结报告

启发式评估方法的输出结果是产品可用性问题列表，但如果只给出列表，其他成员可能很难理解。所以最好输出一份简短的启发式评估报告，并附上截图和流程图。

启发式评估报告(HE报告)主要包括:

出现问题的界面和位置，关键事件或问题出现在用户界面的哪个位置？启发式的名称，引用了十个启发式原则中的哪一个？被评价为否定或肯定的原因，解释为什么界面会违反或符合该启发式？问题的范围，描述问题的范围，是贯穿整个产品还是在某个界面？问题的严重程度(高/中/低），评估问题的严重程度。评定其严重程度的理由，给它高/中/低的原因。修复建议，对问题的改进建议。可能的权衡（为什么修复可能会不起作用），提及这些权衡可以增加报告的可信度。

启发式评估问题列表示例

4.启发式评估方法的局限性

平心而论，启发式方法旨在作为一种帮助新手实践者进行可用性测试的脚手架，因此无论如何都不能与专家可用性测试方法相提并论。而且只有专家才能通过可验证的方法发现问题，而不是使用启发式方法。

启发式评价方法是许多专家根据自己的经验和启发式原则对用户界面进行评价，因此必然会发现许多问题。而且启发式评估方法的实施需要很多专家在有限的天数内工作，成本也高。

所以启发式评价要根据实际情况进行简化，可以简单的由一两个专家进行评审。这种做法叫启发式。但在没有提供客观判断标准的情况下，加上检查人员数量较少，评价结果可能会被指责为“这些问题只是检查人员的主观想法”。

由于资源有限，不可能进行正式的启发式评价而改为简单的复习，注意:

不应以个人偏好，而应以理论依据进行评价。评价的目的不是挑错，更应给出合理建议。当团队意见不一致时，与其争论不如通过实验得出结论。

用户测试方法来源:rainforestqa.com

用户测试1。用户测试介绍

在用户测试中，可用性工程师对用户进行一对一的访谈(理想情况下，观察者和用户不认识，以便收集更客观的数据)，其他成员在听音室观察整个访谈，全程记录用户操作电脑时的界面和声音。

可用性测试的基本内容是一样的:为用户搭建一个场景，让用户通过产品完成特定的任务，观察用户在执行任务过程中遇到的问题。

2.用户测试的常用方法

性能测试的局限性:当任务完成率只有20%的时候，团队只知道这个任务的执行效率很低，却不知道用户为什么没有完成任务，所以会觉得无所适从。

语音思维可以解决这个问题，但是在实际操作过程中，只要面试官不提问，用户就不会主动说话。如果你提出一个问题，用户可能会停止动作并解释，所以测试完成任务的时间是没有意义的。

缺少引起思考的性能测试没有任何意义，但是如果两种方法同时实现，就需要很大的预算。因此，只要量化数据的必要性不明确，就不应该实施性能测试。我们不需要在定量数据测试上浪费有限的资源。相反，只需要几个人参与测试的重复发生思维方法，可以更好的改善界面。

3.用户测试的实施步骤

第一步:设计任务

可用性评估是以任务为基础的，任务设计的质量可以直接影响测试结果的准确性。所以在招用户之前，首先要为产品设计任务。比如一个购物APP设定的任务，可以是买一件价格高于100元的t恤。

如果你想设计一个合适的任务，你应该注意以下几点:

理论上，招聘对象的选择应该是产品的典型目标用户，但仍然需要定义具体的用户特征，即招聘条件。

招聘条件可以从前期市场调研阶段建立的用户画像中提取用户特征，尽可能代表未来的真实用户。如果将目标用户画像分为几类，则要求招募的用户中包含所有类型的用户。

招募的用户应该有能力使用产品执行任务。比如我们肯定不会找不太会用电脑的人去体验桌面软件。

我通常会找到两种类型的用户来体验产品:

一类是有同类型产品使用经验的用户；另一类是完全没使用过类似产品的用户。

因为我的产品目标是降低同类产品的操作复杂度，让小白用户轻松上手，而这两类用户可能会发现完全不同的问题。

4.可用性脚本示例

评测对象：XX购物APP。招募条件：一二线城市90后，有在线购物的经历。参与者人数：5名。测试时间：60分钟。酬劳：咖啡一盒。

第四步:试点测试

中试可以理解为可用性测试前的预演。再周密的计划，没有实践也不会发现计划中的问题。先导测试的目的是对测试计划进行测试，从而发现测试计划中的疏漏并及时修复，避免浪费测试资源。

试点测试的用户一般可以找同事充当，但要保证测试地点和相关材料与实际测试完全一致。

然后，您可以开始可用性测试流程，重点是:

台词和任务卡片的设计，是否可以准确传达信息？台词和任务卡片是否透露了操作步骤，用户是否很快的完成任务？任务时间安排是否合理，用户是否可以在规定时间内完成任务？任务流程安排是否合理，用户是否感到莫名其妙？

最后，根据中试中发现的问题，修复和完善试验方案。

第六步:观察&面试

(5)采用回顾性方法提问

用户测试中有时会出现问题，但由于某种原因，我们不方便打断用户的深入提问，或者用户通过发生思维的方法遗漏了一些信息。这时，测试完成后，测试人员应该对测试中的问题提出问题。

比如:“你刚在XX界面呆了很久，能告诉我你当时在想什么吗？”这样，测试中缺失的信息可以通过回溯法完成。

第七步:分析

(1)整理数据，判断产品是否需要迭代

通过用户测试，我要求学生判断交互设计是否达到用户体验的目标水平。分析数据的第一步是整理测试结果，通常会画一张表，表中通常包含任务、用户体验目标、任务基准值、任务目标值、目标是否完成等信息。

如下图所示:

可用性测试数据对照表示例

然后通过直接比较观察结果和用户体验目标，就可以知道哪些用户体验目标已经实现，哪些没有实现。如果没有达到体验目标，资源充足，就需要迭代产品。这时候就需要具体分析每个用户体验问题，输出解决方案。

(2)分析问题的影响程度

不是所有的问题都是平等的，有些问题会带来负担，用户必须先处理好，才能继续原来的问题。其他错误可能会给用户带来情感问题，让用户重复操作，但不会造成新的问题。

了解问题的严重性可以帮助我们更好地确定用户体验问题的优先级。我们通过问题的性质和频率来确定问题的影响程度。

问题的性质一般按照效果问题>效率问题>满意度(或者速度>误差>满意度)的顺序来评价。

效果相关问题导致用户无法或几乎无法完成任务，而效率问题导致用户做无用的工作，想太多，做错的操作更多。满意度问题导致用户表达不满，问题出现的频率由发现问题的人数决定。

不管测试多少人，我们用三个范围来表示频率:一个人，几个人，所有人(几乎所有人)。比如10人可能分为3类:1人，2~7人，8~10人。

然后，我们根据问题的性质和频率创建一个表，如下图所示:

问题影响分析表示例

列代表问题出现的频率，行代表问题的性质。标黄色的问题定义为必须解决的问题，标绿色的问题是最好解决的问题，标蓝色的问题是资源丰富可以解决的问题。资源总是有限的，不可能解决每一个问题。我们必须通过分析问题的影响程度来确定要解决的问题。

(3)对用户体验问题进行描述

用表格维护用户体验问题的数据比较简洁，不利于别人了解细节和参考。所以我们需要为每个问题补充一些信息，让用户体验问题的例子在数据分析中变得更有价值。

我们需要做的是了解每一个问题，了解其产生的原因和可能的解决方案，合并代表同一个用户体验问题的多个用户体验问题(肯定会有重复的问题)，认清问题之间的潜在关系。

用户体验问题描述通常包含以下信息:

问题概述：从用户角度描述产品存在的问题，比如：“没有返回按钮”应描述为“用户无法返回上一级页面”。用户任务：提供问题发生的背景，帮助我们了解用户想进行什么操作时发生了什么样的问题。用户目标：一个任务可能会分为多个目标，用户目标描述用户具体为了达到什么目标时碰到的问题。问题详述：对用户体验问题详细的描述，比如：用户在什么页面，进行了什么操作，界面发生了怎样的交互等。问题分析：从设计师角度对问题进行分析，比如：为什么产品没有按用户期待的方式运行？是什么导致了用户无法完成任务或产生消极情绪？这样的解释会往往会为可行的问题解决方案提供线索。解决方案：针对问题产生的原因提出可能的解决方案。

第七步:重新设计

一般来说，我们会对每个问题给出一个解决方案。但往往不是这样，有时问题和解决方案之间并没有一一对应的关系。如果每个问题都有解决方案，产品的复杂性可能会增加。

有时候，一个解决方案可以解决多个问题，这就需要我们深刻洞察每个问题与其成因之间的关系。如果能从根本上解决问题，产品质量会大大提高。

这就要求我们跳出原来一对一的思维，先从宏观层面把这些问题群体作为一个整体来分析，而不是孤立的问题。在设计解决方案之后，为了更好地管理问题，需要对解决方案的成本、优先级等信息进行整理&解决方案信息表可以将这些用户体验问题及其解决方案作为产品需求进行管理。

如下图所示:

问题&解决方案信息表示例

需要注意的是:不要以为按照设计方案修复就解决了用户体验问题。解决方案只是我们的假设，假设这个修复方案可以解决问题，所以为了验证假设，我们要不断通过可用性测试来验证新方案。

这是一个贯穿产品开发过程的连续循环:不断发现问题——分析问题原因——修复问题——测试问题是否已经解决。修改设计可能会让用户体验变差，所以在设计时要考虑用户体验问题的修复是否会造成新的问题。

步骤8:输出可用性测试报告

可用性报告的价值在于:记录评估过程，帮助组织了解测试过程和内容。为了给产品开发过程提供有价值的信息，开发团队可以了解问题，然后更好地进行开发。

沟通信息，说服涉众，可用性测试报告可以合理的告诉涉众我们的结论不是基于空，方便资源应用。此外，它还可以传递评估结果，建立用户体验意识。

可用性报告通常包括:

对产品的描述。测试目标。对参与者数量和画像的描述。测试时所执行的任务。测试的实验设计。采用的评估方法。采用的可用性度量指标和数据收集方法。数据结果，包括图形可视化的展现。对问题的描述。对产生问题原因的分析。对问题的严重程度和影响范围的评估。建议的解决方案。 可用性测试常见问题

(1)可用性测试在设计过程中进行得太晚

如果你在产品发布之前不考虑可用性测试，你就没有时间和金钱来解决任何问题。更糟糕的是，你可能会以错误的方式浪费大量精力开发可用性差的产品。

事实上，在整个产品开发周期中重复进行小规模测试是最合适的。产品完成初步原型后，可以先进行可用性测试，快速发现问题，及时修改，避免上线后修改造成的成本浪费。

(2)感觉可用性测试很专业，需要大量的人力财力，所以干脆不做了

因为效益无法量化，项目进度紧张，总是被忽略。其实可用性测试的门槛很低，不用等产品完成，也不用专家来做，也不一定需要专业的设备。只要有一个观察用户操作产品的环境，多少会发现一些可用性问题。

其他小问题就不细说了。希望本文对读者有所帮助。由于作者很长时间没有接触过可用性测试，因此本文不可避免地存在一些缺点、问题和不清晰的描述。希望读者多多指正，谢谢。

参考

10 Usability Heuristics for User Interface DesignComparison of usability evaluation methodsReporting Usability Test ResultsWrite Better Qualitative Usability Tasks: Top 10 Mistakes to AvoidTurn User Goals into Task Scenarios for Usability TestingReporting Usability Test ResultsAn Introduction To Website Usability Testingrunning-usability-tests可用性測試(Usability Testing)小撇步破茧成蝶UX权威指南用户体验与可用性测试

这篇文章最初是@邵叔发表的，大家都是产品经理。未经允许，禁止复制

由标题地图的作者提供