别盲目听从你的用户

关于倾听用户，Paul Buchheit是这么说的：

我用了一天的时间就做出了第一版的Gmail。它一开始并不起眼。我所做的，也不过是把我所有的邮件放进Google组（Usenet）的索引引擎里。我把它发给几个人看了，他们评价说这还是挺有用的，但如果除了我的邮件之外也能搜他们的邮件，那就更好了。于是我开发了第二版。在将第二版发布之后，人们开始想要回复邮件的功能。于是我开发了第三版……在Gmail正式面世之前，这个过程实际上在Google内部持续了好几年！

一般创业公司不太会有成千上万那么多的内部用户。因此，把产品尽早公开发布出去是很重要的。当FriendFeed在10月份准发布（内部测试）的时候，这个产品其实才开发了大概两个月（而且99.9%的代码是由Bret和Jim两个人写的）。从那以后，我们做了大量的改进。试想如果我们当初没有提前发布，可以肯定的是，我们最终做出来的产品绝对不会像现在这么好。什么原因呢？因为我们找到了用户，而且我们倾听来自他们的反馈，我们很清楚地知道我们的产品哪方面做得好以及哪方面做得不好。

倾听用户是一件很微妙的事情。用户常常不知道他们想要什么，即使知道，他们也未必能够说得清楚。沟通永远是个问题。但不管怎么样，你都不能忽视用户。大部分人在发现你的软件或网站满足不了他们的需要时，都只是静静地走开，而且永远不会回头。因此，那些热心给出反馈的用户值得你去注意和尊敬。他们很积极，以帮助你设计产品为己任。如果你不认真倾听，并且有礼貌地回应所有的用户反馈，那你注定会失败。

拒绝倾听用户是很不明智的。然而，我们给“可用性”设定的第一条规则是“不要听从用户”，这不是自相矛盾吗？

如果想知道哪个设计方案更好，只须用户在操作界面上尝试去完成他们的任务时，你在一旁仔细观察。这个方法是如此之简单，以致于很多人都熟视无睹。他们不敢相信，认为可用性测试一定还有其他更为高深的东西。然而，这里面究竟有哪些基本原则呢？我把它们归结如下：

·       观察人们的实际做法；

·       不要相信人们说的他们做了什么；

·       绝对不要相信人们预想的他们将来可能会做什么。

我是认同Paul的，但他的话容易让人误解。Paul曾在一篇文章里说过相关的这么一段话，“我们心里很清楚什么东西在正常工作”，它实际上暗示了“衡量”和“关联”两个要素。如果你的产品能够产生详细的日志来记录用户的实际操作，那么就没必要当面去观察他们了（尽管你去当面观察也无妨）。在你收集了用户的反馈之后，要把它们跟记录那些用户实际操作的数据关联起来。

不要单纯地实现来自“用户代表”或者“业务分析师”的功能需求。把可用性搞砸最常见的做法，就是只听用户说的，而不去看他们真正做的。需求说明书里定义的常常都是错误的。你必须快速地把需求转变成原型程序，然后将具体的东西展示给用户，以确认那是否就是他们真正想要的。

仅凭用户反馈就采取行动是有问题的。哪怕你出于多么美好的意图去猜测。如果你能根据“白纸黑字”一样可靠的数据而采取行动，为啥还要靠猜呢？把用户反馈和详细的使用数据结合起来，然后再去对你的应用程序或网站采取必要的改进措施，这才是正确的做法。

让我们一起来看看Valve软件公司所做的硬件调查表吧。一直以来，游戏玩家对支持非常高的宽屏分辨率呼声很高，比如1920 x 1200或2560 x 1600。这是完全可以理解的，毕竟他们在采购高端游戏装备上花了很多钱。但是，对于绝大部分人来说，他们究竟在用哪个分辨率呢？

译者注：Valve是一家位于美国华盛顿州的软件公司，专门开发电子游戏，代表作品有《半条命》、《军团要塞》、《反恐精英》等。

基于这份对130万Steam用户的调查表结果显示，大概只有10%的游戏玩家拥有很高分辨率的宽屏显示器。当然，可能会有其他方面的原因促使你仍然去满足他们的要求，比如说，这10%的人很可能是这个游戏最忠实的玩家，他们具有很大的影响力。但有了真实的数据去印证用户反馈的问题，它能支撑你所采取的行动，以确保你的开发经费用在了刀刃上。最后你还要做的是，在几乎没人使用的功能上削减开发成本。而这些都得靠分析使用数据来帮你决策。

译者注：Steam是一个游戏整合下载平台，最初是由Valve公司请人开发的。它原先只为Valve旗下的游戏更新内容而用，不过现在已经发展成为一个全球最大的综合性游戏下载平台。

Valve公司同时也在为它旗下的众多游戏——比如第二版的《军团要塞》（《TeamFortress 2》）——收集详尽的关于游戏玩法的统计数据。

我们已经习惯于依赖从玩家那里得来的书面反馈，以帮助我们决定游戏里需要特别改进的地方。而最近，Steam允许我们收集比以往更多的信息。第二版的《军团要塞》也自带了一个汇报机制，它可以详细地告诉我们用户是如何玩游戏的。我们把收集到的这些数据共享出来了，因为我们觉得大家会发现它很有趣，而且我们也希望尽早把一些严重的问题定位出来，并最终开发出一个更好的产品和用户体验。

报表的第一段给出了每个兵种所使用时间的一个统计，它揭示了第二版《军团要塞》的一个问题，而且我认为，这是一个通过再多的玩家反馈都不可能暴露出来的问题。

侦察兵	17.5%
工程兵	17.3%
普通士兵	15%
爆破兵	10.5%
狙击手	10.1%
重装兵	8.5%
间谍	8%
喷火兵	7%
医疗兵	5.5%

这个问题就是，医疗兵在实际的作战过程中被严重忽视了。我猜这是因为医疗兵并不直接参与战斗，所以他们并不像爆破兵或士兵那样激动人心。然而这是令人遗憾的，因为医疗兵的治愈能力对于赢得一场战争常常是很关键的。Valve公司接着做了什么呢？他们发布了一系列跟医疗兵相关的作战取胜法，以鼓励玩家更多地选用医疗兵。这就是基于真实世界的玩家数据而进行的迭代式游戏设计！

使用详细的游戏玩法度量来提炼游戏设计的做法并不是新创的。Bungie公司早已对第二版和第三版的《光晕》（《Halo》）进行了全面的可用性测试。

4月份的时候，Bungie公司发现，在第三版《光晕》的一个叫瓦尔哈拉殿堂（Valhalla）的多人游戏关里存在一个令人不安的问题。

玩家的死亡数（在上面的“热量图”里用深红色表示）呈现出向左边基地倾斜的趋势，这暗示着从右边偷袭的军队可能占了什么便宜。在对这个图片复审之后，设计师最终修改了地形，以使得交战双方的机会均等。

译者注：瓦尔哈拉是北欧神话中死亡之神奥丁款待阵亡将士英灵的殿堂。

我们再一次看到了统计数据的力量。试想一下，如果光靠玩家主动告诉我们的反馈，我们怎样才能发现地图不平衡这样非常基本的问题呢？我不知道这是否存在一丁点的可能性。

去看一看，你的应用程序或网站开始以一种合理的方式收集有用的用户活动数据了吗？别误会我。我始终认为，用户反馈是很重要的。但绝对不要“单纯”依靠用户反馈来指导你的行动。我们应当总是通过某些用户活动数据，来印证和支撑有价值的用户反馈。忽略用户反馈可能让你最终难逃失败的命运，但盲目地听从每一个用户的请求也会让你必败无疑。