可用性测试全流程：用体验来优化体验
上一期聊过了用户访谈，这次我们来聊一聊可用性测试。
在数据驱动的时代，数据仿佛是验证设计的硬通货，但是，当我们的产品刚刚上线，或者开发埋点不完善时，我们的设计该以何为指标进行优化？又或者，当我们获得数据支持、明确了问题页面后，又该如何去确定问题发生的原因？面对这些日常设计困扰，这一期，我们就来讲一个用户研究的常用方法：可用性测试。
可用性测试，这一名称，如果有读过我上一期《用户访谈全流程：深入挖掘用户需求》的同学一定很熟悉，但是上一期碍于篇幅的原因，没有做深入的探讨，这一期我们就这个方法展开来聊一聊。
首先我们需要先明确的第一个概念是：可用性。
那什么是可用性呢？从字面意思来看，就是指当我们执行一个操作，操作结束时，达到了我们所预期的结果，就达到了可用的标准。例如，一个水龙头，我们打开它就出水，关闭就会停水。这个水龙头就是一个可用的产品了。
难道可用性测试就仅仅是指的可用与不可用么？
答案，当然是错误的。首先为了明确这一概念，先请出来一个大家熟悉而陌生的的老朋友。国际标准ISO。为什么说熟悉，那是因为如果你经常逛超市，会发现买的牛奶背后都会有一个iso：xxxxx，这个标志告诉了我们，这盒牛奶的是符合国际安全标准的牛奶，可以放心食用。
那为什么说也很陌生，是因为ISO国际标准组织制定标准的范围不光是食品、生活用品。也包括我们的一些交互概念，比如什么是用户体验、什么是可用，在标准中都有明确的规定。
当我们翻阅ISO 9241-11:2018时可以清晰的知道，可用性的概念是指：“特定的用户在特定的使用场景下，为了达到特定的目的而使用某些产品时，所感受到的有效性、效率及满意度。”
可以看到，可用性这一词，指的更多的是使用过程中的感受。而结果的有效，只是其中的一个部分。
那么下面我们就来解释一下可用性这三个概念：有效性、效率、满意度。
有效性：有效性是指，用户是否能通过使用产品，达成自己的目标。以b站直播为例，用户进入直播页面目的是为了观看一场直播，并跟主播产生互动。那么此时b站直播这个产品的有效性就是指用户能够进入直播间完成观看直播、投喂礼物等操作。如果无法完成，那么就是有效性出了问题。因此，有效性的问题通常都是无论如何必须解决的关键性问题。
使用效率：顾名思义，就是用户是否能以最短路径达成目的。仍然以b站直播为例，如果投喂礼物的操作很麻烦，用户需要反复多次操作才能成功投喂，那么产品就存在效率问题了。严重的效率问题，往往会造成有效性问题。这样的产品，用户用了一次之后，就再也不会使用第二次了。
满意度：满意度的问题是在产品满足了有效性和使用效率的前提下，用户对产品使用的舒适度和认可接受程度，即有没有给用户带来不愉快的体验。比如，注册会员时要求用户提供过多的个人信息，进入产品时要求过多的使用权限等，这些问题虽然没有影响产品的整体使用，但是如果反复出现就会给用户带来不愉快的用户体验，从而导致对产品的满意度下降。
根据ISO 9241的定义，同时满足了以上三个要素，才能称得上是实现了产品的可用性。然而，在实际操作中往往因为开发周期紧张而无法全部满足，这时的解决方法是，首先解决有效性问题，然后在时间和成本都允许的情况下，尽量解决效率和满意度的问题。
2.1 什么是可用性测试
可用性测试是通过观察有代表性的用户，完成产品的典型任务，从而找出可用性问题的过程。该产品可能是一个网站，软件，或者其他任何产品。早期的可用性测试我们一般拿画在纸上的原型进行测试，然而随着互联网上工具的不断发展，可用性测试已经几乎不使用早期的纸上原型进行了。即使是低保真的交互原型图也可以通过类似于墨刀或者Figma等工具，可以让用户直接上手进行简单交互操作。或是直接使用成熟的线上产品进行测试。
2.2 可用性测试与用户访谈的区别
上一篇文章中我为大家介绍了用户访谈，同为定性的用户研究，这两者之间有什么区别呢？
可用性测试与用户访谈一样都是更偏向于定性的研究，但与用户访谈不同的是，可用性测试更偏向于观察用户的行为。用户访谈的目的是为了深入挖掘用户需求，而可用性测试则是为了找出产品问题而进行的测试。因此，可用性测试也经常被批评为“鸡蛋里挑骨头的测试”。事实上，可用性测试正是以反证为目的的测试，并不是为了证明产品哪里好，而是为了找出产品哪里不好。我们通过可用性测试发现产品中存在的问题，并解决，最终的目的就是为了让我们的产品用起来更加容易。
2.3 可用性测试的类型
可用性测试的类型主要有两种，一种是形成性的可用性测试（Summative Evaluation），一种是总结性的可用性测试(Formative Evaluation)
总结性测试通常会安排至少30名以上用户使用界面，验证他们的平均目标达成率、平均达成时间以及主观满意度等，通常以打分的形式呈现。总结性测试的优点是可以作为定量研究的参考，方便做版本间的对比。
然而每次都安排30～100名用户做测试，先抛开测试成本不谈，单从时间纬度上考量就不适合互联网快速迭代的节奏。因此在互联网公司经常使用的，其实是以发现问题为主的，小样本量的形成性的可用性测试。形成性的可用性测试最大的特点即为快速、简易，能紧密贴合产品迭代周期。
从使用的时间上来说，总结性测试一般在设计后使用，形成性的可用性测试则会在产品设计的过程中反复使用。也可以理解为，总结性测试是在做了很多的产品优化之后，为了更好的掌握成果而采取的测试方法。
2.4 可用性测试对产品有哪些帮助？
2.4.1. 理解用户行为
虽然我们总把“面向用户设计”挂在嘴边，但作为设计师或产品经理，我们大多数时候并不直接面对我们的用户。可用性测试作为典型的实验型方法，与问卷调查、专家评审等分析方法不同，它是更加基于真实用户行为所进行的评价，因此更会给设计师或产品团队带来一种“百闻不如一见”的体验，可以帮助团队更直观的了解用户：了解用户的行为习惯、了解用户是如何使用产品的、了解用户是如何认知产品的。无论如何，能够直接的接触用户对团队来说都是非常宝贵的体验。
2.4.2. 发现产品问题
你是不是也有在使用某些产品的时候会想，这么明显的问题，他们怎么可能没发现呢？很多严重的问题甚至用一次就能发现。但是换到自己的产品上，我们却常常沉浸其中难以发现问题。这是因为作为开发者，我们对自己的产品了解的太多了，清楚产品的层次和框架，知道完成一个任务应该按照什么顺序，点击什么按钮。所以我们自然的认为所有的流程都是理所当然的。但其实这样的想法是非常危险的。开发者的想法并不一定等于用户的认知。这时可用性测试就显得十分重要了。
这就好比想要知道设计的玩具是否有趣，你就需要把玩具给到孩子们看他们的反应一样。我们的产品也需要让用户评估，从而得到一些反馈，如哪些地方使用不流畅，必须进行哪些修改，甚至是哪些地方没有满足用户需求。根据反馈评估，进行修改后，再进行新的测试得到新的反馈。这也是可用性测试的意义所在，让用户亲自使用发现产品中的问题，根据用户体验来优化产品体验。
2.5 常见的可用性测试目的
对整个产品进行可用性评估
对新增的功能模块进行评估
用户对于改版方案的看法
某个环节流出率/跳出率很高，想看一下是什么原因导致的
是否满足某群特定用户的需求
3.1 给用户找点事做-任务设定的原则
前面讲过可用性测试其实是我们请用户来，然后观察他们使用我们的产品。这里的使用不是指漫无目的的打开产品浏览，而是有针对性的对某一个或是某几个流程进行使用。所有开始可用性测试的第一步就是“给用户找点事情做”。
以b站直播为例子，这个任务可以是，观看直播、给主播投喂礼物、关注并加入主播粉丝团等。任务会在很大程度上影响测试结果。既然任务设定这么重要，那么下面我们就来讲一讲设定任务时的四大原则
3.1.1 把精力锁定在主要任务上
用户使用产品的目的各式各样。一个产品可能会有上百个小功能点。一场测试不可能测到所有的功能，我们只能挑选其中最主要的任务来测试。另外，产品有重大改版或者升级时，会改变原有用户使用习惯和操作步骤的内容或者有新功能加入等情况，也可以优先测试。如果还是无从下手，那么就从产品的角度出发，自然也能明确主要任务是什么了。
3.1.2 明确起点和目标
可用性测试最重要的地方就是“用户是否可以完成任务”，因此首先要明确目标是什么。如果没有明确定义目标，也就不能准确的判断用户是否完成了任务。因此任务开始之前，我们一般事先会定义一个目标页面，用户如果最终到达了该页面或者显示了该页面、该toast提示，就说明完成了任务。例如，测试用户观看直播的付费流程，那么就可以把“支付成功”或者“投喂成功”作为最终的目标页面。只要出现了礼物动画，那么就算完成目标任务。
另外，除了目标外，也需要明确任务的起点。许多人只要一提到可用性测试，就会开始测试从首页进入的一系列功能。但其实任务的起点并不一定非要是首页。例如测试b站直播中，购买和开通大航海的流程，就并不一定需要让用户从首页开始，更好的方式是以房间页作为任务的起点。所以，任务的设置应该根据不同的场景定义合适的起点和目标。
3.1.3 剧本化任务
实际使用产品时，用户一定会有自己的理由和目的。但是测试的时候不是这样的，即使已经确定了任务，但突然要求用户进行“请在该直播间投喂礼物”的任务，用户可能也会不知所措。如果没有足够丰满的场景，用户就不会主动行动，而是只会等待指示。
因此，我们需要把任务润色成用户一个实际的使用场景。例如，周末你在b站看直播，逛到这个直播间，觉得主播的直播内容很有趣，你的账户里有8000金瓜子，于是你决定给这个主播投喂礼物，预算大概是3000金瓜子左右。
如果像这样以创造一个实际场景的方式告诉用户任务，用户就可以通过自己以往的经验，带着生活实感，更主动的使用产品。只有用户更主动的使用，更主动的思考，可用性测试的流程才能进展的更加顺利。而不是机械化的，布置任务完成任务的循环。
任务测试中经常会有设置错了任务但是却没有察觉出来的情况。错误的设置任务虽然测试也能完整的进行，但是这样的测试一般无法得到令人满意的结果，或者说可能导致结果产品偏差，使其缺乏可信度，甚至可能出现错误的结论。
例如，我们希望测试b站直播用户是否能够顺利加入粉丝团，粉丝团可以通过投喂一个b坷垃，或是投喂价值9900金瓜子的礼物道具得到。如果你将任务描述成，给主播投喂一个b坷垃加入粉丝团，那么用户一定都知道应该首先打开礼物面板，找到b坷垃这个礼物，然后投递出去。如果你这样设置了任务，并得出90%以上的用户都能完成入团流程的结论，那么这个结论其实是不客观的。因为任务设置中包含着强引导性操作。情景结合设置任务的时候，需要注意的是，不要在情景设置中，给用户提供太多的指向性指令。可用性测试的目的是找到用户在使用过程中遇到的问题，而不是盲目的追求任务通过率。
那么我们如何正确设置这个任务呢？任务应该描述成：周末你在b站看直播，逛到这个直播间，觉得主播的直播内容很有趣，于是你决定关注并加入主播的粉丝团。这样设置任务后，用户的路径就可以能是先关注主播，然后寻找加入主播粉丝团的入口，唤起了粉丝团入团页面，仔细阅读并理解之后，投喂一个b坷垃，或是投喂其他礼物道具，甚至是加入大航海，进而完成入团操作。任务设置是否正确，会直接影响你的测试和结论输出。
下面就为大家介绍一些任务设置错误的例子：
1）请随意使用或者浏览b站直播
因为任务设置里没有包含目标，所以用户根本不可能完成任务。用户无法完成任务，那么就无法衡量测试是否成功。这就犯了我们上面说的“没有明确起点和目标”的错误
2）今天是周五，你的心情非常好，下午你的老板表扬了你，同事还请客吃了一顿非常丰盛的下午茶，里面有你最喜欢吃的披萨和炸鸡......
时刻记住你是要给用户布置任务。虽然任务的设置是需要一定的情景，但是心情和吃了什么跟你测试的产品功能有什么关系呢？除非是一款美食类相关的产品。否则不要提及太多无用的情景，时刻记住塑造的情景是需要为任务服务的。情景和心情不同，给用户塑造情景，应该包含具体的场景和行动点。“去XX地出差”，“在办公室写策划案”这些都是情景，但是心情不包含在内。
3）请浏览feed流，选出感兴趣的内容
在与用户交谈的过程中，不要使用用户理解不了的专业术语。无论是公司内部对一些功能的别称又或者是UI设计领域的专业术语，都不要出现在测试过程中。关于这一点，在我之前《用户访谈全流程：深入挖掘用户体验》的文章中也有详细讲过。不了解的小伙伴们可以去回顾一下之前的文章。
4）请打开礼物面板，并投喂一个b坷垃
这个跟上文中提到的“给主播投喂一个b坷垃入团”的任务犯了一样的问题。指示说明中包含了完成任务所需的关键步骤。导致可用性测试变成了单纯的执行任务。这样的任务设置会导致结果的可信度大大降低。任务只应该指示最终目标，而不应该包含完成目标的步骤和方法。如何达成目标，应该由用户独自完成。
5）请观看主播的直播，如果对直播内容感兴趣或是喜欢这个主播，请关注他。
刚刚说到心情与测试的产品功能毫无关系。如果指示内容包含“如果你有情绪的话,xxxx”，用户听到之后会产生理解的偏差。直接给出“请关注他”这样明确的指示就足够了。
3.1.4 给任务设置约束条件
在设定任务的时候，不要忘记设置约束条件。我经常设定的条件有2个。
第一点，不要使用搜索（测试搜索的时候除外）如果使用搜索完成了测试目的，那么就会变成了搜索是否可用的测试。而测试不到实际的功能点。如果参与者忘记了这一点，并试图使用搜索，你可以提示他们：测试中不希望使用此功能。
第二点，留在产品内，这一点一般不需要特别指出，只是遇到测试者试图离开产品的时候，需要稍作提示。别忘了后续追问，用户为何会想要离开产品。
对于产品的开发人员而言，完成产品本身即是目的。但是对于用户而言，产品只是达到某种目的的手段或者工具。因此在可用性测试中，我们应该明确，我们只是把用户进入产品的某个目的当成任务表述了出来而已。
3.2 用户招募
3.2.1 招募什么样的用户？
市面上对于用户招募的条件主要有两种说法，第一种是坚持需要找到目标用户，或者有过产品使用经验的用户；另一种则是采取更灵活更自由的招募条件。下面就让我们分别来看看利用这两种方式如何招募用户。
首先我们来讲一下招募到目标用户的好处，非目标用户不一定有使用产品的需求，或者根本不会使用公司的产品。非目标用户可能遇到目标用户不会遇到的问题，因此目标用户遇到的问题更有参考价值。或者目标用户具备其他用户不具备的专业知识。如果你希望严格按照目标用户来招募测试用户，你需要注意以下几点：
根据测试目的来定，找出与测试目标有关的筛选维度
特别考虑用户使用行为相关的特征，例如竞品使用经验，使用产品的目的，用户活跃程度
挑选最核心的维度，转化成用户的招募条件，并尽量客观化、具体化、可衡量
注意辨别用户信息的真假
虽然许多书籍和文章在用户招募的时候都会强调，招募的用户最好是目标用户。但是到底是不是一定要招募到目标用户才能进行测试呢？其实不一定。
如果产品性质真的非常特殊，对于专业知识有很高的壁垒，那么招募目标用户对于可用性测试来说才是有意义的。举例来说，如果是要测试的是用于订购专业起重机的表单，用户必须在表格中填写诸如跨度、起重臂高度和起重量等信息，那么你可能希望是由目标用户来参与测试。因为非目标用户可能不能理解界面上的专业术语。
但是情况真的如此吗？任何产品都会有新用户需要来使用，即是是起重机司机也会有新手与老手之分，如果行业内的新手用户，他们通常还没有积累那么多的专业领域知识，而他也需要使用你的产品。
另外，很多严重的可用性问题可能与用户的专业知识毫无关系，只是最简单的点击区域、视觉层级这样的基本问题。而这样的基础问题是任何使用产品的用户都会遇到的问题。这样的问题也是阻碍用户持续使用产品的关键影响因素。
并不是说不应该招募目标用户，在确实需要实际用户的时，请务必招募这样的参与者，但是对于某些招募实际用户需要消耗更多成本和时间的产品来说，可以适当放松用户招募的标准。
有些特定问题只有通过观看目标用户使用产品才能发现，但是在可用性测试的初期，产品可能存在大量严重问题，而这些问题几乎人人都会遇到，测出这样的问题并不需要找特定的目标用户。因此在可用性测试刚刚开始的阶段，可以先放宽松招募条件。随着可用性测试的深入，我们可以加大实际用户的招募占比。
比起因为无法招募到目标用户而不进行可用性测试，对招募用户的条件进行适当的放松，多进行几轮可用性测试，显然才是更聪明的做法。
3.2.2 让参与者不停地说-发声思考法
比招募目标用户更重要的一点是选择那些活泼开朗且沟通意愿强的参与者。在进行可用性测试的时候我们通常会希望被访者能采用“发声思考法”。
发声思考法的一大特点就是让参与者一边说出心里想的内容一边操作。在操作过程中，参与者如果能够说出“我想看这里是因为我现在觉得......”，“我觉得下面我应该这样做......”等内容，我们也就能够把握用户关注的是界面哪个部分、他是怎么想的、又采取了怎样的操作等信息。
但是在正式进行测试的时候，你会发现有些参与者只会在提醒他的时候才进行发声。对于常常忘记言辞表达的参与者，我们可以间隔一段时间提醒他们一下。
在大多数情况下，当参与者保持沉默，我们也能够明确的知道他在想什么。例如，当他在阅读页面内信息的时候，就应该让他继续阅读。这种情况就应该让他们继续进行，而不要打断。但是当你有所疑问，就可以提问“您现在在想些什么呢？”一般情况下，用户会一边操作一边回答你的提问，说出心里的想法。但也有一种情况是，你一提问，用户就停下手上的动作进行操作说明，甚至返回上一页面进行说明，遇到这样的情况，可以适时减少提问的频率，记录下用户产生疑惑的地方，等用户整体操作完成再进行补充提问。
除了询问用户“您现在在想些什么呢？”，也可以询问原因，比如“您刚才为什么没有点击ok按钮，而是选择清除按钮呢？”还可以选择询问用户的主观评价等等。
3.2.3 招募人数
对于可用性测试的招募人数也一直争论不休。尼尔森博士曾经提出“有5个人参加的用户测试，即可发现85%的产品可用性问题。”大部分可用性测试的经验是一次测试招募3名左右用户。如果测试的人数少于3人，那么总是可以发现新的问题，但如果测试的人数多于6人，就很难发现新的问题。可用性测试发现问题的数量并不跟参与测试的人数呈正相关。
根据经验，一般邀请3名用户进行测试，那么可以在一个下午就完成整个测试流程，然后快速的整理结论输出。邀请的用户数量越多，记录就越多，就需要我们花费更多的时间进行整理。而其中很多问题其实无关痛痒，这可能反而会让严重的问题难以暴露。
并且找3名用户的成本是非常低的，与其最大限度的利用每一次测试，多做几次可用性测试显然更重要的多。可用性测试是一个需要长线进行的调研内容，因此测试应该遵循短频快的原则。如果每一次测试的用户足够的少，那么就更容易持续的进行测试。
3.2.4 招募渠道
确定招募条件与人数之后，我们就可以开始进行招募工作了。招募渠道一般有以下几种：
公司内部
现有产品用户库/种子池
公司其他产品用户库
熟人、朋友推荐
推广渠道：官微、公众号、社区、论坛、qq群
外包招募
上一篇用户访谈的文章里面许多招募渠道已经详细讲过了，再次就不过多赘述，有需要的小伙伴自行查阅一下上一篇文章。
在招募渠道中，想要重点讲的是公司内部招募。这也是进行可用性测试时最常用的招募渠道。确定招募条件和人数之后，我们一般根据新老用户来进行分类。新用户可以与hr部门沟通从新入职的同事中挑选，作为入职体验的一个环节进行。老用户则可以在同事吧等公司内部论坛中发帖进行招募，让同事们自行报名即可。不过需要注意的是，招募的时候不要选择同项目组的产研同事。且如果是测试同一个产品那么后续测试中不能启用原来参与过的用户。
无论是采用线上或是线下的可用性测试，招募到用户后，就需要给用户发出招募邀请了。一份完整的招募邀请中，一般需要包含测试日期、测试时间、测试地点、行车路线以及联系电话等。如果是邀请新用户前来测试，或是测试未上线的新产品，那么邀请中不需要包含测试内容。如果是线上的可用性测试，邀请中应该包含需要下载的可以共享屏幕内容的协同工作软件等内容。
3.4 注意事项
3.4.1 不回答，保持中立
由于是基于产品本身的测试，而我们作为产品的设计者，难免会对自己的产品带入主观的情绪。但作为测试人员，你应该意识到这种偏见，并尽可能的避免，要做到不要打扰到参与者，而是鼓励他们做每一步操作的时候都说出自己的想法。
另外，也不可以回答用户关于产品使用上的问题。这一点其实与上一篇用户访谈的文章要求是一致的。如果用户问“这个按钮可以点吗？”不要直接回答可以或是不可以，而是反问，“你认为呢？”，把问题踢回去，切忌不要给予任何提示。
在测试中经常也会出现这样的情况，我们作为产品的设计者已知某些页面中的可用性问题，但由于某些原因暂时没有修改产品方案。在测试的过程中用户果然在此处遇到问题并卡壳了。这个时候当用户提出质疑，表示这里不符合预期时，设计师经常情不自禁的附和用户“对！我也觉得这里很不合理”。遇到这样的时候请务必克制自己的情绪，不要附和参与者的观点。记录下问题，作为后续修改的佐证，才是更加明智的解决方案。
可用性测试的基本原则是正确地向用户传达任务后，不提问不回答，让用户自由发挥。换句话说也就是，只告诉用户“要做什么”，而“如何做”则是完全让用户自己考虑。
3.4.2 鼓励用户表达对任务的看法，而不是直接提出意见
在实际的测试中用户除了会对任务提出疑问之外，也有一种情况是用户直接对任务表达意见。在发声思维中，我们鼓励用户表达对产品的所有看法和认知。然而用户毕竟不是专业的设计人员，我们需要挖掘用户的需求，给出解决方案而不是直接全盘照抄用户提出的意见。否则你无法造出车子，而只会得到一匹更快的马。
3.4.3 如果用户不顺利可以给予适当引导
前面说到需要不提问、不回答用户，是不是代表测试的过程中只需要看着用户操作就可以呢？其实也不是。当用户出现以下几种情况时，可以给予一些引导
1.不确定参与者在想什么时，询问“您现在是怎么思考的呢？”/“您在找什么呢？”/“您在做什么呢？”
2.发生了让参与者意外的情况，例如，参与者点击某个地方然后对于新打开的页面发出“嗯？”、“咦”等语气词时，有时候用户的疑问并不都是通过声音表达出来的。比如说，凝视屏幕、把脸贴近界面、突然停下动作或者停止说话等。这些都按时了用户此时他对操作是有疑问的。因此，测试人员应该特别留意用户的动作。然后即使进行询问。但是，在测试过程中，切忌不可随意揣度用户行为并抢先给予提示。比如，“这个部分您似乎觉得很难理解”等等。
3.参与者对于某些功能发表了看法，这时你可以层层挖掘，了解到底为何导致了他的这种看法
4.参与者偏离了任务，可以询问他是如何思考的，了解是什么原因导致偏离了任务。
3.4.4 事后询问（回顾法）
可用性测试进行的过程中我们虽然都会鼓励用户说出思考的内容，但是如果当下未能察觉出用户的疑问，或者错过了介入的时机，又或者碰到了非常不善言辞的用户等等情况，都可能导致发声思考法不能如愿。
遇到这种情况我们也可以事后询问，“您刚才在xx页面做了xx操作，能说一下为什么这么做吗？”
需要特别注意的是，一定要在所有任务全部完成之后再使用回顾法进行提问。如果在任务执行过程中向用户提问，很可能打断用户的操作，作为采访人员我们绝对不可以干扰用户对产品的使用过程。
3.4.5 每场之间留一些时间进行记录和整理
对于测试时间的拟定，通常我们的做法是每场之间预留半小时的间隙，方便整理报告或是以防万一上一场时间太久。每场之间留一些弹性时间，除了方便整理上一场的报告之外，上一场用户遇到的问题，在下一场中也可以着重观察，以判断这个问题是特例还是普遍现象
4.1 测试大纲
以一个一小时左右的测试为例，其基本的流程和时间分配情况大致如下：
序曲（2分钟）：自我介绍、活动介绍、录像许可、保密协议
事前访谈&说明（5分钟）：询问用户背景以及产品使用情况；让用户在执行任务的过程中说出正在思考的内容（发声思考法说明）
任务执行（30分钟）：布置任务并观察
事后访谈（5～10分钟）：感想、主观评价、期望等
尾声（2分钟）：表达感谢，支付报酬、送客
然而，根据测试目的与访谈人的个人喜好，访谈的构成也不是一尘不变的。比如，有的访谈人更喜欢在每个任务结束 之后就询问参与者的想法和评价；或者可用性测试是在线上完成的，那么就无法完成保密协议签订这一步等等。
4.2 概要
下面我们来介绍一个以b站直播为背景的可用性测试实例，以下内容为该测试的概要：
测评对象：bilibili直播房间页
招募条件：观看过bilibili直播的用户
参与人数：3名
任务：加入某个主播的粉丝团
测试时间：40分钟
酬劳：bilibili精美周边
4.3 序曲（2分钟）
打招呼，说明此次访谈目的
“您好，我是bilibili直播的安琪。今天这个访谈主要是为了了解您对我们bilibili直播的使用情况”
录像许可，保密协议
“为了能够记录您的意见，这次访谈我们会进行录像，主要记录您的声音和计算机操作画面。另外，进入的录像我们只会内部做分析用，不会用于其他地方。同样，也希望您能对本次测试中的所有内容保密。”
4.4 事前访谈（5分钟）
产品使用情况
确定用户的手机型号，app版本号
“您使用bilibili看直播多久了？”
“您每天大概会有多少时间，使用bilibili看直播？”
“一般看什么类型的直播？”
事前说明
“希望您能一边操作一边把您心中所想的说出来，特别是您要怎么样操作，为什么这样操作，这些内容对我们来说非常重要，也非常具有参考价值”
“虽然您可以在访谈中进行提问，但由于我们想知道用户的产品使用情况，因此可能不会马上回答您的提问，事先对您进行说明一下，希望您谅解”
4.5 布置任务（30分钟）
“接下来，我们会请您使用一下bilibili直播。但是使用的时候会需要您带着一些目的性，完成一些小任务。”
“您逛到这个直播间，觉得主播的直播内容很有趣，于是决定关注这个主播”
任务一：（5分钟）
“这是一个电台主播，你觉得她唱歌很好听，想听她唱一首《干杯》，但是主播说‘加入粉丝团，卡牌子点歌’，于是你决定加入她的粉丝团”
任务起点：房间页
任务目标：出现入团成功toast
任务二：（5分钟）
“加入粉丝团之后，你发现直播间里大家的牌子等级都十几级了，而你只有一级，于是你也决定升级一下自己的粉丝牌”
任务起点：房间页
任务目标：出现“亲密度+xx”toast
任务三：（5分钟）
“最近正值某款游戏新赛季，还出了个新英雄，你不是很会玩，于是决定去找一个游戏主播看一下直播教学。”
任务起点：首页
任务目标：游戏主播房间页
任务四：（5分钟）
“主播完成了3杀，你觉得非常精彩，你的账户里有8000金瓜子，决定给主播投喂3000金瓜子左右的礼物。”
任务起点：礼物面板
任务目标：礼物动画/礼物连击条
任务五：（5分钟）
“主播说开通大航海就可以带你上分，你非常心动，于是你决定给主播上一个舰长”
任务起点：房间页
任务目标：上船动画
4.6 回顾提问（10分钟）
“今天请您使用了bilibili直播，请您谈一谈使用感受”
“如果要综合评价今天的体验，十分是满分推荐，您给bilibili直播打几分呢？为什么？”
（未达到满意的情况）“假设现在我们要优化评分，您认为哪个部分应该最优先得到改善？”
4.7 尾声（2分钟）
那么，感谢您今天的参与，我们的测试就到此为止了。感谢您为我们提出的宝贵意见，我们有一份小礼物要送给您（如果线上进行测试则询问参与者地址）
5.1 记录
5.1.1 所记述的内容不应该是“需要注意的点”，而应该是“观察到的事实”
记录是可用性测试中的重要环节。记录人员要记录的包括三个内容，观察到的事实，包括用户的操作行为，用户说的话，以及在操作的过程中，自己的发现。
需要注意的是，所记述的内容不应该是“需要注意的点”，而应该是“观察到的事实”。比如“使用不便利”是记录人员的主观猜测。而“用户在加入粉丝团时比较困惑”这个才是观察到的客观事实。
我们需要记录的是客观事实，即用户做了什么、说了什么。上一篇用户访谈的文章中也有提到，我们需要拿到的是，未经处理的一手用户信息。
5.1.2 从“用户的角度”记述
这一点经常发生在当记录员不是研究人员的情况下，半路被拉来的记录人员认为不需要完整记录用户的所有行为。只记录关键词或是将用户的原声转化为观点记录下来。比如“缺少返回按钮”并不是用户的行为或想法，而是产品的问题点。从用户的角度上来说，用户并不是希望想要返回按钮本身，而是需要“返回上一级界面”这个操作。因此，这里我们需要技术的内容应该是“用户无法返回上一级页面”
如果你无法判断到底是否是从用户的角度进行记录，有一个诀窍。如果你记录的句子能以“用户”为开头，那么则是从用户的角度在进行记录。
5.2 观察
5.2.1 请尽可能多的人来观察
可用性测试可以说是“百闻不如一见”的测试，只要自己亲眼所见，无论多么冲击性的结果都不得不接受。因此，前来观察可用性测试的人员越多也就越利于迅速作出重大决定。
相反，如果谁都不来参观，那么目击者只剩下你自己一个，而测试的结论并不是产研同学想要的，那么如果你无法说服别人，可用性测试的效果就会大打折扣。如果实在做不到请多人来观察测试进行，那么优先选择有决策权力的人参与。
5.2.2 观察者的注意事项：不注视、不发声、不介入
如果用户和观察者在同一房间内进行，肯定会给用户带来压力。因此我们需要将这种压力减到最低。这就要求观察者做到以下几点：
不注视：观察员不要盯着用户看，特别是在观察中要尽量避免和用户视线接触，观察员看着用户屏幕就可以了。
不发声：在测试进行的过程中，观察员之间窃窃私语、叹气等都是不可以的。如果在用户进行了某项操作之后，观察员突然叹气，会让用户感觉到自己的操作是不是有什么问题，进而无法放开手使用。
可用性测试需要采取一种短频快的节奏，因此我们需要避免在总结报告上花费过多的时间。大部分的产品迭代周期为2周，如果总结报告需要花费半周到1周的时间，那么必定是赶不上产品的迭代周期了。如果无法在第一时间拿到总结报告，那么报告也就没有任何价值了。
正确的做法是边测边总结，以一轮测试3场为例，当天或是隔天就应该给出报告，越及时越好。报告以excel或是word形式展示，附上界面截图，罗列问题点，给出修改建议，以及修改优先级即可
输出总结报告后，就需要我们根据优先级对问题进行修改。在问题优化阶段大家总是会将某个问题的修改扩大到整个产品上，超出实际观察到的问题范畴，甚至推倒某个功能进行重设计。并不是不能进行重设计，但是当可用性问题反复出现时，我们推荐的第一方案是“微调而不是重设计”，通过修改样式、位置、提示信息等等细微的、最简单的解决方案来解决观察到的问题，让多数用户不再遇到我们观察到的问题。并且将本轮测试中修改了的内容，放到下一次可用性测试之中进行再测试，以核实修改是否有效。
写在最后
可用性测试本身并不是最终目的，我们真正的目的是开发出好用的产品。任何的测试都只是优化产品的一种手段，因此无论看上去多么简单的测试，只要能提高产品体验就足够了。
