大的互联网巨头的设计部门一般都包含有专业的用户研究员，用以研究和评估用户的行为。而对于资源有限的公司或团队，设计师本身既需要完成设计，同时又需要进行一定的可用性测试，从而确定自己的设计是否正确。

《Don't make me think》的作者Steve Krug 在《妙手回春：网站可用性测试及优化指南》当中介绍的发声思考方式是一种非常简洁高效的可用性测试方法。 今天带来一篇更加深入介绍发声思考的译文。相信不论是打算做发声思考可用性测试的设计师，还是曾经使用过这种方法的设计师们，看完之后都会有新的收获。

插图源自：http://www.ipo.titech.ac.jp/english/ics/page14/page14.html

原文请见：http://uxmatters.com/mt/archives/2012/03/talking-out-loud-is-not-the-same-as-thinking-aloud.php

--------------------------翻译正文---------------------------------------

在Jakob Nielsen近期的一个讨论专栏“发声思考是首选的可用性工具”中，发声思考被认为是非常有效的可用性测试方法。对此，我毫无异议，然而，很多人错误的把发声讲述他们正在完成的任务和出声提出设计意见混做一谈。事实上，前者（发声思考）非常宝贵，而后者（出声提出设计意见）非常一般，甚至有可能是有害的。

以下是一些通常你希望从一个发声思考者口中听到的例子：

“我打算操作这个....”

"看到这个界面，我想它的这部分是用来..."

”嗯....这个和我想象中的不太一样，我以为接下来会是....“

“这比我预期中的时间长了很多...”

总之，通过发声思考，你希望了解的是用户怎样理解他手头需要完成的这个任务，以及他如何将界面与任务对应起来。

而你不需要听到类似这些评论：

”我觉得背景颜色应该是蓝色的“

”我觉得其他用户肯定没办法理解这部分...“

“如果我设计，我会把这部分放在那边”

一方面，类似的评论并没办法对当前问题提供实际的启发和引导，只不过是在已经很多的意见当中又增加了一些。往好里说，这是一种干扰；往糟糕处说，它会误导开发者们做出错误的决定，因为他们会认为这是“用户告诉我们他们需要的”。在第一个例子中，那位指定背景颜色应该是蓝色的用户有视觉设计的背景或专业知识么？事实上，我很惊讶于有多少情况下，人们愿意推翻一同工作的经过良好教育培训的专业视觉设计师而仅仅是因为一名会计师（非专业设计者）说他们喜欢蓝色。

那么，如何才能从用户那里得到对你有帮助的反馈呢？依照我的经验，有两种技巧可以提升发声思考的质量：

1. 在可用性测试开始之前，提供一些有指导性的练习。

2. 在可用性测试过程中使用情境控制方法--特别是鼓励和拒止方式。

指导性练习

在我跟被试用户开始正式测试之前，我会先解释发声思考的方式，之后邀请被试来使用发声思考数出他们家里的窗户数量。我告诉被试“我并不是真的关心你家有多少窗户，我关心的是你怎样完成告诉我你家窗户数量的方式方法。”有些被试会很安静的坐在那里一阵，然后说“12个窗户”。我就会指出我没有了解到他是怎样得到12这个结果的。我会要求他们再来一次，努力告诉我得到这个数字的过程。然后他们会试着告诉我：“在我家厨房，水槽对面有一扇窗户，在客厅里有三扇，小房间沙发背后有一面....” 这个时候我会打断他们，“好了，现在我对你回答这个问题的方法有一定了解了：你想象自己站在房间中，然后从厨房开始，一间一间屋子的数窗子的数量。”通常情况下，被试开始在这时了解你的意图，他们可能会说“哦！我明白了！你希望我把自己考虑的过程说出来。”

另一条有用的提示是：先跟被试练习一些简短的任务，如果某些被试在表达思考过程中存在困难，你仍然有机会在完成复杂任务的发声思考前来帮助他们。

 

情境控制

在可用性测试过程中，我会采用B.F. Skinner’s的两种情境控制方法：鼓励与拒止。我们大多数人都很熟悉鼓励方法，但是拒止方法可能相对较新--至少你可能之前从来没有使用来管理你的被试们。

 

鼓励

鼓励是指通过夸赞和肯定来激励用户继续进行一系列正确的行为。例如，当引导者说“你做的很好”，用户通常会进一步做更多引导者刚才肯定的行为和操作。

测试引导者应当只在被试给你需要的数据时给予鼓励。不要在用户给你设计意见时给他们鼓励。

