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

纸原型测试来源：mediamatic.nl

可用性测试方法

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

1. 分析法

让产品可用性工程师及用户界面设计师等专家，基于自身专业知识和经验进行评价的一种方法。

特点：主观、评价结果是假设的、时间少、费用少、评价范围广、设计初期也可以评价。

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

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

启发式评估：让可用性专家判断每个页面及元素是否遵循已确立的可用性原则。

认知走查：设计师模拟用户在使用产品过程中的每个操作步骤所遇到的问题，检查用户的任务目标和心理认知是否可以顺利执行下一步操作？

针对每步操作提出四个问题：

1. 用户是否知道自己要做什么？

2. 用户在探索用户界面的过程中是否注意到操作方法？

3. 用户是否把自己的目的和正确的操作方法关联到一起？

4. 用户能否从系统的反馈中判断出任务是否在顺利进行？

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

多元走查：认知走查的变体，使用小组会议，其中用户、开发人员和人为因素让人们在场景中逐步讨论操作流程中的每个交互页面及元素。

一致性检查：让代表多个其他项目的设计人员检查界面，以查看它是否以与他们自己的设计相同的方式进行操作。

2. 实验法

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

特点：客观、评价结果是事实、时间长、花费大、评价范围较窄、为了做评价，必须准备原型。

实验法常用于可用性测试阶段（用户测试阶段），常见的实验法包括但不限于：

• 卡片分类：通常用于测试分类或导航结构，让用户将一组写有信息的卡片分组，并为其分配名称或标签。卡片分类有助于了解用户如何看待内容以及他们如何组织信息，从而决定在每个页面放置什么，对于页面或功能分类很有帮助。

• 面对面测试：由一个或多个观察者在诸如会议室的固定环境中运行，或者与小团体或个人进行。要求用户完成一组任务，观察者可以随时与他们交互以提出问题或进一步探究。

• 远程测试：在远程测试中，用户在自己的环境中执行一系列任务，通过软件记录完成任务的过程，软件自动记录用户的点击位置和交互过程，并记录他们在使用网站或应用程序时发生的关键事件以及用户提交的反馈。这种类型的测试可以由主持人（使用网络研讨会或电话会议技术）完成，也可以作为自我测试。

• A / B测试：为网站或应用程序的界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析评估出最好版本正式采用。

• 走廊测试：使用随机的人来测试网站，而不是那些在测试网站方面训练有素和经验丰富的人。这种方法对于在开发过程中首次测试新网站特别有效。

• 纸张原型测试：创建一个粗糙的，甚至是手绘的界面图形以用作设计的原型。让用户通过原型来执行任务，该方法能以极低的成本在编码完成之前对设计进行测试。

• 问卷调查：问卷的优势在于可以收集结构化的数据，且价格低廉，不需要检测设备，结果反映了用户的意见。

分析法与实验法的主要区别在于：是否有用户参与其中？

分析法的参与者是具备可用性知识的设计师与工程师；而实验法的参与者是目标用户或小白用户。从某种程度而言，分析法和实验法是一种互补的关系。

一般，在设计用户测试时，先在可用性检查阶段通过分析法去排查可用性问题，把排查出的问题按重要程度排序，然后在可用性测试阶段通过用户测试去重点观察和验证。

分析法的最大缺点是：它得到只是分析者的假设或观点，在团队意见不一致时，并不能够提出支持自己意见的有力证据。为了结束争论，就只能通过实验法。

接下来重点介绍分析法中的启发式评估法与实验法中的一对一用户测试。

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

启发式评估

1. 启发式评估简介

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

启发式评估使专家按照公认的可用性原则，来审查用户界面中的可用性问题，然后通过一系列原则对它们进行分类和评分。Jakob Nielsen的十种启发式评估原则（尼尔森十大交互定律）是行业中最常用的可用性评估原则。

除此之外，还有Gerhardt-Powals的认知工程原理、Weinschenk和 Barker的分类、ISO 9421 对话原则等。

2. 启发式评估原则

