别问用户想要什么！用户访谈的3个基本问题

　　用户调研的首要原则：千万别直接问用户他们想要什么ErikaHall，justenoughresearch
　　我喜欢做用户访谈，它们低廉、有效（你得到的信息会多于你问的问题）、且快速（一般访谈5个用户就够了）。但是，优质的用户访谈需要技巧。如果你天生对人群敏感且好奇，它能帮助你得到你想要的信息；如果你并不具备此项特质，它也能帮你带入角色去体会其中滋味。例如，google实验室的michaelMargolis就喜欢将自己带入角色去做用户调研。
　　正如ErikaHall所述，当你做用户访谈，要避免询问他们想要什么，因为这只能给你带来错误观点。你仅仅能收获用户所设想的解决问题的办法，却无法发现问题的本质原因。
　　不要给你的用户访谈设置障碍
　　仅仅询问用户想要什么会让访谈变得更困难，同时，你也只能得到错误观点。
　　当你询问用户想要什么，你其实是让他思考解决问题的所有可能性，无疑这将使用户研究变得越发困难。如果你做用户研究的目的是为了搭建还不存在的新产品或功能，你其实是想知道究竟是什么原因造成用户使用现有工具无法完成任务，循着这个方法，你才能设计新功能或渐进优化现有功能来帮助他们完成任务。
　　我在Kissmetrics工作时，我曾花费很多时间与用户交流，关于他们使用什么工具或方法来解决当下所遇到问题。我总结了三个高效有用的问题来做用户访谈，并且屡试不爽：
　　你正在解决什么问题？（收集内容信息）
　　目前你如何解决该问题？（分析工作流程）
　　有什么方法能帮助你做的更好（发现机会）
　　译者注：Kissmetrics数据分析公司，位于旧金山
　　问题1：你正在试着解决什么问题，为什么要解决这个问题？
　　为了挖掘产品使用和问题产生的根本原因，我们不断询问用户“为什么要这么做”，直到我们真正理解了用户或客户的痛点。
　　当你调研用户正在做什么时，收集背景信息非常关键，这将有利于你去理解你的用户。调研收集信息诸如：用户工作的小组有多少人以及他们是如何在庞大组织中分工合作，将有利于我们设定所调研问题的范围框架，以便在该框架下使我们的产品更好地发挥功效
　　想象一下，你是一个工匠，难道你不想知道你当前的任务是修补墙上的一道裂缝，还是去修缮整间屋子吗？根据你任务的不同，你便需要选择不同的工具及对应型号。
　　这同样适用于用户访谈。当你知道用户正在解决的究竟是什么问题，并将这些必要的信息告知你的调研小组，你的pm和rd团队都将会感激你的。探究问题的根本原因，你要问为什么。使用5步“为什么”的问法，能让调研变得简单。通过反复问为什么（并不是真的只问5个为什么，视情况而定哈），你将顺其自然地知道用户工作流程如何，或发现其中缺少哪些必要流程。使用此法，我能通过完善流程来满足用户需求，而不需要让工程师再去开发一个新功能来弥补，这样就能将工程师从低效的项目中解救出来。
　　问题2：目前你如何解决该问题？
　　搞清楚工作流程和组织架构，能帮助我们确定从哪里着手解决问题。
　　在明确问题的内容范围之后，我倾向去发现用户当下是如何处理该问题的。做这个的好处是让我能够跟随他们的步伐，去体会他们在处理该问题时有多痛苦。有时，用户会使用奇葩的方法去解决问题从而得到他们想要的。但其实我们只要稍做改善下产品就能解决用户花费数小时甚至一周在解决的问题
　　举个栗子。最近我为一个产品小组调研他们正计划开发的新功能。但我们想了解目前该问题有多严重性，从而排列它的优先级。通过访谈一系列用户目前是如何操作的，我得到了以下一些结论：
　　译者注：该流程表达的是客户如何管理邮件列表，及如何评估客源；CTA全称commoditytradingadvisors，即商品交易顾问；webinar属于一种线上会议软件
　　知道用户的工作流程也能让你的团队发现你的工作流程中有哪个部分需要优化。再举个栗子，在KISSmetrics，我们最近发现客户在核对数据时更喜欢使用邮件而不是用第三方应用。此前我们已经知道kissmetrics是他们日常工作中不可或缺的一部分，有些用户一到办公室甚至会首先处理该类数据，所以我们目前在升级该项目，即每天给我们客户邮件发送更清晰的数据小结
　　问题3：有什么方法能帮助你做的更好？
　　大部分调研在你思考此问题前其实就结束了。这个问题是让用户给你一些提示：在哪些领域他们最需要帮助。当然，这个问题也能帮助你确认或者推翻你的团队在产品架构方面的某些假设。
　　如果你一开始就跨过之前的问题去询问用户如何能做的更好，那么你只能得到他们的一些意见却无法知晓他们当下是如何处理目前所遇到问题的
　　“设计产品是一件非常困难的事情，很多时候，只有在产品面世后，人们才知道他们想要什么。”SteveJobs
　　这是你发现如何优化产品的机会点，或者是用户宣泄他们目前解决办法的机会点，或者是一直被忽略的问题点。要么你会发现这个机会点足够强大到需要推动整个团队去解决，要么这个机会点其实已经被解决，我们需要挑过它进而去关注另一个假设。