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

语言: CN / TW / HK

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

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

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

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

追逐梦想

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

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

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

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

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

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

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

我们打造了他们所要求的

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

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

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

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

我们设计了这个工具。

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

那么为什么他们要告诉我,他们想要这些功能?

用户研究没有终点线

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

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

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

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

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

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

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

转折点

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

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

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

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

“太多的无用评论”

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

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

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

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

最后的尝试

我点击了一个按钮来部署。

我的实习期只剩下一个多星期了。如果事情再次恶化,就没有时间去调整了。我真的只有时间修复小错误,收集更多的定性数据,并向更多的团队展示我的项目。计划是在我回到大学后收集几个月的使用数据,然后在某个地方提交一篇论文。

在99号楼举行的实习结束报告会。

我祈祷这个工具能在很长一段时间内帮助开发人员进行代码审查。

快进到几个月后,我们遇到了另一个问题。分析使用数据并不像我们希望的那样直接。我们对所记录的数据做了一些错误的假设。由于我不再是微软的雇员,我不得不通过电子邮件写数据库查询,并等待有人有空闲时间来运行,然后把匿名的汇总结果发给我。

人们确实使用了这个工具!我们把它部署在三个团队的98名软件工程师身上,为期15周。它被41位不同的作者和883位独特的审查者用于354次代码审查。它在代码审查中发布了149条分析评论(加上构建和测试框架的状态更新)。它本来可以发布更多的评论,但特定的分析警告可以被团队取消。

通过分析使用数据和电子邮件发送调查,我们发现有证据表明这个工具提高了沟通、生产力和审查质量。用户报告了压倒性的赞誉,以及可以改进的功能要求和方案。

最后,我们在一个顶级会议上发表了一篇精彩的论文。不仅如此,微软的几个团队还主动联系我,了解这个工具的设计原理,因为他们想为自己的团队重新创建这个工具。

写下这个故事让所有的问题和解决方案听起来都很明显,但这是从事后来看……

让我们回顾一下我学到的一些经验。

始终让你的用户参与进来,不要孤立地去建设。

不要低估那些你只能从外部看到的工程挑战。

经常定期向你的团队表达关切。他们可能会比你更快地解决这些问题,或者他们可能会发现什么这会变成一个主要的障碍。

准备好遭遇波折。

用户说什么是有原因的,但可能有深层次原因。

如果你假定用户会做什么,他们会找到一种方法让你吃惊。

如果功能不容易使用,不管做的有多好,都没人会用。

用户的工作流程就是一切。(我一直在重新学习这一课……)

用户比你想象的要聪明得多。

译者:蒂克伟