Jakob Nielsen倡导的启发式评估十原则内容如下：

1. 系统状态的可见性：系统应该在合理的时间内做出适当的反馈，始终让用户了解正在发生的事情。

2. 系统与现实世界的匹配：系统应使用用户的语言，用户熟悉的词语和概念，而不是系统导向的专业术语。遵循现实世界的惯例，使信息以自然和合乎逻辑的顺序出现。

3. 用户控制和自由：用户有时会误操作，要提供任何时候都能从当前状态跳出来的出口，保证能够及时取消或者再运行执行过的操作（支持撤消和重做）。

4. 一致性和标准化：不应让用户怀疑不同的词语、情况或行为是否意味着同一件事。保证用户在同样的操作下得到相同的结果。

5. 预防错误：提前预防错误的发生，这种防患于未然的设计要比适当的错误提示更胜一筹。消除容易出错的条件或检查它们，并在用户采取行动之前让用户再次确认是否进行该操作。

6. 识别而不是回忆： 通过使对象，动作和选项等可视化，从而最大限度地减少用户的认知负担，使用户无需回忆，一看就懂。尽量不要让用户从当前对话切换到别的对话时还必须记住某些信息，系统的使用说明应该是可见的，或者适当时可以轻易地检索。

7. 灵活性和效率：加速器功能（初次接触的用户看不到该功能）通常可以提升专家用户的操作效率，从而使系统能够迎合无经验和有经验的用户，允许用户能够单独调整会频繁使用的操作。

8. 审美和极简主义设计：对话不应包含无关或极少需要的信息，对话中的每条附加信息都会与关键信息形成竞争，并降低其相对可见度。

9. 帮助用户识别，诊断和从错误中恢复：错误消息应以简单的语言表示，精确地表明问题，并建设性地提出解决方案。

10. 帮助和文档：即使系统在没有帮助文档的情况下也可以使用良好，但还是有必要提供帮助和文档。这样的信息应该易于搜索，针对用户要执行任务列出具体步骤。

3. 启发式评估法的实施步骤

STEP 1：招募评价人员

Jakob Nielsen认为：一个人评价大约只能发现35%的问题，因此大概需要3~5人才能得到稳妥的结果，能够胜任启发式评估职位的人可以是用户体验设计师、交互设计师、UI设计师等。界面的原设计师是不适合评价界面的，因为评价结果可能会不够客观抑或是发现问题直接就进行修改而不会反馈。

STEP 2：制定评价计划

评价产品的所有功能是比较困难的，所以要事先定好要评价界面的哪些部分，以及依据哪些原则进行评价（Gerhardt-Powals的认知工程原理、Weinschenk和 Barker的分类、ISO 9421 对话原则等）。

STEP 3：实施评价

最好对界面进行两次评价：第一次检查界面的流程是否正常，第二次详细检查各界面是否存在问题。评价人员之间应禁止相互讨论，以避免评价结果被权威人士所影响。

STEP 4：召开评价人员会议

评价人员完成了各自的评价后，要集中开会以汇报评价结果，会议上描述问题的同时将界面显示出来会更有效率。

启发式评估的优点是：通过单独评价和评价人员之间的讨论这二次过滤，可以发现单独一人不能发现的跨度较大的问题。

STEP 5：总结评价结果

汇总所有的评价结果后，就可以整合评价的问题列表了，可能会有一个问题存在多种表达方式，所以需要对问题列表进行适当的整理。

STEP6：输出总结性报告

启发式评估法的输出成果就是产品可用性问题列表，但如果只给出列表，其他成员理解可能会比较困难，因此最好配上界面截图、流程图等输出一份简介的启发式评估报告。

启发式评估报告（HE报告）的内容主要包括：

1. 出现问题的界面和位置，关键事件或问题出现在用户界面的哪个位置？

2. 启发式的名称，引用了十个启发式原则中的哪一个？

3. 被评价为否定或肯定的原因，解释为什么界面会违反或符合该启发式？

4. 问题的范围，描述问题的范围，是贯穿整个产品还是在某个界面？

