最近在读Steve Krug的《Don't Make Me Think》，这本书主要讲的是Web 端的一些设计原则，不过我觉得放在其他终端设备上也同样具有参考价值。
在项目期间，不可避免的需要对产品功能进行测试可以验证或者发现一些问题，书中正好就可用性测试做了详细全面的阐述，今天就书中提到的可用性测试流程做一个整理，希望对大家能有所帮助。
在交互具体方案评审时,大家可能遇到过这样的场景吧：
在评审时，参与人可能有产品、交互、视觉、开发，大家由于职位、使用习惯的不同常常对于方案各执一词，每个人可能会觉得用户会像自己的操作习惯一样使用，或者觉得用户也像自己一样能够看懂，然后在无休止的争论着，最后谁说服力强，就以谁说的为准，而关于这些想法可行不可行最后也无从验证。
而此时引入测试，既能避免团队无休止的争论（浪费时间又消耗精力），也会让我们看到用户的动机、理解、反应的差异，从而让我们不会坚持认为用户的想法和我们的想法一样。
下面就可用性测试的形式和操作方法展开讨论。
可用性测试的形式
说到测试大家是不是会想到高大上的实验室，有单向玻璃，有摄像机录制，花费昂贵。光想想都觉得氛围严肃又紧张。
不过现在大可放心，可用性测试不必那么麻烦，操作很简单很随意，只需一个安静的房间，一个微型麦克风以及终端设备就OK了，是不是so easy啊～
在可用性测试中，一次一个用户，我们观看用户试用，去完成一些典型的任务，通过观察用户的行动，你可以检测到那些让用户混淆和倍感挫折的地方。
工作中大家可能也听过焦点小组的测试方法，那么这二者具体有啥区别呢？我整理了如下表格：
可用性测试操作过程
一.应该多久进行一次测试
作者的观点是每个月可安排上午半天的时间测试一次。
为什么安排半天时间测试呢？
1. 能保持测试简单，所以能坚持进行，若太花时间，可能以后忙的时候就不会安排测试了。
2. 这样就能满足需要，可找到足够多的问题。
3.人们更可能参与进来，在一个相对稳定预知的时间进行，这样可增强团队成员参与的机会。
二.应该测试多少用户
作者认为很多情况下每轮测试的理想对象为3个。也许有人会认为3个太少了，他们觉得这么小的样本证明不了什么，也不会发现所有的问题。这二点都是对的，但是都不重要，因为:
1.这类测试的目的不是为了证明任何东西。要进行证明，需要进行定量测试，需要大量样本量，一份清楚定义、严格执行的测试计划，收集大量测试数据并进行分析。
可用性测试是一种定性的方法，它的目的是通过发现和修复可用性问题来改进正在建造的东西。这个过程一点也不严格，你让他们完成一些任务，你在旁边观察，然后你会了解到很多原来不知道的事实。测试结果是切实可操作的发现，而不是证据。
2.你不用发现所有问题。事实上，你在进行任何测试的时候，也永远不可能发现所有问题。因为事实如下：
一个半天的测试，就能让你发现太多的问题，一个月都修复不完。
把注意力集中在首先修复最严重的那些问题上。而且前三个用户可能会遇到几乎所有最明显的那些和当前任务相关的问题。
三.怎样选择测试参与者
人们决定要测试之后，通常会花很多时间来招募他们认为能精确反映目标群体的测试用户，如果能请到目标用户来测试，那么也很好，不过其实这并没有那么重要。
根据严格的条件进行招募，意味着需要付出更多的劳动和更多的金钱。
如果你们时间充足，或者预算很充分可以请人帮忙招募，那么可以尽量按照你们的条件去筛选，但是如果寻找理想用户意味着你将减少测试次数，那么可以采取另外一种方式：
宽松招募，曲线上升
换句话说，去寻找目标用户，但是别因此裹足不前。
四.谁应该进行观察
你应该鼓励团队成员、利益相关人、各级经理，甚至决策层的管理人员来观看测试过程。对于很多人来说，这完全是一次颠覆性的体验，一下子就改变了他们对用户的认知。
可以请观察者在每场测试间隔写下三个最重要的可用性问题，并在总结会上进行分享。
五.什么时候测试，测试什么
测试越早越好，甚至在开始设计前就可以开始测试，你可测试一下竞品或者功能类似的产品。看他们在竞品上进行几个关键任务，你会了解很多，哪些地方效果好，哪些地方效果不好。这样开始设计后可少走很多弯路，节省成本。
如果是在重新设计现有产品，就更需要在开始之前进行测试了，这样能知道现有的设计哪些地方有问题(这些地方需要改)，那些地方效果很好(这些部分需要保留)。
在整个项目过程中，需要持续对团队产出的任何东西进行测试，从最开始勾勒的草图，到线框图，页面排版、界面原型，还有最后的产品。
在测试中，如果可以允许测试参与者自己决定一部分细节，那么你通常可以得到更有意思的结果。例如，“找到一本你想买的书”，会比“找到一本14元以下的书”好得多。这样会引入他们自己的情感，并且可以让他们更多地用上他们自己对这些内容的理解。
六.测试过程中会发生什么
1.欢迎部分。开始测试，并介绍测试接下来如何进行，让测试参与者有些心理准备。
2.提问部分。接下来可以问参与者几个和他们有关的问题，这样可以帮助他们放松下来，你也可以借此机会了解他们是不是计算机高手。
3.浏览首页 。请测试者大致浏览下首页，让他们告诉你他们看到了什么，你就会知道主页理解起来有多容易，以及测试者有多了解产品所在领域。
4.任务测试。这是测试的核心部分，你的工作是让测试参与者一直停留在测试任务上，并让他们把自己当时的想法说出来。
在测试中，让测试参与者自己进行测试任务很重要，不要做任何事或者说任何话去影响他们。不要询问他们引导性的问题，也不要为他们提供任何线索和协助。
5.问题探查。测试任务结束后，你可以就测试中的发生的任何事情向测试参与者提问，还可以提出那些观察成员希望你问的问题。
七.测试总结
无论何时，你的目标几乎都是找出一些最严重的可用性问题。但是，它们往往不是最后得到修复的那些。比如，人们可能会说：“是的，那确实是一个问题，但是那个功能马上要修改了，我们可以留到那时候再说。”或者面临修复一个严重问题还是一堆简单问题的选择之下，他们选择了容易些的。
修复问题有一条重要原则：
最严重的问题最先修复
下面是作者推荐的筛选问题的方法，不过不一定要跟这一样，找到自己团队适用的就行。
1.收集一份问题列表。让每个人说出他们觉得最严重的3个问题。把这些问题写在白板上，通常很多人对一些问题会说“我也是”，对这些问题你可以打勾会画“正”字做标记。
2.选择10个最严重的问题。可以进行非正式的投票，也可从标记最多的问题开始。
3.建立排序列表。对它们从1到10进行评级，对每个问题在下个月准备怎么修复，写下粗略的想法，谁负责修复，以及需要什么资源。
这里需要注意的是并不需要对每个问题都完美修复，或者说不用完全修复，只需要采取一些调整把它移出这份“最严重问题”的列表就可以了。
关于修复什么，不修复什么，有一些小建议：
1.对那些非常容易修复的问题建立一份列表。“非常容易”指的是一个人可以在一个小时内完成，而且不需要得到任何不在总结会现场人员指示的情况下完成的那些问题。
2.抵制添加的冲动。看到测试参与者没有理解某项内容时，大部分人的第一反应是增加一些东西，比如注释或者指导说明。而往往正确的方案是拿走某个让人混淆的东西。
3.不要太看重人们对新功能的要求。测试参与者常说：“如果它能做✕✕就好了。”这样的说法常被看作要求新增功能。但是测试参与者不是设计师，他们偶尔会提出一个很好的想法，不过如果确实是一个很好的想法，一般你也会在第一时间反应过来：“为什么我们没早点想到这一点。”
4.忽略“皮划艇”问题。你可能会遇到测试参与者暂时出现错误，然后又在不需要任何帮助的情况下回到原来的轨道。你可以忽略这些，总的来说，用户的第二次猜测是对的，就可以了。
以上是我对书中关于可用性测试的整理总结。总之，可用性测试越早引入越好，越早发现问题越早解决嘛，不用等到产品已成形再去测试，如果出现问题那改动点会很大了，可能之前做的工作量都要推翻重来，这很浪费大家的时间和精力。
作为交互设计师，我们不仅要记住一些重要的设计原则，也要对原则背后的原因心知肚明。因为在设计工作中，我们始终要与上下游同事保持沟通，跟他们去解释自己的设计方案，去回答他们的质疑。了解的越多，底气才会足，观点有理有据才会更有说服力，更重要的是工作的展开在双方都理解的基础上会配合的更好。
