可用性测试可以帮助我们区分设计思维（为用户而设计）和沉迷于产品外在特点的差异。
在这篇文章中，我们总结了六个步骤去进行一个有见地的可用性测试：
1、定义目标
2、选择测试（类型、方式、测试用户？）
3、创建用户任务
4、撰写研究计划
5、进行测试
6、拟定一份快速报告
让我们开始吧。
1、定义目标
任何一个可用性测试的第一步，都是确定你预期的目标。目标可以是非常广泛的，例如：
对我们的用户来说，哪种付款方式是最直观的？
目标也可以是很具体的，例如：
哪种表单设计样式能最大限度的提高电商的下单量？
当然，关于你的产品你会有很多的问题，并且这样的好奇心是很棒的。不过，在这个时候要铭记限制每个测试在相关度最高的问题上。每个测试都会有一个重要的焦点导向最精确的结果。如果你测试的目标越多，那么犯错的可能性也会越高。
David Sherman mentions in his article on usability testing ，这些问题的答案，会是测试的一些前提假设，你也可以预留出一些时间，为你和你的团队自己做一些假设，然后尝试着自己去回答这些目标问题。
2、选择正确的测试
这个要讨论的不是哪种测试会起作用，而是根据具体的需求哪一种会起作用。
在这篇免费的guide to usability testing，我们基于Christian Rohrer’s 的 fantastic article将测试分为了四类：
Scripted－这类测试基于指令组分析用户与产品之间的互动。针对特定目标和个体因素的问题。（树测试、走廊可用性测试、基准测试）
Decontextualized－适合于初步的用户测试和角色研究，这些测试不一定涉及到产品，但是会分析更广义和理论性的主题，针对的是一些创意构成和广泛意见的问题。（用户访谈、调查、卡片分类）
Natural(or near-natural)－通过在用户自己的环境中分析他们，这些测试检查用户如何表现，并且在有限的成本内精确地找准用户的情感。（字段／日记研究、A/B测试、首次点击测试、beta测试）
Hybrid－这些实验测试方法放弃了传统方法转向采用无与伦比的样式在用户的意识下。（参与设计、快速接触记忆测试，形容词卡）
一旦你决定了测试类型将要开始进行，你应该写一个简单的描述告知你的团队。如果你打算通过一份快速的规划文档来概述你的策略，那将会更有用。
3、创建你的用户任务
在测试期间你给用户的所有－包括内容和问题，以及措辞－都会影响到他们的反应，这个任务可以是主观的或者客观的，你的测试应该正确地融合两者：
客观的－一个客观的任务会提供一个小房间给用户做解释用，用户会被给到一个明确定义成功或者失败的问题（找到一个可以容纳12人的场所）这个会带来定量且准确的结果。
主观的－相比之下，一个主观的任务可以被多种方法完成。这些事“沙盒”风格的任务。（“你的朋友们正在谈论Optimal Workshop,但是你之前从没用过它，去了解它是怎样工作的”）这些提供定性的和有时也会意想不到的结果。
至于措辞，应该注意避免偏见。一个错误的单词就可能会倾斜最终的结果。
举个例子，如果你想要找到用户最自然浏览你的网店的方式，写一个任务像“圣诞节前十天，你需要为你的母亲寻找一件礼物”，就可能会引导用户去使用搜索功能，而不是像正常的窗口点击那样的方法。
4、撰写研究计划
改编自Tomer Sharon’s One-Pager(极其有用且轻量)，我们使用在UXPin的研究计划文档是一份包含了所有必要测试细节的正式文稿。如果你想交付给你的团队一份一页的精致文档，那么建议你去鼓励他们看一看它。
在保证简洁的同时，你至少还应该涵盖这七个部分：
背景－在一个单独的段落，描述引出这次研究的原因和事件。
目标－用一两句话（或编号），总结研究希望完成什么任务。目标的短语应该简洁客观。不应该是“测试用户是否喜欢我们新的结账流程”，而是“测试新的结账流程如何影响首次用户转化”。
问题－列出5-7个你想要回答研究的问题。
策略－什么地点，什么时间和这个测试将被怎样运作。解释你为什么选择这个特殊的测试方法。
参与者－形容你正在研究的用户类型特点，包括他们的行为特征，你也可以附加角色的更多特征获得更多信息。
时间轴－记录什么时间开始招募测试，什么时间测试开始，什么时间产出结果。
测试脚本－如果你的脚本准备好了，那么把它也放进去。
去看看 Sharon’s sample One-Pager 它应该是什么样的。
鼓励你的团队成员去给一些建议以便测试的结果对每个人都很有帮助。找到他们也想要答案的问题。
5、进行测试
在从团队得到反馈之后，你准备好了真正开始进行测试，这涉及到招募合适的参与者，时间调度安排，和写一份实际的测试文档。
Jeff Sauro,Measuring Usability LLC的创始人，列举了七种用户招募的方法，包括在线工具。通过我们的经验，我们发现走廊测试和像UserTesting的工具非常有用。
至于在实际测试时你的角色，有时你必须在在场主持活动（适当约束）和让用户自己进行之间（不加约束）选择。此外，你还可以选择是在现场进行测试还是远程进行。
不加约束的－不加约束的测试会更便宜，快速，更简单地招募用户和安排时间。而且也移除了主持人的影响，引导了一个更自然和少偏见的研究结果。缺点是，没有机会对用户进行追问，不能够引导那些走入误区的用户走回正确的方向。
适当约束的－有主持会更加昂贵，而且需要更多的精力去组织，适当约束的测试让你能够去引导用户，有利有弊。约束测试被推荐用在那些粗糙的原型上（bugs和可用性风险更高）或是特别复杂的原型上（用户可能需要一些说明解释）。
尽管每个测试都有不同的品质和最好的实践，下面是一些通用的建议：
让用户舒适－提醒他们是在测试产品，而不是功能。一个测试脚本能够在每个测试开始的时候帮助你确保发现一些让人安心的点。
避免干扰－这为了避免偏见，和那些你没有预测的行为泄露给用户。最好的见解通常来自当用户不参与产品的设计。注意变通方法，让他们激励功能改进。
会话纪录－这是在之后诠释结果时候的可靠参考依据，如果你通过UXPin来测试，你还可以记录面部的反应，点击，和所有的音频资料。
合作－为了稍后的快速比较，Tom Sharon建创建议创建一个彩虹电子表允许每个人记录他们自己的诠释。我们在Yelp的重设计过程中用了他的电子表格，发现它对设计师和共享者们汇总结果非常有帮助。图片来源：Based onexercise suggested by Tomer Sharon
6、草拟一份快速报告
可用性报告是和团队分享结果的一种方法，以便每个人都能在同一页上。
为了更好的整理和让结果更容易获得，我们建议建立一个一般的云盘。
当你写报告的时候，将下面几点牢记于心：
避免含糊－提及到“用户不能买合适的产品”不是很有帮助因为是有多因素的影响。可能是结帐流程太麻烦，或是产品列表浏览起来很糟糕。试着从交互／视觉上对这些问题现象进行解释（如混乱布局，结帐流程和步骤太多等）。
问题优先－不管你发现了多少问题，人们都必须知道哪个是最重要的。我们建议分类报告（例如导航问题，布局问题等），然后根据重要程度来添加颜色标签（低／中／高）。列下每一个问题，但是要合乎情理。例如，不要说如果结账过程没有意义，一个红色的CTA按钮导致了很差的转换率。
包括建议－不要包含任何的高保真原型和模型在可用性报告里，但是建议一些改进。补充书面建议，我们的UX研究员 Ben Kim通常链接到低保证的线框图或原型上。
可用性报告应该是一个文件夹，而不是单个文件。不要忘了包括这些东西：
正式的可用性报告
支持图表、图形和数据
以前的测试文档（用户被问到的问题清单）
音频视频资料
文档只是一个起点。安排后续的会议和团队一起检查可用性报告和相关数据，讨论问题和提出建议。
结语
不要等到项目结束时进行可用性测试。一旦你有了低保真的原型，开始测试。有效数据越少，灵感越多。早测试，常测试，以便在太晚之前，你可以真的将结果用上。
