可用性不可能随意地杜撰编造，它贯穿了整个产品设计过程，需要不断地被开发和提炼。如果你想要拥有最好的产品，你必须从原型设计起便开始考虑真实用户的使用场景。

制作原型已经是一项非常繁复的工作了，我们为什么还坚持在初期阶段把可用性测试纳入其中呢？这是因为，人们不喜欢难用的产品，除非你的原型是可用的。

毋庸置疑，你设计的产品是给真实的人所使用的，因此也应该在真实的用户身上进行测试。制作原型的目的就是试验测试，所以只有使用真实用户测试才有意义。

基于这些，下面让我们看看如何将可用性贯穿设计/制作原型过程，如何在原型设计前进行可用性测试，同时我们也提供了一些原型可用性测试的建议。

原型设计前的可用性测试

可用性测试并非一定从原型开始——事实上，只要你手头已有一些资源，你就应该尽快开展可用性测试。在这个阶段，可用性测试虽然主要偏概念，但是能够帮助你确定原型的导航方式和信息结构。最常见的原型设计前可用性测试方法包括：

1. 卡片分类法(Card Sorting)

这种方法简单而明确，能够帮助你获得关于产品信息结构的用户偏好。将你产品的所有元素都写在卡片上，然后要求用户在已设定的类型下（“封闭式”）或是根据用户自身感受（“开放式”）进行卡片排序。

2. 树形测试法(Tree Testing)

作为卡片分类法的“姊妹测试”，树形测试法能够评估现有信息结构的有效性。将你的网站/app简单基本化，把主要的信息结构呈现给用户，并要求用户点击以完成设定的任务。你需要记录用户是否选择了正确的路径，如果不是，需要记录干扰用户点击正确路径的原因。

3. 访谈法(Interviews)

有时候理解用户的最佳方法就是直接询问用户。这听起来很简单，然而要真正把握用户访谈中的微妙和策略仍是非常困难的。

越早解决问题总是好的，这些初步的测试能够确保在原型设计之前原型的概念是正确的。

正确的用户和正确的用户任务

尽管可用性测试方法不尽相同，但是毋庸置疑的是，无论哪种方法都需要用户，大部分方法也都涉及到用户任务。鉴于用户和用户任务是所有可用性测试中最为关键的两个因素，下面我们将简要地解释如何完美处理这两个因素。

1. 招募用户

在建立典型用户角色之后，现在你应该对目标用户有一个清晰的认识，同时也能帮助你基于用户行为进行用户分群。事实上，你无须为用户的人口统计数据而纠结——最大的用户区别因素往往是用户是否了解他们所处的领域/行业、是否拥有经验，而非性别、年龄或是地理位置。

知道招募谁仅仅是第一步，更棘手的是如何寻找并成功招募到这些用户。Jeff Sauro提炼了如何找到用户测试的理想用户的7种最佳方法。

2. 确定用户任务

用户任务决定了用户在测试期间做什么，因此也决定了你究竟是在测试哪一个可用性因素。Ubuntu的可用性测试专家赵婷婷提出了在设计用户任务时需要注意的一些区别，主要包括了两大区别：

a) 直接任务 vs 场景任务：直接任务是准确命令的（如，“在网站上搜索一份炭火烤鸡配方”），场景任务则是在一个特定场景下进行的（“你现在想为一些老朋友举办一场宴会，你需要一份炭火烤鸡配方”）。记住，通常情况下优先选择场景任务；只有当你在测试技术数据时，直接任务才比场景任务更胜一筹。

b) 封闭式任务 vs 开放式任务：封闭式任务明确定义了完成任务的标准；相比而言，开放式任务则允许用户以多种方式完成任务。封闭式任务一般用以测试特定的功能，开放式任务更适用于了解用户是怎么想的。例如，“这个周末你的朋友将举办一场生日派对，请找一个能容纳15人的派对场所”属于封闭式任务，“你听到你的同事们在讨论iWatch，你希望能够进一步地了解iWatch”则属于开放式任务。

