可用性测试
本文摘自《Handbook of Usability Testing》，作者：Jeffrey Rubin和Dana Chisnell，由天翼应天书院的用户研究员张晓雯翻译。
什么是可用性测试？
可用性测试（usability testing）这一术语被不加区分地指代任何评估产品或系统的技术方法。很多时候，演讲者明显是在讨论本书第一章介绍的其他方法（如启发式评估、任务走查等），却仍称呼这些方法“可用性测试”。本书中可用性测试是指：
招募有代表性的目标用户作为测试参与者，评估某产品是否符合特定可用性标准以及符合程度。
可用性测试以具有代表性的真实用户为测试样本，这不同于专家评估、任务走查或其他不要求具有代表性的真实用户参与的测试方法。
为什么进行可用性测试？
站在公司的立场，可用性测试是为提升产品收益而付出的巨大努力之一。
可用性测试的好处
进行测试的好处很多，用户最终也获益良多：从具有代表性的用户中收集数据以帮助设计决策、修复设计问题，减少或消除用户的挫败感。
- 信息化设计（Informing Design）
可用性测试总体目的是在产品发布前识别和修复产品（包括附加的支持材料）中的可用性缺陷，一般是使用产品或原型方法来发现界面设计中的可用性问题，收集测试数据帮助信息化设计。目的是保证新产品：
1.1 是对目标用户有用且有价值的
1.2 是易于学习的
1.3 可以帮助人们有效并高效地处理事务
1.4 使用时令人满意（如果可能的话，甚至是令人愉悦的）
- 消除设计问题和挫败感
正如硬币的两面，与产品收益相对的是用户使用产品的易用度。如果产品发布前，你完美解决了产品设计的缺陷，目标用户在使用产品时挫败感最小（甚至没有）。那恭喜你，你同时也实现了如下目标：
2.1 为你的组织与用户建立良好关系奠定了基础
2.2 提前设定了预期，你的组织销售的产品不仅优质且易于使用
2.3 表明你的组织重视用户目标
2.4 用户会发现你的组织所发布的产品是有用、有效、高效且令人满意
- 提高收益
你的组织进行可用性测试的目的和益处： 3.1 创建可用性基准的历史记录，与后续版本比较。公司通过追踪测试结果，保证新产品已经提升了可用性，至少也保持了以往水平。
3.2 减少服务和支持呼叫的成本。一个易用的产品不需要多余的服务呼叫以及公司的其他支持。
3.3 增加产品销量和重复销售的可能性。有用的产品创造了愉悦的用户，他们与身边潜在的购买者（客户）或用户谈论或推荐。同时，愉悦的用户会继续使用产品的未来版本，而不会购买竞争对手的产品。
3.4 赢得竞争优势，可用性已成为产品在市场中的分水岭。可用性已成为用户区别某产品与竞品的主要标准。你在选择时，只要浏览最新广告并筛选出被形容为“简单”、“容易”的产品就好。不过，不幸的是，在这些产品被测试后发现对其的描述并非恰如其分。
3.5 降低风险。事实上，所有的公司和组织已经进行可用性测试很多年了。只不过这类测试的真名是“产品发布”， 投入市场的产品在用户试用时被“测试”。显然，这样的战略引起巨大的风险，而产品发布之前进行可用性测试可以降低发布后的产品存在严重可用性问题的风险。
方法学基础
进行可用性测试的方法学基础是实验控制的经典方法。进行基础研究的正规做法通常是：形成特定假设，在控制情境下隔离和操纵变量来检验假设。通过合理的推论统计方法严格地考察变量间的因果关系，从而接受或拒绝特定假设。
真正的实验设计具有如下特征：
- 形成特定假设。假设是指在检验中你所期望发生的结果。譬如，“A格式的帮助设计相比B格式的帮助设计，提高了有经验用户的速度和错误率” 。假设必须尽可能地具体。
- （采用非常系统的方法）随机选择参与被试并分配至不同的实验条件。你需要理解目标总体的特征，从总体中随机选择具有代表性的样本。随机抽样非常困难，尤其是在目标总体是现有客户时。
- 严格控制。实验控制非常重要，否则即便达到统计显著性，结果的有效性仍将受到质疑。在测试前或测试中，所有测试参与者的产品使用经验必须是大致相同的。另外，与测试主持人的交互程度也需要控制。
- 必须设置对照组。为了结果有效，必须设置对照组；对照组只在需要考察的某一变量上的设置与测试组有所区别。
- （用户的）样本量必须足够大，可以在统计上检验组间显著性差异。为了测量组间统计上的差异，需要较大的样本量。样本太少可能会导致结论错误。
上述为经典实验的方法基础，在进行基础研究时，这不失为好的选择。但是，它不是本书所介绍的可用性方法，理由如下。
- 本书大多数读者置身于节奏快、压力大的产品开发环境中，采用上述方法进行可用性测试通常是不可能或不恰当的。出于公司制度或其他方面考量，这样的测试方法也是不可行的。进行可用性测试的目的并非是建立或检验某个假设，而是形成提高产品的设计决策。
- 富有经验的可用性或者人因学专家仍旧需要充分掌握实施经典实验研究的方法和统计知识。一名没有相应背景或缺乏训练的测试者得出的研究结果有可能是令人误解的，甚至会造成更坏的后果，这比不进行任何研究更糟糕。
- 当经常进行测试时，你通常很难践行随机分配测试参与者这一原则，你很难控制这个因素，尤其是以现存用户作为测试参与者。
- 不采用正统的实验方法的另一原因是样本量。实验研究中，结论需要推广到特定的目标总体，其必须的样本量大小是依赖于总体的现有已知信息。但通常这类总体信息又是未知的（这有时也是进行测试的原因）。由于缺乏总体信息，保险起见，每种条件需要10-12名测试参与者，考察单个因素就可能需要测试40个甚至更多的用户以达到统计上的显著结果。
- 最后并且可能是最重要的一点，经典的方法学是为了收集验证假设所需的定量证据，譬如某种设计优于另一种，而不是为了获取定量信息，以解决问题和重新设计产品。我们认为多数读者更关心后者而非前者。 我们推崇的方法相对非正式，是基于迭代的测试，但本质上仍遵循实验的严格性。在本书的后续章节中，你也会发现，实验严格性这一准则对任何研究来说都是必须的。 在产品发展的早期阶段，进行一系列快速、具有针对性的研究是大有裨益的。这也正是本书介绍这类非正式却被严格设计的测试的目的：发现产品某些可用性缺陷、识别原因并找出克服它们的方法。下节我们将描述测试的基础方法。
可用性测试的基本要素
- 形成研究问题或是测试目标，而不是假设。
- 选择具有代表性的用户样本，这些样本可以是不被随机选择的。
- 测试环境类似真实的工作环境。
- 观察终端用户使用或者回顾真实产品。
- 测试主持人需要控制，并且有时需要访谈和调查参与者。
- 收集定性和定量信息以及偏好数据。
- 对产品的设计提出改进建议。 我们将在后续的章节中详述如何进行测试。 缺：测试的方法论|具体操作步骤
可用性测试主要过程
- 招募测试人员
- 原则：测试人员要尽可能地代表将来真实的用户。e.g.产品主要用户是新手，则应当选择一些对产品不熟悉的用户
- 准备测试任务
- 准备一系列让要求用户完成的任务，这些任务应当是实际使用中的典型任务
- 测试过程
- 用户使用产品完成所要求的任务
- 组织者在一旁观察用户操作的全过程，并记录发现的问题
- 测试结束后
- 可以询问用户对于产品的主观看法或感觉
- 询问他们为什么会做出那样的操作
- 研究分析
- 组织者分析记录并产出一份产品的可用性问题列表，并对问题的严重程度进行分级，使得PM可以根据项目进度选择优先处理
可用性测试常见问题及对策
- 可用性测试做的太晚（往往在产品快要上线时）
- 产品测试在产品的各个阶段都可以做。
- 产品已上线运行时，拿真实的产品给用户做；
- 产品只有页面Demo时，拿Demo给用户做
- 产品只有纸面原型时，拿手绘
- 的产品加纸笔给用户做
- 尚无任何成型的产品时，拿竞争对手的产品给用户做
- 产品测试在产品的各个阶段都可以做。
- 觉得可用性测试很专业，干脆不做
- 可用性测试听着很专业，但收益无法量化
- 尝试轻量级的可用性测试，如坐在同时旁边，半个小时，简单的几个任务：将xxx用户的有效期增加一年，将yyy公司的状态设置为冻结查询zzz公司的员工数量
- 可用性测试听着很专业，但收益无法量化
- 明确测试的是产品，而不是用户
- 测试前明确告诉用户此活动测试的是产品中的问题，而不是测试用户是否有能力使用该软件。所以，不要让用户听到“可用性测试”等术语，而是说“来试用一下我们的新产品吧，我们需要你的意见”。清楚地说明这一点有助于减轻用户的压力，使得他们能像在阵势环境中来使用软件。
- Do and Don't
- 测试开始时，告诉用户大概持续的时间，要做哪些事情，让用户心中有数，轻松愉快地完成任务。
- 测试过程中，要求用户在使用产品的过程中使用一种名为“发声思维”的方法，即在使用产品的同时说出自己的思考过程，比如为了完成某个任务，用户需要先做什么，再做什么，后做什么，做什么要做某个动作等。
- 测试过程中千万不要有任何引导以及暗示，而只是观察和记录，因为任何引导都可能使得原本可以发现的问题无法暴露。用户行为和预想的不一样时，可以提问，实在进行不下去时再给予提示。NB.一切的错都是产品和我们的错，用户绝对没有错。
- 测试结束后，送点小礼品。（邀请时要告诉用户会有一些对他付出的补偿）尽快总结并且反馈给用户，一方面让觉得自己在做一件有意义的事情，一方面也表示感谢，建立长期和谐的“用户参与产品设计”的氛围。
- NB.可用性总结要用于指导产品改进，这才是可用性测试的根本目的。
测试的局限性
现在我们已经描绘出可用性测试可实现的目标这一宏伟蓝图，也是时候让我们浇点冷水了。测试绝不是可用性或是产品获得成功的全部或关键因素，理解测试的局限性至关重要。测试无法保证产品的成功，甚至也不能就此证明产品是有用的。即使是被最严格执行的正规测试也不可能100%的确信产品发布后是有用的，这是因为：
- 测试通常是在人为环境进行。
- 在实验室测试，即便是在现场测试，也只不过是对真实使用环境的模拟，本身并不是真实使用环境。执行测试本身就有可能影响结果。
- 测试结果无法证明产品是可用的。
- 即使某个产品的测试结果达到统计上显著，仍不能证明这个产品运行良好。统计上的显著性仅仅是衡量测试结果不是随机造成的这一可能性，并不能保证产品是可用的。而且测试结果与测试进行所在的环境有很大关系。
- 测试参与者不能完全代表目标用户。
- 参与测试者仅代表了你所理解和定义的那部分目标用户。市场研究毕竟不是绝对正确的科学，而且真正的最终使用用户通常是难以识别和描述。
- 测试并不总是最好的方法。
- 我们在第1章和第13章讨论了众多评估和提高产品的方法。例如，在某些案例中，相比可用性测试，进行专家或启发式评估在成本、时间和准确率上更为有效。尤其是在早期阶段，不成熟的产品会违背较多可用性准则。此时我们并不需要为了发现这些显而易见的问题而招募众多测试者。
尽管存在上述局限，作为一种以用户为中心的方法，被精确设计的可用性测试如果是基于合理的研究问题，在产品发展生命周期内的正确时间施测，它将是发现产品潜在问题并解决问题的可靠方法。它可以大大降低发布不稳定或无法学习的产品所带来的风险。在几乎任何情况下，进行测试好过不进行测试，这也是本书暗含的主旨。
版权说明： 转载时，必须在文章中注明：本文转载自爱奇艺高级设计经理晓生的博客或微博