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）相关文件的准备
更专业的用户可用性测试，会与用户签署一些协议。
比如：
用户知情同意书，用于声明用户是自愿参加评估的并允许我们获取和使用数据。
可用性测试说明文件，简单概述测试目的与对用户的期望以及用户要遵守的规则等。
保密协议，防止用户泄露产品信息。
问卷与调查，充分了解用户的背景。
有的测试可能还会用到培训资料，比如：某些复杂的智能硬件，可能需要用户先阅读说明书后再执行任务，诸如此类在此不过多阐述。
（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：重新设计
通常来讲，我们会针对每个问题，给出一个解决方案。但事实往往并非如此，问题和解决方案之间有时并不是一一对应关系。如果针对每个问题都给出解决方案，可能导致产品的复杂度提升。
有时，一个解决方案就能解决多个问题，这就需要我们对每个问题的联系及其产生原因有深刻的洞察，若是能从根本解决问题，产品的品质会得到极大提升。
这需要我们跳出原有的一对一的思维，先从宏观层面整体分析这些问题组，而不是孤立的一个个问题。在设计出解决方案后，还要对解决方案的成本和优先级等信息进行梳理，以便于更好的管理问题&解决方案信息表格，可以把这些用户体验问题与其解决方案当做产品需求来管理。
如下图所示：
问题&解决方案信息表的示例
要注意的是：不要以为按照设计方案修复好，用户体验问题就已经解决了。解决方案也只是我们的假设而已，假设这个修复方案可以解决问题，所以为了验证假设，我们要不断的通过可用性测试来验证新的方案。
这是一个贯穿产品开发过程持续循环的过程：不断的发现问题-分析问题原因-修复问题-测试问题是否已得到解决。对设计进行修改可能会使用户体验变得更糟糕，所以设计时要考虑用户体验问题修复是否会造成新问题。
STEP 8：输出可用性测试报告
可用性报告的价值在于：记录评估过程，帮助组织内部了解测试过程和内容。为产品开发过程提供有价值的信息，开发团队知道了问题所在才能更好的执行开发。
传达信息，并说服干系人，可用性测试报告可以有理有据的告诉干系人，我们的结论并非凭空产生，便于资源的申请。除此之外，还可以传递评估结果，树立用户体验意识等。
可用性报告的内容一般包括：
对产品的描述。
测试目标。
对参与者数量和画像的描述。
测试时所执行的任务。
测试的实验设计。
采用的评估方法。
采用的可用性度量指标和数据收集方法。
数据结果，包括图形可视化的展现。
对问题的描述。
对产生问题原因的分析。
对问题的严重程度和影响范围的评估。
建议的解决方案。
可用性测试常见问题
（1）可用性测试在设计过程中进行的太晚
如果你等到产品发布之前才想到可用性测试，你就没有时间或金钱去修复任何问题 ，更糟糕的是你可能会以错误的方式，浪费大量精力开发可用性很差的产品。
其实，在整个产品研发周期内反复进行小规模的测试是最合适的，在产品完成初步原型时，就可以先进行可用性测试，快速发现问题，及时修改，避免上线后修改带来的成本浪费。
（2）觉得可用性测试很专业，且要花费大量人力财力，所以干脆不做
因为收益无法量化，项目排期又比较紧张，所以总被忽略掉。其实可用性测试门槛很低，不必等产品做好才开始，不一定非要由专家来做，更不一定要求专业的设备。只要能有一个环境观察用户操作产品，或多或少都会发现一些可用性的问题。
其他小问题就不多阐述了，希望本文对读者有所帮助。由于作者接触可用性测试也没有多久，文中难免有不足之处，有问题的地方和描述不清楚的地方，还望请读者多多指正，感谢。
