可用性测试实践经验

可用性测试是用研的入门必修课，也是用研最常用的方法之一。这篇文章总结了我在做可用性测试时踩过的一些坑，以及总结出来的一些实践经验。

研究设计

1. 必须清晰地定义产品面向的不同角色，如果不同角色的知识背景和使用场景相差较大，就不要用同一类用户去测试所有的任务。我们做的是一款ToB产品，面向的是企业用户，很自然地，我们的用户分为两大阵营：管理层和基层员工。做可用性测试时，考虑到邀请管理层用户成本高难度大，且这次测试中我们更关注的是基础功能的可用性，所以邀请的用户基本都是基层员工。但是我们仍然为这些基层用户设置了一些属于管理场景的任务，希望能够从中挖掘到一些有价值的信息。结果可想而知：软件本身就具有一定的复杂性，基层员工不熟悉企业管理，在做任务的过程中可能连相关概念都不太懂，任务完成率非常低。我们想了解在用户自主试用和探索之后，对产品的印象和态度如何，但是大多数基层员工现实生活中并不会有去自主试用这些产品的动机，因此用户表达的可能是自己假想的态度，不具有太大参考价值。更好的方式是在研究设计阶段就清晰地区分开管理层和基层的不同场景，如果对这些功能设计都存在疑虑，就分别邀请管理层和基层，做两场基于不同场景任务的可用性测试。
2. 重视行为以及对行为的解释，不要花太多时间去了解用户态度。可用性测试是定性研究，样本量比较小，从这样小的样本中得到的用户态度并不具有推断价值。而用户的行为和认知的个体差异和测量误差相对要小得多，因此结果要更加可靠一些。在我接到的调研需求中，就包含了“了解新用户对产品的印象和态度”这一项，并且设计师也提了很多问题给我——对于他们不太确定的问题，他们希望知道用户怎么想。光是询问这些问题，我都能跟用户做场一个小时的访谈了。把它们加到可用性测试中，会导致测试时间太长，影响了真正重要的任务测试过程；并且如果只是简单询问这些问题而不深入了解，得出的结论也确实没有多大价值。

用户招募

一定要为参与测试的用户设定一个合理的标准，不要因为用户难找、时间紧迫而降低标准。由于招募渠道有限，报名用户不多；而我当时既要做好脚本设计的工作，又要同时筛选和预约用户、预约会议室、调试设备，并尽可能快地开始测试，时间紧迫和人手不足让我不得不降低用户筛选标准，因为我没有精力去拓展其他招募渠道，也没有时间等待更多的用户报名。这样做的结果是招募到了一两名确实不太适合的用户，而这是在用户筛选的过程中本可以避免的事情。建议在平常的工作中多拓展招募渠道、建立用户库，这样以后再有比较紧急的测试任务时，可以相对轻松地完成用户招募工作，避免只能通过降低标准来完成招募。

脚本设计

1. 任务千万不要太多，如果安排了一个半小时的时间，任务最好不要超过6个。任务太多会导致用户非常累，也很难以较好的状态去完成后面的测试任务。尤其是当我们没有条件提供一个环境较好的会议室时，用户在密闭空间中待的时间太久，非常容易疲惫和注意力分散。任务完成了稍多于一半的时候，我一般都会询问用户是否要休息一下。有的用户会乐意休息一下喝口水，但有的用户却希望再坚持一下，以便尽快完成所有任务——尽管坚持的效果往往不会太好。
2. 有些功能本身就很复杂，在短时间内让用户了解和学会操作，对用户来说难度太大。功能的复杂性可能体现在概念体系或者业务逻辑上。如果是概念复杂，可以用学徒式的问题，多问一下“这是什么意思”，了解用户难以理解的是哪些概念；业务逻辑的复杂可能会涉及到较多的前后文操作、多角色交互，短时间内要还原出这个生态并不容易，遇到这个问题可能意味着我们把任务设计得太大，适当做些拆分可能会更好。
3. 设计任务时到底要不要去问对应的产品经理和设计师？前面提到了设计师向我提了很多想要从用户那里验证的想法，正是因为我去问了，才会收集到如此多让我头疼的问题——很多问题不适合放在可用性测试中问，所以又要告诉产品和设计师们这些问题解答不了。似乎怎么看都是一件很麻烦的事情。但其实，还是应该问，只是要换种问法。不应该问“对于这个功能，你有什么想了解的问题”，而应该问“哪些功能是更重要的”“你对哪些部分的设计比较不确信”。他们对产品更了解，因此只要问对了问题，对于任务设计总会有好处。