5. 问题的严重程度(高/中/低），评估问题的严重程度。

6. 评定其严重程度的理由，给它高/中/低的原因。

7. 修复建议，对问题的改进建议。

8. 可能的权衡（为什么修复可能会不起作用），提及这些权衡可以增加报告的可信度。
   

启发式评估问题列表的示例

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

平心而论，启发式方法是打算作为一种帮助新手从业者进行可用性检验的“脚手架”，因此它无论如何都无法与专家可用性检验方法相提并论。而且，只有专家才能通过可检验方法发现问题，而不是使用启发式方法的都是专家。

启发式评估法是由多位专家基于自身经验和启发式原则，对用户界面进行的评判，因此势必会发现很多问题。而且实施启发式评估法需要多名专家在限定的几天内进行作业，所需成本也较高。

所以应结合实际情况对启发式评估做简化，可以只由一两名专家进行简单审查，这种做法被成为启发法。不过在不提供客观的判断标准，且检验人员数量又少的情况下，评估结果可能会被指责“这些问题只是检验人员的主观想法而已”。

因为资源有限而导致不能进行正规的启发式评估，而改为简易的审查时，要注意：

1. 不应以个人偏好，而应以理论依据进行评价。

2. 评价的目的不是挑错，更应给出合理建议。

3. 当团队意见不一致时，与其争论不如通过实验得出结论。
   

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

   用户测试

   1. 用户测试简介

   用户测试，可用性工程师与用户进行一对一访谈（理想情况下，观察者与使用者彼此不认识，以便收集更多客观数据），其他成员在监听室观察整个访谈，而且用户操作计算机时的界面和声音，全程都被录像。

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

   2. 用户测试的常见方法

   （1）发声思考法

   发声思考法就是让用户一边说出心里想的内容一边操作，操作过程中用户能够说出“我觉得下面应该这样操作…”。这样我们就能够把握用户关注的是哪个部分、他是怎么想的、又采取了怎样的操作等信息，这是一种能够弄清楚为什么会导致不好结果的非常有效的评估方法。

   发声思考法观察的重点：

   • 用户是否独立完成了任务？若不能独立完成任务，页面存在有效性问题。

   • 用户达到目的的过程中，是否做了无效操作或不知所措？如果有，页面存在效率问题。

   • 用户是否有不满的情绪？如果有则页面存在满意度问题。

    

   （2）回顾法

   让用户操作完后回答问题的方法。

   回顾法的限制：

   • 很难回顾复杂的情况。

   • 用户会在事后为自己的行为找借口。

   • 回顾发比较耗时。

    

   （3）性能测试

   性能测试一般会安排在项目前后实施，目的是设置目标数值、把握目标的完成程度和改善程度。

   测试主要针对产品可用性三要素（有效性、效率、满意度）的相关数据进行定量测试：

   1. 有效性可以用任务完成率来表示：有几成的用户可以独立完成任务是检验里最重要的一个性能指标，这里的任务完成指用户正确的完成了任务。

   2. 效率可以用任务完成时间来表示：界面时为了让用户完成任务而设计的，因此能够在最短时间内让用户完成任务的界面才是优秀的界面，所以需要检测用户完成任务所花的时间。最好限制每个任务的时间，在限定时间内未能完成任务，就被当做任务未完成。

   3. 满意度可以用主观评价来表示：任务完成后，可以就“难易程度”、“好感”、“是否有再次使用的意向”等问题向用户提问，并设置5~10个等级让用户选择。

    

   测试方法：发声法和回顾法这样的用户测试都是一对一的形式，但性能测试是定量测试，参与测试的人太少可信度太低，也不能用来说明问题。因此经常以集体测试的形式进行，每1~2名用户配备一位监督者，制定测试内容、确认完成任务、检测任务完成时间等。

   数据统计处理较多的心理学实验里，一般至少会收集20~30人的数据。而且所谓20人是目标用户的人数，因此整体而言需要40~60人。

   原则上讲，一次性能测试会测试多个用户界面。如果只测试一个用户界面，那么即时最终得到了任务完成率和平均时间，这些数值的好坏也没有一个标准。通过对比竞争产品，比较多套方案，或者对比改版前后的数据，就能进行客观评价了。（在让每个用户使用多个界面时，使用顺序应该不相同，这可以避免使用顺序带来的影响。）

   性能测试的限制：当任务完成率只有20%时，团队只知道这个任务的执行效率很低，但不知道用户究竟是为什么没能完成任务，因此会感觉无所适从。

   发声思考法可以解决这个问题，但实际操作过程中，只要采访人员不提问，用户就不会主动说话。如果提问的话，用户又可能就会停下手上的动作进行说明，这样一来测试完成任务的时间就没意义了。

   缺少发生思考的性能测试没有任何意义，但如果同时实施这两种方法，又需要很大预算。所以只要还未明确定量数据的必要性，就不应实施性能测试。我们没必要把有限的资源浪费在定量数据的测试上。相反，反复进行的发生思考法这种只需几个人参加的测试，可以更好的改善界面。

   3. 用户测试的实施步骤

   STEP 1：设计任务

   可用性评估是基于任务的，任务设计的优劣能直接影响测试结果的准确性。所以在招募用户前，应先针对产品设计任务。比如：一个购物类APP设定的任务可以是：购买一件价格高于100元的T恤。

   想要设计出合适的任务须注意以下几点：

   （1）选择最核心的功能或操作流程作为任务

   一个产品可以执行很多任务，不可能把所有任务都执行一次。所以应采用精益思维，把有限的资源放在最有价值的环节上，产品最核心的功能或操作流程往往是最频繁被用户使用的地方。

   如果这里还存在可用性问题，那么就算改善了其他边缘地带的可用性问题，依然对产品整体体验于事无补，所以设计的任务要以核心功能和操作流程为主。

   （2）任务应符合常规操作流程

   有时设计者会把自己想要用户做的事当任务来测试，但实际用户并不是按设计者想的流程去完成任务的。而且由于测试的任务较多，设计者为省事有时会把多个小任务合并为一个大任务，这样做有时是可以的，但如果小任务之间的操作流程存在冲突，用户测试的操作流程就是不合乎常规的。

   也就是说，用户实际在执行的任务在正常使用产品的时候，根本不会出现或极少出现，这样的测试的结果准确性令人堪忧，且还会给参与测试的用户造成困惑。

   （3）为任务创建一个应用场景

   简短的场景描述会会对用户执行任务有所帮助。比如：任务是“购买一件价格高于100元的T恤”，我们可以创建这样一个场景——你的同事过生日了，你想挑一件一百多块的T恤给他，请使用XX APP来完成T恤的购买。

   这样给了用户一个执行任务的理由和目的，不会使任务变得突兀，而且用户也会变得有代入感从而更好的理解并执行任务。注意场景描述里不要涉及用户的直系亲属，没人知道他们的经历，以免引起用户的情绪反应。

   （4）明确任务的起点和终点

   判断用户是否完成了任务的主要依据就是：用户是否从起点（页面A）到达了终点（页面B）。

   所以要清晰的定义，哪个页面是起点？哪个页面是终点？起点未必一定要是首页，起点位置应根据具体场景来确定，毕竟并不是每个任务都是从首页开始的。比如：任务是“购买一件价格高于100元的T恤”，那么起点页面可以是APP的首页，终点页面就是付款成功页面。

   不过除了检查是否到达终点，可能还要检查一些关键信息，比如：用户购买的T恤价格是否高于100元、用户是否正确填写了地址等。如果没有，那么我们要搞清楚原因是什么？

   （5）任务不应过于简单

   如果想测试用户是否可以找到某功能，不要用类似“找到XX功能按钮”这样的描述，我们应该给用户提供一个要处理的现实任务，而不只是定位功能的位置。“找到退款功能按钮”应改为“购买一件T恤并退款。”

   （6）避免提供线索和描述操作步骤

   任务应给出具体目标，而不是操作步骤。

   以买T恤的任务为例：如果告诉用户“搜索T恤，然后选择数量和颜色，填写地址并确认订单，最后进行支付”，那么用户在执行任务时的思路可能是这样的：找T恤、找数量选择按钮、找颜色选择按钮、找填写地址的位置、找订单确认按钮、找支付按钮，一个完整的核心任务就这样被拆分成了多个确认功能按钮位置的操作，引导性过强的任务失去了测试的意义。

   这样做会错过用户在任务中，执行到某一步骤时可能提供的宝贵反馈。因为用户一开始可能并不知道会有这些操作步骤，可能会因一些额外的操作感到惊讶或烦恼。而且用户在实际使用产品时，考虑的是使用目标，而不是具体的操作和功能。

   因此，一定要避免提供线索和操作步骤给用户。

   STEP 2：招募用户

   （1）要根据资金预算和日程安排来招募用户，并给予他们一些报酬（小礼物即可）

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

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

   被招募的用户应具备使用产品执行任务的能力，比如：我们一定不会找电脑都不太会使用的人来体验桌面软件。

   通常我会找两类用户来体验产品：

   • 一类是有同类型产品使用经验的用户；

   • 另一类是完全没使用过类似产品的用户。

   因为我的产品目标是降低同类产品的操作复杂度，让小白用户也能轻易上手，通过这两种用户可能会发现截然不同的问题。

   （2）接下来要确认所要招募的用户数量

   Jakob Nielsen提出过一个法则：有5人参加的用户测试，即可发现大多数（85%）的产品可用性问题，而且通常最严重的问题都是前几名用户发现的，随着用户数量的增多，发现的问题逐渐减少，被发现的问题数量与测试用户的数量的关系如下图所示。

    

   但它也存在一些局限性，比如：它只能说明发现的问题的数量，但不能确认所发现问题的严重程度（还有很多局限性在此不一一列举）。所以我们要根据我们的实际情况，来确定要招募的用户的数量，查看每次测试的结果与迭代效果，看看是否值得投入更多资源来做可用性测试。

Resource: Nielsen Norman Group

（3）关于招募渠道

如果时间精力充裕，可以从网络问卷和在市场调研阶段的渠道，邀请外部用户进行测试。反之，则可以充分利用身边的资源——同事和朋友，但不要找项目组内部的成员，因为他们对产品过于了解，会影响测试结果的有效性。

STEP 3 ：准备工作

（1）测试地点与工具的准备

专业的用户测试一般在实验室内进行，实验室有观察室与操作室，测试人员与用户在操作室进行可用性测试，其他团队成员在观察室中观察，两个房间之间通常由单面镜隔开。

操作室内无法看到观察室的情况，而观察室能看到操作室的情况。通常观察室中还需要配备电脑或投影仪，实时显示操作室中正在被用户操作的用户界面。但绝大多数公司往往不具备这样的条件的实验，这时我们找一间安静的会议室就可以了。

测试人员与用户在会议室进行测试，如果是PC端软件的测试，可在PC预安装录播或直播软件，便于其他成员观看用户操作的流程与表情。如果是手机端软件的测试，可以直接使用同屏功能，团队其他成员直接在另外的PC上观看用户的操作即可。

推荐使用能同时录制屏幕和用户表情具备画中画功能的软件，因为观察用户屏幕帮助我们了解用户做了什么，观察用户表情可以了解用户的情绪（困惑、恼怒等）。

总之，方法和工具有很多，只要不影响用户测试并便于团队成员观察即可。

（2）任务相关资料的准备

要准备任务提示卡，一张用于记录用户要完成的任务的卡片，有些任务可能比较复杂，这样可以更准确的传达任务信息，且便于用户主动查看。

还要为自己准备一份数据收集表格，用于收集任务相关数据，如任务是否完成、完成时间等，还要有用于记录关键事件和在测试过程中观察到的用户体验问题的表格，比如：设计可能存在的问题及原因等。

（3）相关文件的准备

更专业的用户可用性测试，会与用户签署一些协议。

比如：

1. 用户知情同意书，用于声明用户是自愿参加评估的并允许我们获取和使用数据。

2. 可用性测试说明文件，简单概述测试目的与对用户的期望以及用户要遵守的规则等。

3. 保密协议，防止用户泄露产品信息。

4. 问卷与调查，充分了解用户的背景。

有的测试可能还会用到培训资料，比如：某些复杂的智能硬件，可能需要用户先阅读说明书后再执行任务，诸如此类在此不过多阐述。

（4）可用性测试剧本的准备

可用性测试剧本指我们从接触用户、开场白、开始测试、事后访谈、给予奖励并送走用户的整个过程中要执行的行为与台词的集合，测试人员通过执行剧本中的内容来推动可用性测试的进行。（别忘了准备报酬）

4. 可用性剧本示例

• 评测对象：XX购物APP。

• 招募条件：一二线城市90后，有在线购物的经历。

• 参与者人数：5名。

• 测试时间：60分钟。

• 酬劳：咖啡一盒。

（1）开场白（3分钟），说明访谈目的和基本流程，签订录像许可与保密协议等文件

常用话术：您好，我是XX购物APP的可用性工程师，很高兴见到您。今天由我来和您做这次测试，这次测试的目的是测试我们的产品是否便于用户使用，接下来会拜托您通过APP执行几个任务，执行任务的过程我们需要通过摄像头记录下来，以便于我们的重复观察与分析。还要麻烦您对本次测试的内容进行保密，如果没有什么疑问，请您在这些协议上签字，谢谢。

（2）事前访谈（5~10分钟），了解用户背景，也可通过问卷来获取信息

常用话术：方便透露下您的年龄/职业嘛，说个范围就可以，比如：20~30/某个行业。您是否有用过类似的在线购物产品？有的话，感觉怎么样？感觉优点/缺点有哪些？如果没有，您购物是通过什么方式呢？通过什么方式支付呢？

（3）测试说明（5分钟），说明测试内容与用户应遵循的相关规则。

常用话术：接下来请您使用我们的APP购买一件商品，任务的细节和背景都写在这张卡片上了。需要强调的是：我们的APP只是一个初步版本，我们已经知道它存在一些体验上的问题，想通过您的使用验证这些问题，所以如果遇到了什么问题，都是产品设计的问题，操作失败了也请不要放在心上。

在操作过程中，希望您能一边操作一边告诉我您要进行什么操作？您为什么要这么操作？您是怎么想的？这对我将非常有帮助。

最后，您在操作过程中最好不要向我提问，因为如果我告诉了您如何操作，我可能就无法找到产品中的问题了。所以如果您问我问题，我没有答复您，还请见谅。

（4）观察测试（30~40分钟），观察并记录用户在执行任务中遇到的问题

假设目标任务为——购买一件100元以上的T恤，起点为首页，终点为付款成功页。

常用话术：假设您的同事过生日了，您想送他一件100元以上的T恤，请使用这款APP进行购买。

（5）事后访谈（5~10分钟），通过回顾法询问用户在执行任务中遇到的问题

常用话术：您刚才用这款APP进行了一次购物体验，能谈谈您的感想吗？

比如：觉得哪里比较好？哪里比较差？对比您之前使用过的同类APP感觉如何？如果要综合评价这次购物体验，您会给它打几分呢？给之用过的同类产品打几分呢？为了使产品体验更好，您觉得我们有哪些需要改进的地方呢？

虽然主流观点认为不该问用户产品哪里需要改进，因为改进产品是设计者的事情，用户给出的也只是基于自身经验的主观解决方案。但是如果针对用户的答案，继续深挖“为什么”，可能就会知道用户真正想要的结果是什么。

（6）结束语（3分钟），对用于表示感谢，并初始化实验室准备测试下一位用户

常用话术：今天的测试到此为止啦，感谢您的配合，这次测试的数据对我们非常有用，我们为您准备一盒咖啡以表谢意，请笑纳哈。（接着送走用户就好）

STEP 4：试点测试

试点测试可以理解成可用性测试之前的彩排，无论进行了多么周密的计划，不实践一下是不会发现计划中的问题的，试点测试的目的就是对测试计划进行测试，以便于发现测试计划中的疏漏，及时修复，以免浪费测试资源。

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

然后即可开始可用性测试的流程，要重点关注：

• 台词和任务卡片的设计，是否可以准确传达信息？

• 台词和任务卡片是否透露了操作步骤，用户是否很快的完成任务？

• 任务时间安排是否合理，用户是否可以在规定时间内完成任务？

• 任务流程安排是否合理，用户是否感到莫名其妙？

最后，根据试点测试中发现的问题，对测试计划进行修复，完善测试计划。

STEP 6：观察&访谈

（1）邀请关键干系人观察测试

建议邀请产品的核心研发、设计师、项目经理等来观察测试，因为这样可以是测试结果更有说服力。如果没有这些人来观察测试，测试结果得可信度对他们来说就大打折扣。因此，越多关键干系人观察到了测试，越有利于后续产品优化方案的执行。

（2）不要干扰用户执行任务

进入正式测试环节后，测试人员就不能像在事前访谈一样不断的像用户提问了，用户测试的主角是用户，测试人员应安静的观察用户的操作并记录，不要干扰用户执行任务。

当用户对当前操作存在疑问时，比如：“我现在可以按这个按钮吗？”

测试人员不可以直接回答用户应该如何操作，以及每个按钮代表什么。也不可以无视用户的问题，因为这样可能会引起用户的不满情绪。

此时，最合适的方式应该是回复“您觉得应该是怎样呢？是什么让您觉得应该是这样？您怎么想就怎么做，没关系的。”把问题推回给用户，并让其有一定安全感，做错了也没关系。我们只负责告诉用户“做什么”，至于“怎么做”这是要用户通过操作反馈给我们的信息。

（3）适当干预用户的操作

用户测试中最常用的方法就是发声思考法，它要求用户在进行操作的同时将所思所想大声说出来，以便测试人员了解用户的心理活动，以及用户在每个操作流程中关注了哪些元素，如何看待这些元素？知道了这些才能更好的根据用户心智模型来改进产品。

但在实际测试中，用户很少会把自己所思所想直接说出来，有的是因为害羞；有的是因为感到不自在，难以做到。

这时就需要测试人员进行适当的干预，比如：您正在看什么呀？您现在想进行什么操作呀？这是否和您的预期一致呀？通过这类问题试探用户的想法，并鼓励其发生思考。

原则上，只要用户操作的很顺利就不需要人为干预，我们只在用户碰到问题时进行干预，进而了解用户遇到了什么问题。用户的困惑除了发生思考，还可以从其肢体语言表达出来。比如：用户皱眉、发出语气词、喘粗气、清嗓子、挠头、突然停下动作等，这都暗示了用户在当前界面遇到了麻烦，所以测试人员应重点留意用户的肢体语言。

但切忌帮助用户进行预判断和给予用户提示，比如：“这个按钮可能设计的不太合理…”。测试人员只负责观察和记录用户的行为，不能引导用户操作和帮助用户判断。

（4）重点观察和记录用户在什么界面说了什么做什么了

记录这些客观事实即可，不要带着自己的观点去观察，比如：为了证明某个设计是对的/错的，带着寻找证据的心态去观察可能会忽略一些信息，因为人们只看到自己想要看到的。

记住：我们要记录的是客观事实，而不是自己基于客观事实的推断和分析。可能我们看到用户的操作心理马上就有了一个推断，这没问题，但要区分出客观事实和推断。因为分析，是这个阶段收集完数据之后在下一个阶段应该做的事。记录问题的同时，也要关注用户操作流畅的地方，避免最后修改了不必修改的地方。（记录的数据，是绘制用户体验地图的关键）

（5）使用回顾法进行提问

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

比如：“您刚才在XX界面停留了很久，能告诉我当时您在思考什么吗？”这样就能通过回顾法补全测试中遗漏的信息。

STEP 7：分析

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

通过用户测试，我要们判断交互设计是否满足了用户体验目标水平。分析数据的第一步是整理出测试结果，通常要绘制一份表格，表格内容通常包含：任务、用户体验目标、任务基准值、任务目标值、是否完成目标等信息。

如下图所示：

可用性测试数据整理表的示例

接着我们直接通过比较观测结果和用户体验目标，就可以知道哪些用户体验目标已经达到、哪些没有达到。如果体验目标没有达到且资源充足，那么产品就需要进行迭代。这时就要具体分析每个用户体验问题，并输出解决方案。

（2）分析问题的影响程度

并非所有的问题都是平等的，一些问题会带来负担，用户必须先处理才能继续原来的问题。其他错误可能会带来用户的情绪问题，让用户重复操作，但不会引发新的问题。

了解问题的严重性，能帮助我们更好的对用户体验问题优先级进行排序，我们通过问题性质和问题发生频率来确定问题的影响程度。

问题性质，一般要通过效果问题＞效率问题＞满意度（或者速度＞错误＞满意度）的顺序来评价问题的性质。

效果相关问题导致用户无法完成或几乎无法完成任务，效率问题导致用户做无用功，或过多思考、执行更多错误操作。满意度问题导致用户表达不满意情绪，问题发生频率，通过发现问题的人数来决定。

不管测试了多少人，我们用三个范围来表示频率：1个人、几个人、所有人（几乎所有人）。比如：10个人可能就被分为：1个人、2~7人、8~10人三个范围。

然后我们基于问题性质和发生频率建立一个表格，如下图所示：

问题影响度分析表的示例

列代表问题发生频率，行代表问题性质。把标记黄色的问题定义为必须要解决的问题，把标记绿色的问题标记为最好去解决的问题，把标记为蓝色的问题标记为资源充沛的话，可以去解决的问题。资源总是有限的，不可能每个问题都去修复，我们必须通过分析问题的影响程度确定要修复的问题。

（3）制作用户体验问题描述

以表格来维护用户体验问题的数据比较简略，不利于其他人了解详细情况和参考，所以我们需要对每个问题进行一些信息补充，让用户体验问题的实例在数据分析中变得更有价值。

我们需要做的就是——了解每个问题及其产生的原因和可能的解决方案，将表示同一个用户体验问题的多个用户体验问题进行合并（肯定会有重复出现的问题），并认清各个问题之间潜在的关系。

一份用户体验问题描述通常包含如下信息：

• 问题概述：从用户角度描述产品存在的问题，比如：“没有返回按钮”应描述为“用户无法返回上一级页面”。

• 用户任务：提供问题发生的背景，帮助我们了解用户想进行什么操作时发生了什么样的问题。

• 用户目标：一个任务可能会分为多个目标，用户目标描述用户具体为了达到什么目标时碰到的问题。

• 问题详述：对用户体验问题详细的描述，比如：用户在什么页面，进行了什么操作，界面发生了怎样的交互等。

• 问题分析：从设计师角度对问题进行分析，比如：为什么产品没有按用户期待的方式运行？是什么导致了用户无法完成任务或产生消极情绪？这样的解释会往往会为可行的问题解决方案提供线索。

• 解决方案：针对问题产生的原因提出可能的解决方案。

STEP 7：重新设计

通常来讲，我们会针对每个问题，给出一个解决方案。但事实往往并非如此，问题和解决方案之间有时并不是一一对应关系。如果针对每个问题都给出解决方案，可能导致产品的复杂度提升。

有时，一个解决方案就能解决多个问题，这就需要我们对每个问题的联系及其产生原因有深刻的洞察，若是能从根本解决问题，产品的品质会得到极大提升。

这需要我们跳出原有的一对一的思维，先从宏观层面整体分析这些问题组，而不是孤立的一个个问题。在设计出解决方案后，还要对解决方案的成本和优先级等信息进行梳理，以便于更好的管理问题&解决方案信息表格，可以把这些用户体验问题与其解决方案当做产品需求来管理。

如下图所示：