我从可用性测试中学到的五件事

我第一次参与的几个可用性测试就是市场人员喜欢做的：主持人坐一边，另外五六个人坐在另一边。而我们就应该坐在另一边做记录，在观察用户表现的同时还要经常和他们开玩笑互动。

观察用户的表现很有趣。但有时完全没用。所有的可用性测试都有偏差，更严重的是，即使你给用户付了钱，你就能保证他们的表现是真实的？所以，你的目标是要尽可能限制这个偏差。在这个过程中我们可以学到很多东西，这就是为什么我们**继续测试，无论有没有偏差。

最好的方法是模拟用户使用应用程序时的环境。比如，如果用户坐着，我不**对其做移动地图应用的测试，因为用户一般都是在走路寻找某个地方时才使用地图。我已经对手持电话的用户做过了测试，测试指标是“他们找到目的地了吗？”

对于其它应用，我**在办公桌上和用户做可用性测试。这样可以更好地理解用户日常生活中使用应用的环境。

我和客户最近做了一个测试，用户日常生活中必须与3-4 个应用进行交互。我可以从中了解用户使用的其它应用（比如 Salesforce、Excel、Outlook 以及其它六个浏览器窗口）。我一边看用户与软件的交互，一边做笔记，并列出与应用相关的工作流程建议表，而不是我最初设计的那样。

看他们做什么而不是说什么

很多人都喜欢帮助别人，所以他们**积极地面对你摆在他们面前的问题，这种情况被称为社****许（Social Desirability）。我进行过几次可用性测试，用户都表达他们如何喜欢这款应用。他们**说：“我喜欢它！我完全**使用它。”

很明显，他们并不知道怎么使用这个应用。

当你称其为“可用性测试”时，终端用户可能**简单地认为是对知识的测试，而不是 app 的可用性测试。他们不想别人认为他们很愚蠢，所以他们**说他们有多了解如何使用网站或他们很专注这个工作，这样他们就不**犯错。很多人都喜欢帮忙，所以他们对你摆在他们面前的问题非常积极。仅凭这一点，我可能就有一系列内容可以写。

看他们做的，以及他们如何对屏幕上的应用做出反应，并试着和他们的评论联系起来。有时，我记录鼠标的运动就可以精确地知道用户在干什么，但是我通常只**粗略的记录一下交互方面。

让用户说话比你想象的要容易

在 Jobvite 工作时，我采访过很多招聘专员和招聘经理。没有比从招聘专员那里更容易得到反馈的了。

你问他们三个问题，他们就**告诉你所有事情。他们中午吃的什么，采访了谁，喜不喜欢他们的工作等等。更重要的是，如果引导他们，他们**告诉你如何使用技术。招聘专员每天**说很多，但是没有人**认真听他们的话。他们一旦有机**，**很乐意谈。

他们和像大多数人一样，希望有人倾听，因为我们是一个开放的社**。作为设计师和开发者，我们给他们对话的机**，也给我们一个获取真实意见的机**。这并不仅仅因为他们使用你测试的技术，他们的环境也适合。

你需要做的就是问为什么？

这些反馈对设计出伟大的产品非常重要，因为你了解用户的痛点，你可以解决他们的问题。

最好的想法来源于脱稿流程

我看到过这种可用性测试：主持人列举了一系列问题，做笔记，轻易获取毫无价值的反馈，甚至可能都不知道谈了些什么。

我也见过这种可用性测试：主持人只列举了几个简短的问题，让用户按照几个重要的观点来谈，顺着产品变化的反馈来走。

最好的情况是有一个宽松的剧本，这样你可以从自己的角度进行思考。如果你学**如何做，那么测试就**有更多偶然的问题解决办法。这时真正价值的内容就出现了，因为你可以深入探讨一个话题，并获取用户的真实想法。

不需要用一个完整的原型来测试概念

我已经记不清有多少次我使用半成品原型来测试想法了。在进行测试前，我**告诉用户这是测试试验中的想法。我也**告诉他们这是个原型，所以有些东西可能不凑效。由于原型通常是高度逼真的，以致用户**忘了这是测试。

我给他们发送一个链接。他们一点击就**崩溃。

为什么**崩溃？

因为这是一个原型，但它并不完整。我们正在尝试其它方法。所以，当你点击这个链接，你认为应该发生什么情况？你能一步一步地解释出来吗？

大多数情况下，他们**描述下一步**怎么做。当然，如果刚好在用户描述每个步骤的时候，你能确定他们的真实想法，那就很酷了。更好的是，他们可能**给你提供一个你从来没想到过的想法。

可用性测试并不仅仅是测试你当前的设计，它可以利用用户的集体体验来改善它。这些想法不仅能验证你现在所做的工作，并且还可能进入你的产品线路中。

你向用户学习了吗？

抓紧时间。

多问为什么。

倾听。

这并不难，但是你需要坚持每天做，无论什么时候。你所学到的可能出乎你的意料。