测试过程

1. 测试过程使用哪些设备、录屏录像需要哪些工具和环境，必须有一套完整的解决方案。测试过程总会出现很多意外状况，比如WiFi连不上，录屏软件没反应等，出现了问题的话就会耽误用户的时间。之前的测试中就是状况不断，尤其是使用安卓手机的用户，录屏比较麻烦。针对这个问题我专门整理了一下可用性测试中常用的设备，制定了一套比较适用、成本也不太高的解决方案，感兴趣的话可以看一下我的另一篇文章。
2. 如何让用户think aloud？我一般会在开场白的时候说一下，希望用户随时将自己的想法讲出来；在第一个任务开始之前，我也会强调一下这件事。遗憾的是，到目前为止还没能成功让用户做到think aloud。这对用户来说是一件不太自然的事情，因此比较难让用户抗拒强大阻力做到这点。我目前的一个想法是在任务开始之前给用户一点时间去练习和习惯think aloud，让用户能有时间去适应这种状态。
3. 要合理分配任务时间。开场白的时间、每个任务的时间、测后访谈的时间都需要在脚本设计的过程就大概确定，如果在测试中发现某个阶段占用的时间太长，就需要控制一下时间，避免影响后续的任务。
4. 尽量减少使用的打印纸的数量。测试过程难免需要一些纸质材料，但是本着低碳环保的理念，打印的纸能少就少。

我在做测试的时候有一些打印纸的标配：测试脚本会打印两份，一份是我主持的时候需要看的（我可能在上面对脚本做些注解和调整），一份是给帮忙做记录的同事以及到场观察的PM设计等人看的（不管他们有几人）；任务卡片会打印一份，是给用户看的；用户登记和礼金签收作为同一个表，打印一份；知情同意书需要让用户感到足够正式，因此每个用户打印一份（我克制住了自己正反面都打印的冲动）。

接下来是令我头疼的部分，就是每个任务结束之后的评分表。一般一页纸就可以搞定，但是如果每个用户都打印一张感觉有些浪费。我一度使用在线问卷的方式，用我自己的手机打开问卷链接，需要评分的时候就拿给用户，但效果不好，一是手机界面小看着比较费劲，二是这需要我在几个页面之间来回切换，增加了我（作为主持人）在测试期间的工作负荷。后来想到一个很好的方法：打印一张评分表就好了，然后准备一些条形便利贴，让用户直接把便利贴贴在自己选择的选项上，测试结束后把用户的评分录入到电子表格中，打印纸就可以重复利用了。这个想法本来没有什么高明之处，它主要的优点是：我可以顺便让用户在条形便利贴上写下自己打这个分数的理由，因为空间有限，就可以收集到一些非常言简意赅的理由。

分析整理

1. 选择一个合适的模型对不同功能的可用性进行综合评估，便于对功能进行横向比较。比如，可以参考ISO对可用性的定义：可用性=有效性+效率+满意度。有效性可以用任务的完成情况来度量，效率可以用任务完成时间来度量，满意度可以用用户评分来度量。这样子可以形成任务的可用性水平矩阵，便于在不同任务之间进行比较。
2. 测试发现的可用性问题需要有一个优先级评定标准。简单地通过发现该问题的用户数来判定问题优先级是不太合理的，建议使用樽本彻也的方法。对有效性、效率、满意度三个指标分别给定三个等级， 并赋予不同的分值，对每个可用性问题，评估在每个指标上处于哪种严重等级，按照下图的标准，评定问题的优先级：
   
   

   樽本彻也建议的问题优先级评定标准

如果对以上提到的问题有更好的建议和解决办法，欢迎指教。