可用性测试的重点

可用性测试是在移动APP在设计、投入市场后用来评估可用性的一种常用工具。可用性测试实施时一般是使用发声思考，即用户在一个测试环境中被给予任务，并鼓励他们在尝试完成任务时出声思考。这能够帮助可用性测试的主试即实验者知道用户界面（APP设计）是如何帮助用户自然地思考和执行操作，强调对于产品的特色和改善方法的认知。

如何去定义一个可用性问题修改的紧迫性？

可用性问题的严重等级是一个重要的因素。当这个问题阻止用户任务完成时，就需要最紧急的修复行动了。Dumas和Redish（1993）使用了4个关键等级，至今仍被用户研究员引用的较多：第一个等级为最严重的等级，表示最严重的问题，第四个等级为表示最轻的严重性。Kallio等人（2004）也将问题按严重性进行分类：高（导致任务执行失败），中等（不是那么严重，任务可以完成）和低（小问题）。

实验室 VS 现场

传统的实验室测试

传统的可用性测试一般是在可用性测试实验室实施完成，如阿里、网易游戏都有专业的实验室，一般是由一间类似于办公室的区域和一面单向玻璃的可监视房间组成。必须保障实验室环境是一个安静的空间，测试的用户能够全神贯注于任务的执行。

实验室测试的担忧

经常在实验室进行测试的用户研究员都会担心在实验室进行的评估会由于没有模仿用户的使用情境而缺少生态效度。因为在现实的使用场景中，打断、移动、声音和多重任务操作等，这些没有出现在实验室测试中的因素，都可能在现实情景中影响到用户的操作。

现场测试

然而现场的可用性测试是非常罕见的，大部分（70%以上）的移动APP评估是在实验室设备中做的。这可能是因为数据的收集，如出声思考、视频记录或者观察记录，这些在现场做比较困难。

幸好由于便携式录像设备在近两年快速发展，使得在现场进行用户测试变得容易些。这些发展允许用户研究员像在实验室那样，可以在现场做一些小测试了；也使得他们能够有意识的去跟踪屏幕上发生的事情，去倾听用户的评论。同时也允许在现场的可用性测试中使用出声思考的方法。尽管发展了合适的工具，现场测试仍然比实验室更加耗时，也可能需要测试的用户和主持人付出更大的努力。

研究目的

敏捷用研在APP快速迭代开发的环境下被提出和倡导，以用户为中心的设计和可用性测试一定要非常高效。敏捷测试需要用户研究员在产品开发时间被严格限制的期间内，发现最重大的可用性问题在上线前进行修复。所以，可用性测试的焦点绝不是发现每个可能的细小问题。

如何使测试的结果最优化，选择正确的评估方法尤为重要。对可用性测试者来说，经过科学验证的合适的测试方法是非常宝贵的。在我们的研究中，主要的目的是了解清楚，当评估移动APP可用性时，现场测试是否有风险，或者实验室环境是否可以模拟出足够的生态效度。

对比研究

为了解清楚可用性测试中环境的影响，我们实施了一个对比研究，即同时在现场和实验室两种环境下开展可用性测试，并且保证其他因素（执行的任务，发声思考的方法等）都是一样的，只有测试的环境不同。

两种测试环境分别是：

1. 实验室：一般用户研究员进行可用性测试的地方，预算较低；
2. 现场：一个用户会真正使用移动APP的地方。

研究问题和假设

（1）问题：在实验室和现场会发现同样数量的问题和现象吗？

假设：如果进行对比的两组测试都是在足够多的用户中进行，那么现场测试发现的问题数量会更多。

（2）问题：在两个测试环境中发现的问题和现象会是一样的吗？如果不是，有什么差异？

假设：两种环境中的问题将会是不同的。例如最常下载时间在现场可能更能被容忍。

（3）问题：如果发现的问题有不同，那么是因为实验室或现场发生问题的严重性不同吗？

假设：现场的问题会因为在任务执行过程中被打断而更加严重。

（4）问题：任务执行时间会不同吗？由此我们可以从测试中推断出什么？

假设：任务执行时间在现场将会更长。

（5）问题：环境会影响测试用户的执行吗？

假设：现场测试的任务在执行过程中将会有更多的被打断机会，而打断行为的发生次数会影响用户操作。

（6）问题：当评估移动APP的可用性时，是实验室更适合还是现场测试更合适？

假设：当评估移动APP的可用性时，现场测试将会更适合，因为情境影响使用和操作。

研究结果

然而对比研究的结果使我们惊讶，因为结果并没有支持大部分我们之前的假设。