原型可用性测试的一般性建议

考虑到原型必然是“不完整的”……用户会有各种疑问……测试主持人将不得不回答这些疑问……

第一个问题也是最常被问的问题是，可用性测试是否需要主持人。尽管无主持人的可用性测试的确拥有许多优势，对于原型测试，我们仍建议需要设置一名主持人。考虑到原型必然是“不完整”的，测试主持人不得不回答用户对界面的各种疑问。

可用性测试的另一个常见错误是当用户碰到困难时停止或者改变测试。记住，可用性测试的目的是为了发现并解决问题，因此用户碰到困难恰恰表明这是一次成功的测试。例如，如果用户在尚未在原型中开发的路径迷失，你可以询问他们“为什么选择这条路径”以及“你认为这条路径应该能实现什么”。针对失败的用户任务询问的后续问题可能能够获得比“完美地完成一次用户任务”更有价值的反馈。 

不同的原型保真度

虽然有些人认为应该以粗糙的原型开始测试，有些人则主张使用更高保真度的原型进行测试，这里我们认为最好的方法应该是尽可能地对每一种保真度原型进行测试。Enlighten的高级信息架构师Chris Farnum阐述了每种保真度原型的利弊。下面我们也将会提到，使用低保真原型能够更好地测试概念，而高保真度原型则更适合于测试复杂的交互方式。

最好的方法是尽可能地对每一种保真度原型进行测试。

1. 低保真度

通常我们可以在开发的早期阶段使用低保真原型（包括纸原型）进行可用性测试，然而低保真原型并不适合后期的可用性测试。另外，低保真原型能够让用户提出更多诚实的批评——因为用户清楚地知道，这只是一个正在进行中的项目。

然而，当后期我们需要测试复杂功能时，受保真度的限制，低保真原型无法提供帮助。纸原型尤其如此，因为你需要一个“人机”来操控所有部分，特别是当你需要添加菜单、交互方式、页面和元素时会变得非常困难。

2. 高保真度

使用高保真原型进行可用性测试能够让用户对“最终产品是什么样的”有一个接近真实的体验。高保真原型非常适合用来测试复杂的交互方式，以及测试在前几轮测试中发现的可用性问题的解决方案。然而，相较于低保真原型，制作高保真原型的成本非常昂贵。

3. 中保真度

是否在高保真和低保真之间犹豫不决？当你需要平衡保真度和制作成本时，中保真原型是你的最佳选择。如果你只打算进行一轮可用性测试，请使用中保真原型。

4条内容指南建议

当你刚开始制作原型时，必要的时候可以忽略小的细节，这也是通常推荐的方法。然而在测试原型时，你必须确保补上那些低保真原型可能忽视的细节。根据我们的经验，以下是当你在准备原型测试时的4条极为有用的建议：

1. 避免lorem ipsum

毫无意义的lorem ipsum文本容易让用户分心、困惑，也不能完全表达出你的产品信息。 

2. 使用通俗的名称

使用傻傻的名字或者名人的名字可能能给测试带来更多的乐趣，但是乐趣并不是测试的关键。任何干扰都会影响测试结果，所以尽可能地使用通俗的真实名字。 

3. 不能出现图像/图标占位符

在制作线框图时你可以使用图像/图标占位符，但在可用性测试时不能出现这些占位符。图片和图标在用户体验中起到很大作用，所以在测试时必须用真实的图片/图标加以替换，除非这些图片仅仅是出于装饰目的，和理解用户界面没有关系。 

4. 使用真实的数据

千万不要用XXX或是随意地填充诸如电话号码/地址等数据——这些都会分散用户注意。使用真实可信的数据能够确保用户测试结果的准确性。 

参加测试的用户很有可能会专注于那些你认为可以忽略不计的细节，所以请永远保持小心谨慎，尽可能地减少干扰用户的因素，从而获得干净的测试数据结果。

原文链接：http://www.webdesignerdepot.com/2015/02/how-to-test-the-usability-of-prototypes-like-a-pro/