为什么用户不去使用他们强烈要求添加的功能？

神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。

编者按：用户想要什么？每当你这么去问用户，他们都会自认为地给一个你想要听到的答案。绝大多数的人几乎不太清楚自己想要什么，所以停止向你的用户询问，他们到底想要什么，不要让他人的想象力限制你的想法。本文来自编译。

众所周知，在用户调研中，如果你问一个用户是否想要一个新的功能，他们往往会大声回答 “想要”。谁不想要更多的功能呢？尽管他们可能不会真的使用这个功能，而你可能在功能发布后才意识到这个问题。

我们都听过这样的故事：我完全按照用户告诉我想要的东西打造产品，然而他们却不去用。有很多证据表明这些功能背后的用户需求。那么，为什么用户不用这些功能呢？

追逐梦想

能在微软工作一直是我的梦想。二十年前，我第一次使用Visual Studio接触到编程。我从Visual Basic 6开始，然后转到Visual C++ 6，再到Visual C# 2008。在我早期的一份软件工作中，我的经理在绩效审查会议上问我，“比起这里，你更愿意在哪里工作？” 我回答说是微软。

读研期间，我看到微软在我研究的领域里发表了很多优秀的论文。甚至好像所有著名的教授都至少在微软实习了一个暑假。但我不知道如何进入他们的领域，我在会议上与微软的研究人员交谈了几次，但我仍然不在他们的雷达范围。

所以有一天晚上，我向两个我想去的微软的团队发送了电子邮件。几天后，进行了微软的第一次视频面试，接下来的一周又进行了几次面试。

我在微软得到了一份研究实习的机会。

这个职位是一个综合性的角色，我与研究人员和开发者工具（dev tools）团队一起工作。具体来说，是在一个内部工具和服务上的工作，用于公司内部进行代码审查，每周大约有30,000人使用这个工具。

我一开始花了很多时间来了解代码审查过程。我跟踪开发人员进行代码审查，我分析了来自代码审查网络服务的遥测数据，我录了开发人员进行代码审查时的屏幕，我还采访了开发人员关于代码审查的情况。事实上，在我开始实习之前，我甚至做了一份关于代码审查的研究论文的文献综述，这样我就可以在第一天到场的时候做好准备。

现在，我只需要做一个工具来解决现存的问题。

我们打造了他们所要求的

我们的目标是创建一个自动代码审查器，在代码审查中提供程序分析反馈。这样，整个团队都可以看到反馈，而不是只有代码修改者能看到，他们可以把时间花在设计讨论上，而不是表面的吹毛求疵。此外，还将简化请求构建、运行程序分析器和运行测试的过程，这可能需要很多时间，对于一些团队来说，这些都是在审查过程中很晚的阶段才完成的。自动审查将在整个审查过程中保持参与，并自动更新反馈。

打造最初的原型工具所花的时间，比我们最初预期的要长得多。我本应该使用一些现有的基础设施作为基础，只需针对我们的使用情况做一些调整。这最多需要两周时间，我们是这么想的。结果发现有几个小插曲：参与我们想用的那个项目的人都离开了公司，我们不知道如何建立源代码，有大约50万行代码，而且我们找到的一个了解这个项目的人，已经提前13个小时不再回复我们的电子邮件。

没办法，我只能从头开始重写我们需要的东西，而我的实习时间已经在倒计时了。

一个月之后，我向一些经理和开发人员演示了我们的自动代码审查器的原型。他们给出了积极的反馈，并同意让我们在他们的团队中试用这个工具。我写了一个关于如何使用的简短教程，并把它发给了各个团队。我花了一个周末的时间来修复错误，并将其设置为能够在 “真实世界”中使用。

我们设计了这个工具。

几乎没有人使用这个工具。少数人用了，也只用了一两次，几乎不与它互动。几天后，没有任何人在使用。

那么为什么他们要告诉我，他们想要这些功能？

用户研究没有终点线

我感到挫败，夏天很快就过去了。这个项目在进行过程中已经遇到了十几个不同的障碍。我已经准备好放弃了。无论如何，我现在可以在我的简历上写上微软了，不是吗。

我休了个周末，试着不去想它。

每天早上，在大多数人到公司之前，我在办公室喝一杯美式咖啡和美味的巧克力牛奶。

然后我的动力来了，就像那天晚上我鼓起勇气发电子邮件，让我得到了实习的机会，我在周一早上6点到了办公室（从中部时区搬到西海岸的好处），并开始勾画出一个计划。当我的导师到达时，我告诉他们给我一周时间，我打算把这个问题搞清楚。

这不是用户的错。他们没有对我撒谎，他们确实遇到了问题，他们确实想要一个解决方案。我只是忽略了一些东西，我所要做的就是回去观察，答案就在那里。

我进行了一个小型的实验室研究，再次看看人们是如何进行代码审查的。但我也要求他们使用我的工具做一次代码审查。我几乎没有给他们任何关于如何使用的指示，我一步一步地观察着。

我给最初使用工具的几个开发人员发了电子邮件，试图了解他们对这个工具的想法。

转折点

有一个问题变得很明显，我一直在错误的地方寻找答案。甚至不是关于我们的工具所提供的功能，而是这个工具是如何融入他们的工作流程。或者在这种情况下，这个工具需要他们的工作流程进行一个微小但明确的改变，才能开始使用。许多开发人员甚至不知道我们工具的存在，我从来没有想过这会是一个问题，我们以前从未讨论过这个问题。

在与我的导师们进行头脑风暴后，他们很快就想出了一个解决方案。我们将工具的一部分从桌面应用转移到网络服务，监听代码审查，然后自动启动我们的功能，而不需要任何明确的命令。这样一来，开发人员的工作流程就完全没有变化了! 这就是默认选项的力量。

留我们的时间很短，但要创建一个网络服务来做这件事是一个相当小的任务。有一个现有的API，负责处理困难的部分。

这一次，我们希望在部署方面更加谨慎。开发人员可能会给我们第二次机会，但我怀疑他们会给我们第三次机会。我们的计划是部署到一个与我们同在一栋楼里的小团队，并迅速得到他们的反馈。我们清楚地告诉他们，他们是我们的重中之重，我们对他们关于这个工具的意见非常重视。

“太多的无用评论”

开发人员用了，但他们感到沮丧。工具使他们的信息量过大，妨碍了他们的工作。我收到了一两封愤怒的电子邮件。根据我们在开发过程中所测试的用例，我们不可能预见到这种情况的发生。但如果我们更接近我们的客户，我们就会看到。我应该看到这一点的，这是另一个教训。

我们在工具中加入了一些硬性限制，不再用信息轰炸代码审查。我们过滤掉了可能不太相关或低优先级的分析警告，汇总了重复出现的警告，并对显示的警告数量设置了最大限制。我们还增加了自动审查的状态更新，这样用户就能确切地知道系统处于什么状态。事后看来，开发者想要的东西都是完全合理和符合逻辑的，甚至是显而易见的。

是时候向所有最初同意使用我们工具的团队再重新部署一次了。

我们进行了四次检查，确认一切准备就绪，然后再四次检查。我们给经理们发了一封电子邮件，告诉他们，我们将默认为他们的所有代码审查打开我们的工具。