usability.de 分享原型可用性测试的六大常见错误与规避建议

2020年9月21日

我们的建议始终如一：尽早进行测试。针对早期原型或粗略想法的用户反馈，有助于避免后期出现非常繁琐的修改和调整。然而，存在一些错误，即使在创建原型阶段也会对测试结果产生负面影响。我们希望分享我们在原型设计领域15年的经验，并列出应当注意的最重要几点。

1. 为大多数用户而非边缘情况（Edge Case）创建原型。

我们时不时会看到一些与用户不匹配的原型。要么是因为它们仅反映了边缘情况，即应用中最多只影响20%用户的部分；要么是因为其中展示的内容与为可用性测试所确定的目标群体细分无关（例如，尽管只邀请了男性参与，却展示了化妆品内容）。

这就导致在原型用于可用性测试之前，必须（有时需要多次）对原型进行反复迭代。这会导致项目中宝贵的时间流失。

我们的建议：应尽可能早地让 UX 研究员参与到原型的创建中。产品的核心用例和目标群体应共同定义，以便在原型中真实地反映这些要素。

2. 不要构建单行道。

我们经常收到这样的原型，它们实际上只允许一条“正确”的路径，即仅链接该路径。结果就会变成：所有参与者都毫无问题地找到了产品 xy。但是，当成千上万的其他链接和导航元素争夺注意力且一切确实可点击时，以后也会是这样吗？

可用性测试的参与者很快就能注意到这一点。他们会自动开始寻找鼠标指针变为手形的地方，从而找到正确的路径。如果可用性测试本应提供关于导航和定位的见解，那就特别令人遗憾了。如果未禁用原型中可点击元素的高亮显示，并且每次点击时所有可点击元素都会发光，那么这个问题甚至会更严重。

我们的建议：应在可用性测试前禁用原型中可点击元素的热点高亮显示。此外，应尽可能多地设置交互功能。当然，在开发初期并非所有内容都已就绪。这时一个小技巧会有帮助：通过设置盲链接（改变鼠标指针形状，但没有实际链接），使最终产品中所有可点击的元素看起来具有交互性。

3. 内容为王。

在设计或重新设计应用程序时，内容往往是那个被忽视的继子。如果重点主要放在花哨的设计上，人们总会听到这样的话：“内容最后再放。”但对于网站用户来说，内容是 King。他们不会区分网站的设计和内容的区别。对他们而言，这就是您的应用，如果它不包含内容，那就缺少了一个决定性的部分。因此，当原型的内容仅由占位符文本组成时，原型往往难以发挥作用。这也意味着在可用性测试中错失了获取初步内容反馈的机会。

我们的建议：内容团队应理想地从原型创建之初就参与进来。应避免使用 Lorem Ipsum 文本和其他占位符。相反，原型应尽可能包含真实的内容。这里关注的不是最终的措辞，而是有机会获取关于内容及其放置位置的初步用户反馈。

带有占位元素及内容的原型展示。

4. 提供导向和上下文。

有时原型会将测试用户直接扔进应用的某个位置。当需要测试特定功能或独立区域时，情况往往如此。例如，测试参与者可能正处于其用户账户中间，现在需要理解自己身处哪个应用、名叫 Michael Müller，并且已经有 50 个好友和 3 条未读消息。这通常效果不佳，因为测试参与者没有得到良好的引导，因此他们的参与度往往不高。

我们的建议：即使是原型也应始终提供导向和上下文。用户必须了解这是哪个应用，以及他是如何到达该应用中相应位置的。这可以通过多种方式实现，例如通过截图模拟之前的步骤，或者在测试场景前提供一个较长的介绍。

5. 不要预设交互可能性。

在原型中，表单字段经常已经预填了理想数据。但这却错失了获取关于表单标签和特性以及单个字段反馈的机会。

我们的建议：为了确定未来的用户是否能够理解并填写表单（或者他们是否认为询问了过多的个人数据），表单字段应为空。理想的情况是，测试参与者实际上也能在原型中填写这些表单。

通过交互可以发现，例如许多用户会直观地将门牌号写在街道名称后面，而不是将其填入新的字段中。

6. 不要寻找“完美”的工具。

当然，各个原型工具之间存在差异。但关于此的讨论往往占据大量篇幅，从我们的角度来看，有时甚至过多。因为最终重要的是，原型具备一定的功能性，能够映射应用的主要用例，并且符合受邀的目标群体（例如，对于目标群体而言真正相关的产品或内容）。

我们的建议：最后，所有原型工具都有其优缺点。但如今，大多数工具都能满足可用性测试的需求。

以下是常见原型工具的概览：

如果您在原型设计中遵循我们的建议，将自动提高测试结果以及基于这些结果的（设计）决策的质量和可靠性。

作为全方位服务的 UX 服务商，我们专注于设计和实施用户友好的原型。我们的用户体验设计师乐意协助您规划和创建不同细节程度和复杂度的功能性原型。

在此了解更多关于原型设计的信息。
我们很乐意就您的项目为您提供免费咨询。期待您的垂询！