说说数据分析中的之“用户访谈”

前言：尽管存在诸多缺点，对于探索性的用户研究来说，访谈仍然不失为一种有价值的研究方法。

用户说什么与用户做什么常常是不同的——我曾经无数次地提到过这一点。我甚至写过一篇题为“可用性的第一准则？不要听用户说”的专栏，这一点在今天和9年前一样重要。(最好的可用性方法是非常稳定的，这也是为什么学习有效的方法是一件有着很高的终身投入产出比(ROI)的事情。)

细心的(Observant)读者会抱怨道，在我目前关于反应时(response-time)延误的分析中，我已经打破了我自己设立的原则。在那篇文章中，我报告了一系列我们做的关于作为体验的品牌(Brand as Experience)的概念的访谈研究。为什么我突然开始询问用户他们的想法而不是观察他们实际的行为。

答案就是：访谈事实上是一种合适的用户研究方法——如果你仅仅在它们能够产生有效数据的少数几种情况下使用的话。

访谈不能做什么

在谈到访谈好的一面前，我们首先回顾一下它许多不好的地方。(许多缺点与焦点小组是一样的，后者也在网页设计项目中大量地滥用。)

用户访谈最主要的缺点就是，你不是让用户回忆过去对系统的使用，就是让用户猜测未来会怎么使用。这两种回答方式都是非常不可靠的，并常常具有误导性。

人的记忆是很容易出错的。用户是不可能记住他们如何使用网站的所有细节的。他们常常会编造故事来合理化任何他们记住的或者错误记忆的东西，从而让它们听起来比实际上更合逻辑。

用户是讲求实际的(pragmatic)、具体的(concrete)。如果仅仅是提供给他们一些描述，他们通常很难想象他们会如何使用一项新技术。用户不是设计者，想象一件并不存在的东西是一项稀有能力。

设想用户评论的一个时间轴：只有一个点能够得到有效数据——当前：用户现在正在做的事情。我们应该避免让用户错误地回忆过去或错误地预测未来。

说明书(spec)不起作用的一个理由就是用户(和管理人员)不能告诉你是否一个说明记录了能够解决他们问题的东西。说明书当然写得很好，但存在无数的关于典型用户(user reps)的个案研究发现(sign off on)以重大失败为结局的事情。

这也是为什么敏捷开发( Agile development)和纸上原型(paper prototyping)的方法是有价值的原因。当用户有具体的东西可以与之互动时，你能够很明显地看到你是否是以一种简单和舒适的方式在解决他们的问题。

大部分具体的设计问题不能够通过访谈用户得到答案。以下是一些你不可能从访谈中得到的东西：

购买按钮应该是红的还是橙色的吗？
多个选项是采用下拉菜单好还是采用单选按钮好？
Foo产品线( Foo product line )应该放在信息架构的哪里？
采用三级导航好，还是坚持二级导航好，即使后者意味着更长的菜单？
你应该如何编写帮助信息来最好地教会用户如何正确地使用系统？

当然，你可以询问用户这些问题中的任何一个，但是回答与真实网站的有效设计完全无关。与具体的用户界面元素有关的两难问题只能够通过观察用户与一个具体解决方案的设计如何交互才能得到解决。这样你才能知道在实际的使用中系统运转如何。(或者你可以实施多个方案，然后进行比较)

同理，你不能问“你会使用(未来可能的)特性X吗？”因为用户很难预测他们没有看见的东西。你甚至不能问已经存在的特性这样的问题，“特性Y有多有用？”事实上，在许多研究中，主持人(facilitators)要求用户评价还不存在的具体特性，但只是作为诱饵(ringer)放在访谈中，从而让用户提供大量的反馈。

(The take away如果你不得不问用户有多喜欢你的特性，你要保证包含一些不存在的特性以收集用户的基线态度。)

