数据之于用户分析研究.docx

/archives/2050说说数据分析中的之“用户访谈”前言：尽管存在诸多缺点，对于探索性的用户研究来说，访谈仍然不失为一种有价值的研究方法。用户说什么与用户做什么常常是不同的——我曾经无数次地提到过这一点。我甚至写过一篇题为“可用性的第一准则？不要听用户说”的专栏，这一点在今天和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)的预期。换句话说，我们对单独页面的设计不敢兴趣——我们已经在用户测试中研究过——但我们想知道用户在使用它之后会有什么想法。这个时候就最好通过询问的方式来获知了。 如果你想知道用户的一般态度或他们对某个问题的看法，访谈也是很有用的。当你获得这一信息后，你就应该设计能够解决这一问题的产品特性(并测试这些特性的