【译文】可用性测试之发声思考
原文链接： 原文有删截
-----正文分割线-------
定义发声思考测试
定义：在一个发声思考测试中，测试的参与者在执行任务行为时实时的说出自己脑子中所想的内容
这看上去是一个很简单的要求，但是在实际过程中要求一个测试者不停地说出自己所想是非常困难的，所以测试的实施者必须不断的提醒测试者。
进行一个基本的发声思考可用性测试，只需要做3件事情
- 招募代表性用户
- 让他们执行有代表性的任务
- 闭上嘴听测试用户说
发声的好处
首先这个方法有一大堆优势。其中最重要的是，发声为想法提供了一个可见的窗口，透过窗口你可以发现用户到底是如何使用和看待你的设计的。特别的，你可以发现他们产生误解的地方，这些往往是需要进行重新设计的，所有引起误解的元素都必须改变。更重要的是，你可以从中发现为什么用户会产生误解，为什么其他的设计方式会更易用。
发声的好处还有
- 低花费。不需要特殊的仪器，只需要你坐在测试对象旁边记录他所说的话。收集到足够多数量的用户测试信息可能会花费一整天的时间，但这一定是值得的
- 可信度高。大多数的实验者都缺乏经验所以大多数时候测试都不能够按照最正确的方式进行。但是除非你严重干涉误导测试者，即使在不标准的测试中你依然能够获得大量有价值的发现。相比之下，定量的可用性研究对于方法的精确度要求的更加严格，很小的错误也可能导致研究结果出现巨大偏差。定量的研究往往也花费更高。
- 灵活度高。在开发的任意时期你都可以进行这样的测试，从纸上的原型到已经成型的原型。发声思考特别适合敏捷式的开发模式。你可以运用这种方法测试任意形式的用户界面，虽然用发声的方式测试声音交互界面有点奇怪，但是你可以参考这篇文章里关于进行有实力测试障碍的人的测试。不论是网站，软件，局域网，消费类产品，企业级软件，移动设计，发声测试都可以运用，因为他只依赖于可以思考的用户
- 有说服力。最老练的开发者，傲慢的设计师，吝啬的总经理在直接面对消费者的时候态度都会变得温和。让他们坐下来听听在发声测试中用户的想法并不会花费他们太多的时间，并且有可能促使他们重视可用性。
- 简单易懂。
发声思考的问题
花费低和不容易出错是定性研究方法诸如发声思考的巨大优势。但他们不好的一面是除非你进行的是一个巨大昂贵的实验，否则是不能形成定量数据的。当然你可以选择做一个巨大昂贵的实验，但是我的建议是这些精力和经费投资在更多的设计迭代过程中更值得。
其他问题
- 不自然。除非测试者是个怪人，大多数普通人不会坐在那里自言自语一整天。所以想要让测试者在测试过程中保持自言自语其实是一个比较困难的过程。幸运的是来参加测试的人一般都会比较积极的配合，以至于有时可能忘记自己仅仅是在进行一项测试。
- 想法过滤。测试者被要求说出他们脑中呈现的第一印象，而不是说出经过了思考之后的分析结果。但是与此同时，大多数人希望自己表现的像个聪明人，于是他们更倾向于在说出自己所想之前先思考一番。千万不要陷入了这个陷阱，获得测试用户最原始的想法是非常重要的。所以一般情况下，实验者必须不断的提醒用户不断的说。
- 误导用户行为。指导和解释说明在测试过程中是必要的，但假如是一个不专业的实验者来进行，那么他给予的信息很可能会改变用户原本的行为。有误导存在的情况下，用户的行为是没有代表性的，更无法提供设计依据。至少，你必须能够识别出在哪些测试中用户的行为是被误导了的，作废这些观测结果。最糟糕的情况就是你不知道自己在哪些地方做错了，这样你提供给设计团队的意见很有可能就是错误的
- 不一定通用。只要你同时使用其他的方法，不通用事实上并不是一个真正的缺点。发声思考可以在大多数情况下使用，但也并非全部情况下通用。一旦你在可用性测试这方面有了一定的经验，你会有其他很多测试方法可以选择
不要因为这些问题就退缩，如果你还没有使用过这个方法，你可以现在就为自己正在进行的设计项目进行一次。这个方法是如此的简单易行，每周一次都是完全可行的。所以如果你这一周犯了错误，下一周你一定可以做的更好。
------正文分割线------
这篇文章是一个系列的文章的第一篇，这个系列还有很多其他有趣的文章，可以在原文地址找到他们的链接
- How Many Test Users in a Usability Study?
- Usability 101: Introduction to Usability
- How to Run a Usability Test with Users Who Are on Your Site Now
- Remote Usability Tests: Moderated and Unmoderated
- Making Usability Findings Actionable: 5 Tips for Writing Better Reports