例如，如果一个用户告诉我：“这里的操作提示非常难懂，”我会首先确定难懂的地方在哪里，可能是文字描述不清楚，有些模棱两可。之后我通常会给予鼓励“嗯，很感谢你告诉我们，这很有帮助，我们就需要这样的发现。”

在产品设计的跟用户想象的不一样时，我也会这样做。“所以当你输入manger时，你希望软件能够自动的帮你矫正，修改为manager，因为manger在这里根本不合任务情境对么？嗯，这点对我们很有帮助”请注意，我没有说”这是一个好的建议“。为什么不这样说？一方面，在这间会议室里，还有一大群开发工程师们，他们知道实现这样一种拼写检查是根本不可能实现的--至少不可能在不想陷入繁冗开发的当前这个产品中。如果我说“这是一个好的建议”，那么，我就会在这些开发工程师们当中失去可信度。之后他们就会开始对我从这个用户这里收集到的其他建议和问题产生不信任。

另一个更重要的方面是，如果我开始鼓励被试给出设计建议。我增强了被试的什么行为？提设计建议！但我不是邀请这个用户来给我设计意见的，我希望看到的是一个真正的用户如何理解我设计的界面以及利用它完成指定任务的过程。

 

拒止

我想讨论的另一种方法是“拒止”。当遇到我不需要的反馈时，我如何处理呢？尤其是那些视觉样式的偏好类型的设计建议？我什么都不做。这就是拒止：对于不想要的行为不给予任何响应和反馈。一种常见的拒止是：当孩子很吵闹时，不予响应，给他安静的一段时间，这并不是要惩罚孩子，而是让孩子从吵闹的状态中离开。

通常来说，经过鼓励的行为通常会持续进行，而那些没有得到鼓励和反馈的行为则最终会消失。因此，在可用性测试中会常常见到类似这样：

被试：我没有看到“提交”按钮。

我：所以在你完成了表单之后你不知道该怎样继续了，因为你没有找到一个“提交”按钮对么。好的，多谢，这是一个非常有用的信息。

被试：是这样的，我觉得应该把这个按钮做成红色，好让我能够看到它。

我：下面一个问题，我们会要求你完成....

看到了么？我第一个反馈是非常积极肯定的，我鼓励了用户，因为他帮助我发现了那个“提交”按钮并没有让用户注意到。

然而，我接下来的反馈是没有理会被试给我的设计建议而跳过进入第二个任务环节。通过被试的第一个描述，我们知道了我们的设计可能让用户找不到“提交”按钮。我会让我们受过良好培训和教育的视觉设计师来解决这个问题。

我知道有很多人都希望能够参加到设计讨论当中。但是，一但你让所有人都进入设计讨论的过程中，被试们就不会再继续讲述那些能够帮助发现问题的使用的过程了，转而，他们会开始给你设计的解决方案，他们会认为你邀请他们来是想听他们的设计意见。为什么会发生这样的情况呢？因为你不断的询问设计意见帮助他们确信了这种印象。就像我在最开始的例子当中一样，被试告诉我“12扇窗户”，我知道了他的答案，但是没得到任何用户怎么算出来12这个结果的信息。再次强调，我们从不缺乏解决问题的专家们；我们缺乏的是用户对于问题的理解。

 

结论

让人们进行发声思考使得人们将那些沉默的行为--诸如理解，计划，反映转化为明确的，能够被你观察到和分析的数据和行为。由于这个原因，发声思考在可用性测试当中是非常宝贵的。但是如果一个发声思考的被试认为你邀请他们来是征询他们对于设计的意见和建议时，他们就不会继续分享那些对你有重要启发的用户沉默的内部心理行为，转而会给你讲述他们认为怎样设计，而不是他们怎样使用。他们会变成那些告诉你我家有12面窗户的用户。

有一些客户有时候过分的期望用户给予的设计建议，因为他们认为这是真实用户给出的参考。事实上，这与我曾经参加过的一个客户评估一样，我们的客户依照一个小范围的统计得出：“我们软件的安装时间比上一版本降低了12%.我们使得我们的软件更容易安装了！”对此，我只能说，也许是更容易了，也许不是。在可用性测试中，我们应当关注的是用户如何数出自家的窗户数量。定量的数据越少，研究者就越容易让用户关注于定性的行为数据。

最后，邀请你的客户和被试进行发声思考，并且在你得到有用的问题反馈时给予他们鼓励！只有这样你才能从用户的角度发现问题，这才是可用性测试的精髓所在。

 

原创翻译，转载请注明出处：http://viosdesign.com/2013/01/thinking_aloud_usability_test/