Usability test可用性测试学习感想
Usability test可用性测试学习感想
翻译论文《Usability test》第二部分，结合现实生活典例，理解可用性测试。
可用性测试方法有很多，而用户体验只是其中一种，或一项指标。
可用性测试到底是什么呢？先给大家举个例子：比如扫码抽奖的活动，可用性测试的目的是观察用户在实际使用我们的用户是否能理解活动的意图，顺利的完成扫码，抽奖的操作。通过观察，修改给用户带来挫败感的地方，增加产品的易用性。所以，可用性测试其实是为了使真实用户流畅完成产品的操作和功能。
可用性测试，大多用于网站或移动应用的设计评估，其实也可以用于智能硬件的完整体验流程，通常会邀请目标受众群体中的真实用户，在特定场景下通过产品完成典型的任务。在真实的使用过程中观察用户的实际操作情况，详细记录并分析用户在使用产品中遇到的问题，目的是发现产品中存在的可用性问题，收集定性和定量数据帮助产品改进，并确定目标用户对产品的满意度。简单来说，可用性测试就是通过观察用户使用产品完成典型任务，发现产品中存在的效率与满意度相关问题的方法。
不论是做什么样的可用性测试，最重要的基本问题都围绕下面四个展开：
·为什么要进行这个测试（why）？
·什么时候在哪里做测试（when？where？）？
·谁要作为测试者（who）？
·我们要测试什么（what）？
当然这些问题其实都不太难，但是这些都是至关重要的问题。如果没有经过这个步骤的思考，整个可用性测试做下来就会像无头苍蝇，没有一个总的指导。接下来就按照这几个问题，根据论文翻译来讲一讲自己的感想与思考。
（一）为什么要进行这个测试（why）？
可用性测试（Usability testing），是一项通过用户的使用来评估产品的技术，由于它反应了用户的真实使用经验，所以可以视为一种不可或缺的可用性检验过程。也就是说，通过可用性测试应该让用户使用产品（服务）的设计原型或者产品，通过观察，记录和分析用户的行为和感受，以改善产品（服务）的可用性。它适用于产品（服务）前期设计开发，中期改进和后期维护完善的各个阶段，是用户中心设计的思想的重要体现。
（二）什么时候在哪里做测试（when？where？）？
在不同的地方测试会对测试者、被测试者和测试结果有巨大的影响。论文中主要讨论了网站测试法和实验室测试法的优点和缺点。但是，尽管测试的物理位置不同，但是测试内容应该包括实际使用其中最关键的组件。需要考虑的问题包括：实际的测试数据；可用的日常材料和工具；需要模拟的压力和时间压力；用户之间需要的合作；系统和其他有关材料的放置；以及组织情况和用户的作用。对于特殊的案例，可用性实验室还可以提供了一个控制良好的环境，接近用户，并且使用了特定于用户的实际研究数据来为每个测试用户提供更多的使用环境。
（三）谁要作为测试者（who）？
可用性测试当然要找潜在用户，或是按照统计学找出特定的用户，但是找几个用户来进行一次可用性测试？这个问题没有明确的答案。我们可以回归一下做可用性测试的目的：我们是希望发现严重的问题并尽快进行改进，而不是一次性发现所有的问题。一般来说，3个用户就会发现70%的问题。一次测试太多的用户，发现过多的问题，对于优先级和排期也会有很大的影响。并且越难做的事，越难以开始和坚持。每次找3名用户，测试并修改相关问题，下个月再次进行验证和发现新的问题，进入一个良性的循环。
（四）我们要测试什么（what）？
根据产品的功能列举出需要进行测试的任务，列举完后再回头与功能进行对比，看列举出来的任务是否覆盖了需要测试的所有功能。弄清楚用户的需求以及产生该需求的场景：设计测试任务时必须先弄清楚用户的需求以及需求的场景，这样你设计出来的任务才能将被测试的用户带入实际的场景中去。比如说一个客户经常到偏远的地方出差，这些地方的网络条件很差，几乎无法访问你的产品，于是你为该用户提供了一个离线访问的功能。客户的需求就是能在网络较差的情况下访问产品，而产生该需求的场景就是客户经常到偏远的地方出差。所以设计测试任务时必须要抓住“人”、“情景”、“目标”这三个要素，这三个要素一定要在你的测试任务中体现出来，最终的描述形式就是“谁在什么情况下要做什么”。
最后是沟通测试结果。测试结束后应与委托方面对面沟通，除了汇报测试结果，还有测试中发现用户需求与产品定位不一致或其他更好的改进方案，都可以与委托方做详细交流。
思考：该不该在测试中安排主持人呢？
现目前，基本已经形成了系统化的可用性测试流程，但是这些流程步骤中仍然存在具体的争议性问题，比如：到底应该在哪进行可用性测试？该不该鼓励使用出声思维呢？测试中需不需要主持人？
其实这些问题都没有确切的答案，优缺不一，论文中只是做了讨论，也并没有给出确切的说法，接下来我想就“主持人”这一话题，讲一讲我的想法。
该不该在测试中使用主持人呢？
由于主持人的存在可能会影响用户的性能和主观评级，因此建议用户仅在汇总测试中留下，或至少最小化与用户的交互。
例如，在论文提到的CRIS比较中，有一个主持人参加了测试，以帮助解决技术问题，但主持人大多是沉默的，并且在需要时只给出了预定的答复。在形成性测试中，强烈建议在用户旁边设一个主持人，因为这给用户提供了一个宝贵的机会来密切观察用户的“第一印象”，并探讨他们的期望和体验。但是主持人的存在常常会使用户感到紧张，一个陌生人随时随刻盯着你，经常会影响正常发挥，对测试结果造成影响。
既然用主持人很有必要性，但是又主持人与用户的互动又会影响测试结果，那么就应该通过一些改进，来减小影响，使测试结果更加准确合理。所以我认为从心理学角度出发，主持人应该：
1.让参与测试的用户一直保持出声思维，不断的说出自己的想法，看到的，想到的，关注的内容等等。
2.主持要保持中立的态度，不要因为是自己做的产品就往好的方向引导，或者不看好产品就往不好的方向引导，这样就会失去做可用性测试的意义。
3.如果参与者有疑问，主持人可以考虑以问题来回答问题，尽量不影响用户的判断。
“我这么操作对吗？”
“您觉得呢？”
4.主持人要注意观察用户的表情和身体语言，随时知道用户在做什么，想什么，如果不知道，出声询问。
测试后续问题
测试结束后如果出现问题，论文中并没有给出解决方案，但是在网上我查到了几条建议，用于在出现问题时的解决方法：
1.微调，而不是重新设计
当我们发现问题，直觉反应是重新设计整个页面或者功能，完美改进所有问题。但是“天下没有白吃的午餐”，完美意味着更长的排期和更多的设计开发量。我们可以通过找到修复问题最简单的修改，对产品进行微调，快速验证修改是否有效。
2.尽快，而不是等待大改版
我们遇到问题，经常会用一个说法，“等到xx改版的时候，一起做了”，xx改版往往是个比想象要漫长许多的时间，很多发现的问题就不了了之了。如果发现的问题都不能得到解决，还有多少人愿意坚持做这件事呢？
3.做减法，而不是加法
当我们发现用户不理解我们要表达的内容，最先想到的方法是添加更多的说明，来详细的解释这个内容，但是很多时候，用户在网站上跳跃式的浏览，可能是干扰信息太多，而不是说明信息太少。最好的设计不是加无可加，而是减无可减。
4.微调，但要验证
微调之后，调整的方式是否有用，需要再次验证。如果只是把按钮放大这类，可以随便找个人看一下是否能关注到你调整后需要他注意到的信息。如果是大的挑战或者多个微调，那就需要加入到下个月的可用性测试中，看看是否有效。如果有效，需要看看是否会影响到之前的功能，如果无效，那就尝试用过一个系的微调。
从开始测试，确定测试目的，寻找测试用户、记录数据、分析结果到解决问题，可用性测试的各个环节都是为了 发现系统中存在的问题，并作出合理的处理和解决，以使系统能够达到用户体验和性能最佳的平衡点。