用户现场调研，许多B端产品经理都经历过，然而不同的人通过不同的方法，拿到的调研结果也往往不同。一次成功的调研能够使产品需求浮出水面，一次失败的调研则只是浪费时间。若把用户调研当作一场战争，我们该如何制定战术，确保挖掘出用户最真切的需求？欢迎阅读。
大部分行业的B端产品经理，本身无法真正成为自己所设计产品的用户，只能通过去现场进行实际的用户调研了解真实用户的痛点、发现产品需求，从而把握产品的发展方向。所以，用户现场调研几乎是所有B端产品经理在设计产品时都会经历的一个重要环节。
但是不同的人通过用户现场调研所拿到的结果是大相庭径的，有的在调研后收获颇丰，信心满满的撸起袖子开始干了。有的却悻悻而归，抱怨用户不配合抱怨调研就是浪费时间，随便编造一个用户调研报告了草草了事。
不同的人通过不同的方式方法产生了不同的调研效果，用户调研其实是能够为产品的发展起到重要作用的。但我们不能高估自己也高估用户，觉得睿智的我们双方在一起随便聊聊天，产品需求就浮出水面，产品问题就迎刃而解了。
而是要把每次的用户调研都当成战争，认真制定战术，通过一次次的战争挖掘用户最真切的需求，让我们的产品在上线后真正征服用户，这样才能收获产品的胜利果实。
在进行用户现场调研前，要先知彼。搞清楚用户所处组织的组织架构，明确实际用户与关键相关方。因为B端产品的特性，我们做用户调研时不能单纯只调研实际用户而忽略了关键相关方。
比如我负责的产品是由住院病区护士使用的，那么实际用户就是一线的病区护士。关键相关方则还包括医院护士的管理部门-护理部、医院信息系统的管理科室-信息科。
明确了实际用户与关键相关方之后，要根据情况判断进行用户现场调研时的人员范围与顺序。
仍然以我举例，通常我去医院初次调研或是比较重要的调研时，一定是实际用户与关键相关方都要进行调研，并且顺序为先整体再局部，也就是先医院信息科，再护理部，再到临床护士也就是实际用户。
原因在于医院信息科作为医院所有信息系统的总体管理部门，是医院信息系统对外沟通的窗口和中间桥梁，他们对临床护士和系统各方面的情况非常了解。
首先，找到他们一方面能从他们作为信息工程师的角度，整体全面了解目前护士的业务场景和护理部及护士当前系统的使用情况；另一方面他们作为信息系统管理部门，也方便协调安排我们后续与护理部和护士的调研工作。
护理部作为医院护士群体的管理层，相比信息科更加熟悉护士所有的临床业务场景，并且他们对模糊的业务场景也具备决策权。同时也会对系统提出一系列的要求和规范，我们的系统基本要在管理层的这些要求和规范下进行设计。
搞定了关键相关方的信息科和护理部之后，我们的用户调研基本就已经有了骨架。之后再找到实际用户临床护士沟通，针对一线护士实际的业务流程进行更加细致和深入的了解，确定实际业务中的所有细节，将骨架填充好丰富的血肉。
这就是为什么要了解用户的组织架构和关键相关方。不过了解了这些之后也别着急出发，我们只是知彼了，还没知己呢。
带着这些问题再好好准备准备弹药吧！
一百多年前，当世界上主要的交通工具还是马车时，福特汽车创始人亨利福特在做用户调研时，收集到很多用户需求是跑的更快的马。但是亨利福特没有研究如何能够让马跑的更快，而是继续追问了为什么，最后得到了用户是需要更好的交通工具实现更快到达目的地的需求，从而推动了汽车工业更加快速的发展。
这是关于用户调研一个很经典的故事，但是很多人仅仅把它当成了故事并没有付出实践。
在实际工作中，我们的大脑习惯于优先接收和处理可以少思考的确定性问题。当我们和用户沟通时用户说出了问题的答案时，我们总会下意识的松一口气，心想搞定了，用户已经把答案直接告诉我了真好，我不用费脑子多想了。
于是道理大家都懂，但实际做的时候就是没多问几个为什么。希望大家时刻提醒自己在面对用户的需求或者任何人的需求时记得多问几个问什么。
别人可以不问，但是作为产品经理的我们不能不问，我们是一个产品、一个功能、一个需求的底线。
在问为什么的时候我们也要注意不要带有主观情绪，也不要使用带有刻意引导的话语去影响用户说出你想要的结果。
有些产品同事在办公室已经想好了“创意”，于是在用户调研时引导用户认可自己的“创意”。但是用户的嘴是会骗人的。
毕竟在调研时大部分是用嘴说而不是实际操作，且用户可能懒得搭理我们随便敷衍表示了认可。于是造成了产品在错误的道路上迈着自信的步伐越走越远，最后在上线前被用户给否定方案的情况发生。
这是因为我们在和用户沟通时，潜意识里将自己和用户作为了对立面，希望对面的人认可自己先入为主的想法，不希望听到不一样的声音。
要避免这种情况的发生可以试试在和用户沟通的时候不要告诉用户你是这个产品的设计人，从而下意识的站到了用户的对立面，而是说你是负责把用户的声音传递给产品设计人的中间人。
作为这个角色我们在用户表达时可以和用户站在同一战线，甚至可以和用户一起吐槽产品，吐槽产品设计人员，让用户感到我们是感同身受的真实理解他们，从而提升对我们信任感。这样能更好的引导用户说出最真实的想法和需求。
不过即使用户是真诚的表达了真实的想法，我们也仍不能只是简单的完全信任用户的话。因为人的记忆和表达会因为各种情况而出现不同程度的差异，这是无可避免的情况。所以除了耳听八方听用户说什么，还要眼观六路去实际观察用户是怎么做的。
比如我们和护士沟通时，不是仅仅在办公室聊一聊就结束了，还会争取跟着护士看一看她们的工作流程。甚至在病区一待就是几天，观察不同护士的不同操作情况，通过自己对实际业务场景的观察去佐证和判断与用户口头表述的内容是否有差异。
并且在用户调研过程中，我们也不要过于严肃化，觉得一定要是跟用户说我现在开始问问题了，我现在开始观察了，我们的用户调研才开始。
其实用户调研可以是一个一直打开的状态，你在观察的时候看到有疑惑的地方可以随口就问了，和用户闲聊的时候想到了一些模糊的场景可以顺便提出来就确定了，甚至在路上碰到了用户都可以唠两句你需要了解的问题。
不必拘泥于形式，调研不是刻板的坐直问问题、站直盯着用户的一种固定行为，而是可以做到润物细无声，让所有和用户在一起的时间都能够自然的感受和理解。
前面我们提到有时候调研的时候用户明明认可了，可上线前又否掉了方案的情况。这时候别管这方案合不合理、她当时听没听进去了。
当时你的确是得到用户口头认可了，但是用户现在就是说“我不知道这个事啊”，你是不是欲哭无泪，这找谁说理去啊！这就是查无实据带来的后果。
在用户调研时，针对重要需求和特殊情况可以在对方允许的情况下进行录音录像，保留原始沟通记录。在用户调研完成后，有条件的情况下最好把调研内容进行汇总整理，形成本次的用户调研报告。
并和各方一起就用户调研报告内容进行评审，评审时争取我方领导、对方相关各部门和对方领导在场。针对调研报告有异议的部分可以记录下来，趁大家都在就有异议的地方进行澄清和确认。针对调研报告多方确定无误的话可以签字留档。
当然签字后并不代表后面用户需求要是发生变化了我们就不再进行修改了，而是当这种情况发生时，需要让各方知晓需求发生改变的实际情况。
避免各方将其盲目简单定义为是我方当时的调研工作理解有误、质量有问题等原因，导致给我方工作造成负面影响。
同时多方评审调研报告也是我们产品经理为后续的产品设计质量做的一道保障。实际工作中存在部分同事为了应付快速完成用户现场调研工作，编造调研报告的情况。
这会导致后续在产品设计时，用户调研报告完全没有参考价值，产品经理不得不重新进行调研，造成了额外的人力成本、时间成本、尤其是用户信任成本。
作为产品经理，这种行为对产品质量的伤害是极深的。希望各位做一个负责任的产品经理，不要让这种情况发生在我们身上。
用户现场调研完成后，我们要将用户调研的内容提炼为一个个的需求，并且确认需求的优先级和排期，安排后续的设计和开发工作。
在这个过程中，有些用户调研的内容可能会因为有了更好的思路而产生更好的替代方案，有些内容也可能因为技术问题、资源问题等无法实现或者不考虑实现，以及在落地时会发现更多细节性的问题模糊不清。
这些情况是常有的，千万不要觉得用户调研已经结束了，就不管不问用户自己做决定了。事事有回应是一个合格的打工人的基本素质，面对用户也一样。
我们的用户花了这么大精力陪我们完成了用户调研，并且也对我们的结果寄予厚望，希望能帮助我们一起打造一个适合他们使用的优秀产品。
在我们针对用户调研的内容安排了后续的工作时，有条件的可以及时通过合适的方式如线上会议、微信或者再次线下见面将处理情况和用户进行反馈，模糊的地方再沟通确认。
让用户切实感受到我们做产品的诚意和对用户付出的在意，也能提升用户的参与感，提高用户对我们的团队和产品的好感。
甚至在产品上线后，我们仍然可以进行现场回访，在实践中和用户保持沟通，继续向着更加优秀的产品方向优化迭代。
用户现场调研不是一朝一夕的事情，不是一次两次见面就完成的任务。尤其我们作为B端产品经理，要向用户请教的专业的地方有很多，用户现场调研能够贯穿在产品的整个生命周期中发挥重要作用的。
希望大家能够更加地重视用户现场调研这一行为，并且能将其在我们设计产品的工作中发挥更多的价值！
专栏作家
小游，人人都是产品经理专栏作家。工作在医疗领域的产品经理，持续关注医疗信息化、数字医疗、互联网医疗行业。打怪升级中，期望能够通过自己的力量为世界创造美好。
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。