（1）问题：在实验室和现场会发现同样数量的问题和现象吗？

根据我们的研究：现场测试发现的问题会比实验室多，但并未达到显著差异。

我们的假设是在现场测试会发现更多的问题，但是没有被实验结果支持。

（2）问题：在两个测试环境中发现的问题和现象是一样的吗？如果不是，有什么差异？

尽管观察到了同样的问题，但是同一问题在现场测试中发生的频率更高。

（3）问题：如果发现的问题有不同，那么是因为实验室或现场发生问题的严重性不同吗？

假设是在现场会发现更多严重的问题，但是没有被证实。有关问题的严重性，在两种测试环境中没有差异。

（4）问题：任务执行时间会不同吗？由此我们可以从测试中推断出什么？

个人任务完成的时间，现场测试的用户没有比实验室测试的用户更长。当然在测试所需要的总时间上，现场的确要比实验室长，这说明现场测试是一个更消耗时间的方法。

（5）问题：环境会影响测试用户的执行吗？

在现场，测试有潜在的干扰，但是对于用户的操作似乎没有太大的影响。因为当执行复杂任务时，用户会寻找一个安全的地方（方位/角度）去执行，只有一小部分用户会一边执行一边踱步。在现场，用户的注意力会非常集中在测试上，例如在进出地铁时也会持续工作，在地铁上他们似乎也没有被其他地铁乘客打扰到，即使其他乘客会来和主持人说话。

尽管主持人的行为在两场测试中是一样的，但是现场测试中用户的表现似乎更加放松、随便，表现在他们更频繁的去发表关于APP的评论。

（6）问题：当评估移动APP的可用性时，是实验室更适合还是现场测试更合适？

当做一款移动APP的用户界面评估时，现场测试可能没法显著增加测试的有效性和完全性。不是因为一些问题没有被发现，而是因为现场测试所需要的时间更长，需要付出的努力更多。基于我们的实验，实验室测试似乎已经能够在提高用户界面和系统交互方面给予充足的信息。

现场测试完成后，主持人和用户交谈的更随意，似乎用户更容易说出自己关于产品观念的想法。现场测试的方法适合于不仅和一个系统交互进行测试，还包括测试用户行为和环境。另外，APP或设备如有一定的机密性那么测试通常是在实验室进行的，特别是在还在开发周期的产品。

在现场环境中，用户似乎在寻找一个安静的角落来和APP进行交互。个人空间似乎并不只在与别人交流时才被需要；在公共场合，当人们在做自己的事情时同样需要隐私。

研究的影响和将来的研究

正如用户研究员的目标是在严格的项目经费和时间的限制下，找到最大和最致命的可用性问题，那么这项研究帮助用户研究员在测试地点上做了决策。当测试一个移动APP的可用性时，实验室测试能够给予充足的信息。

给予用户研究从业者的启示

当测试一款移动APP的用户界面时，现场测试可能不是最好的选择；多数还是因为它比实验室测试更加耗时。

如果需要进行现场测试，则需要准备好比实验室双倍的时间来进行；因为在现场，你可能一天下来只能测试实验室的一半被试，且你需要做好事情不按计划走的准备，因为除了测试还会有更多的干扰和意想不到的事情。

在做现场测试前，先做一个严格的预测试是必要的；因为许多细节都会很容易出错，你真的需要检查所有的准备来确保万无一失。

文  / 媛媛大王 链接 / http://www.woshipm.com/user-research/424328.html

如果你是交互设计师，是否纠结过某个左滑出的功能，用户是否会发现？如果你是视觉设计师，那么，你是否为某个按钮究竟用什么颜色而抓狂？如果你是产品经理，是否也曾怀疑过设计师为什么这么做，用户到底会不会买账？

对于有些疑问，多动动脑子，答案可能就显而易见，而有些争议，即使磨破了嘴皮子，也还是各执己见，不相上下。此时，要想说服自己以及他人，最需要的就是找相关用户来说话。本文要讲的就是在此情此景，如何找用户来进行一场快速的可用性测试。

是的，上述的种种都是我以及身边的小伙伴们正在经历的。对于有些疑问，多动动脑子，答案可能就显而易见，而有些争议，即使磨破了嘴皮子，也还是各执己见，不相上下。此时，要想说服自己以及他人，最需要的就是找相关用户来说话。本文要讲的就是在此情此景，如何找用户来进行一场快速的可用性测试。

什么是可用性测试？

可用性测试就是邀请真实用户或潜在用户使用产品或设计原型，对其在使用过程中的行为进行观察、记录、测量和访谈，进而了解用户对产品的要求和需要，并以此作为改进产品设计的出发点，提高产品的可用性。