在一项著名的研究中，微软要求客户在开始使用产品之前指出Office 2007的新特性有哪些。大部分所谓的(requested)新命令事实上已经存在于Office 2003当中了，所以设计团队正确地得出结论：产品的主要问题是现有功能的可发现性(discoverability)。

评价特性的方式就是让人们使用它。当用户使用特性时密切地关注用户的评价。你甚至可以在任务结束后立马要求补充性评价，这时特性在用户的头脑还印象深刻。

访谈可以告诉你的

对于我们的品牌讨论,我们想要知道随着时间的推移如何使用一个网站能够建立对该网站的印象，以及他们对品牌承诺(brand promise)的预期。换句话说，我们对单独页面的设计不敢兴趣——我们已经在用户测试中研究过——但我们想知道用户在使用它之后会有什么想法。这个时候就最好通过询问的方式来获知了。

如果你想知道用户的一般态度或他们对某个问题的看法，访谈也是很有用的。当你获得这一信息后，你就应该设计能够解决这一问题的产品特性(并测试这些特性的原型设计，以保证你的做法是正确的)。

关键事件法(critical incident method)在这些探索性的访谈中非常有用：要求用户回忆他们遇到非常严重的问题或者状况异常良好的特定事例。通常，这些极端事件在用户的头脑中更加生动，能够告诉你一些细节帮助你想到有用的产品特性。

(相反，如果你询问用户他们通常如何完成一个任务，他们常常会描述一个理想的工作流程，而省略了真实使用过程中的许多瑕疵和偏离，不管是在家里还是办公室。好的应用工作流程(good application workflow)的一个决定因素就是避免理想化的情境，并依据用户实际使用的方式设计。)

警惕询问效应(Query Effect)

无论你什么时候询问用户的看法，你都要警惕询问效应：人们能够编造对任何事物的看法；如果你问他们，他们就会这么做。因此你可以要求用户详细地(at great length)评价一些无关紧要的事情，即便这些事情在他们放下他们自己的设备后再也不会想到。
因为“用户不喜欢这样”或者“用户要求这样”而做出巨大的设计改变是危险的。如果你问一些重要的(leading)问题或让回答者产生压力，他们可能会编造一些丝毫(in the slightest)不能反映他们真实喜好看法。

比如，如果你询问用户关于视觉设计的问题，你肯定会得到关于色彩的评价，即使这些对用户来说并不特别重要。另一方面，当用户在使用网站时如果听到他们自发地提到色彩，那这肯定是一个需要考虑的问题。(比如(say)，想这样的评论”Wow，氖蓝色真伤眼睛”，或者更积极一点的陈述比如”佛青色让人舒服、放松”。)

方法整合：资料三角测定(Data Triangulation)

访谈是对其他可用性方法的很好补充。如果你只能使用一种方法，我一般会推荐用户测试。但为什么要将自己局限于一种方法呢？每种方法只需要几天的工作量，所以你可以在最小化预算的条件下综合使用多种方法。

让我们回到促使我写这个专栏的例子上：我们最近关于网站反应时间的研究发现。如果你想某个页面加载、表单处理(forms handling)或者AJAX部件操作的最佳速度，你必须观察用户完成与这些设计相关的典型任务。如果有东西反应太慢，你会记录下用户变得不耐烦、易忘并最终离开网站。但是如果你几周后询问他们，他们不会明确地(specifically)知道是哪个界面元素反应太慢；他们也不会回忆起构成他们注意力持续时间(attention span)的秒数。相反，如果你想知道反应缓慢(sluggish)或迅速(snappy)的网站的品牌影响(我们目前的研究问题)，那么访谈则是合适的。对于这种高阶的问题，你会想知道是什么造成用户在使用网站这么久之后仍在脑海中有如此深刻的印象。

每种方法都有它的优点和缺点。利用每一种方法的优点而不只是利用一种方法能让你获得更丰富的认识。同样，利用一系列其他方法来补充每一种方法，你能够对研究发现完成三角测定，并防止错误的结果(misleading outcomes)。