所谓的快速可用性测试，主要针对的是短流程，小项目，或者多选一方案的用户可用性测试，这种方式高效、快捷，我们无数次的疑问、争议，都是通过这样的方式找到了好的解决方式。那么，究竟如何来进行呢？

第一步，明确快速测试类型及产品目标

快速测试类型我把它分为两大类：探索型及验证型。探索型即为让用户通过使用产品，找出产品的可用性问题，进行优化；验证型即为有几种（UE/UI）设计方案，通过用户使用，最终选择最优方案。

注意：在验证型测试类型中，产品目标一定要考虑进去，明确这几种方案背后的产品目标是什么？有可能测试结果并非其中任何一个方案，而是有了更好的解决产品目标的方式。

第二步，任务创建

选择型可用性测试，一般针对的是产品短流程或者整个产品，此时就需要相关人员协商讨论整个产品的主要功能点（用户常用功能、产品核心功能、亮点功能等），对照这个功能列表分别创建用户任务。任务的设计要具体，尽量贴近用户的真实使用场景。

验证性可用性测试，这种情况任务比较明确，只需结合几种方案用户所使用的场景，确保测试任务符合用户实际使用行为即可。

第三步，预测试

任务创建完成以后，千万不要着急进行测试，所以这里插入个人认为非常重要的一点：预测试。预测试的目的就是发现设计任务是否有漏洞，及时修复。可以找公司内部的同事快速测试来完成。基本上我在每次的预测试中都会发现或大或小的任务漏洞。所以，为了保证测试结果的准确性，这一步千万不要偷懒。

第四步，招募用户

1、找多少用户

对于快速的可用性测试，到底应该找多少用户来测试？说到这里，可以参考Nielsen的这张经典图表，可能对于用户数量业内有很多的争议。我个人的项目经验来说，一般发现产品的重大问题的话，6~8个用户足够了，而对于验证型的测试，可根据测试结果及时调整数量，一般也会控制在12人左右，基本上符合了Nielsen的理论。

2、 找什么用户

我们在项目中一定会有的两个参考因素：是否使用过该产品及程度、是否使用过相似产品及程度。此外，一些基本的人口学特征（性别、年龄、学历等）也在筛选范围内。

3、哪里找用户

可能这个是我们项目中比较难控制的，项目的不同，也就意味着需要不同背景的人来测试，没有固定的一个组群来维护，这里就给出一些我们平时找用户的地方作为参考：公司内部非此项目组的同事们（充分利用公司的各个大群/小群/群邮件）、周边符合条件的朋友、产品的线上用户、产品论坛/贴吧等等。

第五步，用户测试

一切准备就绪后，即可开始用户测试。主要就是让用户完成预先设计好的一系列任务，我们在此时需要对用户的行为进行观察、记录、测量和访谈。

测试过程中注意：切记引导性过强；操作行为是重点（用户的语言可能带有欺骗性，应更多关注“用户行为”，鼓励用户“出声思维法”，即要求用户在操作时，将完成任务时所有的思考、行为、感受都描述出来）。

第六步，数据分析

1、 探索型可用性测试

通过用户测试，可能会发现产品很多可用性问题，在问题整理完毕之后，需要对问题进行分类或者优先级排序。参考业内的整理办法，主要有二级、三级、五级等。我们比较常用的是三级划分问题的方法，把问题逐个梳理。

问题的三级划分：高（无法完成任务）中（完成任务，效率/满意度不高）低（完成任务，较快/满意）

说到这里，就又回到本文开头提到的可用性概念：产品在特定使用环境下为特定用户用于特定用途时所具有的有效性、效率和用户主观满意度。那么对于问题的评估也是从这三个维度来打标签，详细解释参考下文：

• 有效性：用户完成特定任务和达到特定目标时所具有的正确和完整程度；
• 效率：用户完成任务的正确和完整程度与所使用资源（如时间）之间的比率；
• 满意度：用户在使用产品过程中所感受到的主观满意和接受程度。

2、 验证型可用性测试

这类的数据分析相较于前者简单一些，主要就是整理测试用户对每个方案的任务是否、效率、满意程度，最后让用户选出心仪方案，如都不选，则给出每个方案的优化建议。

上述就是结合自己的项目经验梳理出的快速可用性测试流程，再来回顾一下：明确目标—测试任务创建—预测试—招募用户—用户测试—数据分析，六大步。

总之产品可用性测试的好坏还是需要不断的实践练习才能有一个好的效果。诸位还是多多实践吧。

文/john 来源：http://www.woshipm.com/pmd/405753.html