写完上一篇 实践版 | B端用户访谈的20条心得（前10条） 后，很多小伙伴私信知果觉得看了很有收获（知果当然很开心啦~）。由于最近事情较多，这篇更新有点慢了，还请小伙伴们见谅哈。那话不多说，接着上一篇我们再来看看B端用户访谈调研还需要注意哪些。
在访谈中你会发现，有可能用户的知识面是非常广的，他提到的问题我们可能未曾想过，或根本不知道。此时，我们会产生想把问题搞明白的心态。可能有小伙伴要问了，假如我不明白这个问题，去问用户，会不会让用户觉得我什么也不懂呢？
其实你不用担心，既然用户受邀了访谈，就不排斥与我们沟通。并且他希望自己反馈的问题，是可以被真正得到重视和解决的。记得曾经有个受邀访谈的用户和我说：“我最担心的是你访谈了我，但却不对我提出的问题重视，并在后续改进。而是访谈完，就把问题搁置一边了。”
可见，我们在访谈中可以与用户真心地交流，不用害怕不懂而不敢问。我们要把用户说的问题搞懂，并且给出达成共识的解决方案，才是搞懂问题的根本。
我在访谈中经常会出现这种情况，和用户聊着聊着，会希望调整访谈的内容。例如，有些问题觉得已经解决了，就想跳过；有些问题原来没想到，想在访谈中增加。
依据我的经验，我认为访谈内容在可控范围内，是可以做一些调整的。我们无需根据原来列好的访谈大纲，照搬来做。毕竟，访谈的双方都是活生生的人，而不是两个机器人，我们在访谈中需要根据用户表现出来的相关信息（如表情、肢体动作、言语等），做一定程度的调整。
我们心中要始终明确，任何访谈内容，最终是为了访谈目标服务的。在访谈目标范围内的调整，都是可以接受的。
我们在用户访谈的一些文章中，会看到说，我们尽量不要让用户发散思维，而是要在我们划定好的访谈范围里面进行。若用户不小心跑题了，那我们需要把他们的思绪抓回来，回到本该访谈的范围里。
我在实际访谈中发现，假如你和用户在访谈前提前达成了访谈范围，那跑出范围的概率也不会很大，最多是用户通过A问题引申到了B问题，而不会故意去谈一个B问题。此时，我们可以允许用户发散一下思维，这对我们更全面地了解用户的所思所想是有益的。
但若出现用户直接谈到了B问题（他能谈到，说明他比较在意这个问题），我们尽量不要打断用户，让用户说完。等用户说完后，我们可以看下这个B问题是否属于自己可解答的范围，是的话，不妨简单解答下，接着将话题引回到本次访谈中。若不属于自己的负责范围，可与用户沟通自己会记录下来，带回去反馈给相关负责人，后续会联系用户。
有时候，我们访谈的内容是针对界面操作的，那么就非常有必要让用户现场演示，而不要通过口头描述来传达。若通过口头传达，一方面，我们理解的可能与用户描述的有偏差；另一方面，我们回去自己找场景验证，也容易找错。
这就对应了上一篇中的第7条，我们需要提前罗列合适的访谈环境。若预见到可能需要用户进行界面操作的，那么就需要提前准备电脑。如此，在访谈时，针对某些沟通内容，就可以直接演示界面现状了。
我在最开始访谈时，经常是用户演示界面上的一些问题，我用笔记下来的情况。之后，我再自己到电脑上找用户当时说的问题是哪些，逐一截屏记录下来。但我发现，回去后我可能压根找不到用户当时演示的问题了，我就只能用文字描述，但这不利于场景复现与排查问题。
因此，我们在访谈时，就可以和用户沟通在信息脱敏的情况下，保留一些关键页面，可以是截图，也可以录制视频。
我的习惯是，不论开会、与同事沟通，等等情况，都会拿上本子和笔，将一些关键信息记录下来，用户访谈也不例外。
古话说：“好记性不如烂笔头。”确实如此。人的记忆容量是有限的，特别是短时记忆的容量，更是非常有限。而且对于有些信息，你现在觉得自己记住了，可回过头来却发现你从未觉得它们存在过。
用户访谈长则需要2-3个小时，若我们一天访谈2-3个用户，那几乎一天大脑都在处理信息。因此，想要在事后将这些信息都回忆起来，我们就必须要依靠本子和笔的帮忙。
用笔和本子记录访谈关键词，结束后立马整理，复现具体内容。
很多用户访谈文章指出，在访谈结束环节，建议给被访谈人送个小礼物。我的感受是，对于被访谈人来我方公司的情况（专门受邀访谈的），可以送小礼物，还可一起吃个简餐。如果是我们到对方公司，可能带上礼物并不方便，就可以从言语上、肢体上（如握手）对用户做出感谢。
当然，这都不是唯一答案，我们可以根据实际情况需要，做出真心地感谢。
打铁要趁热。所以，当一天的访谈结束后，我们需要及时梳理访谈内容，把与用户谈到的问题，尽可能的还原和记录。如果思路清晰的话，还可以将同类问题合并起来，让信息尽量精准，不冗余。
我有时候一天可能访谈不止一个用户，因此我会根据实际情况，在访谈完一个用户的空隙时间进行内容整理。这时候记忆是最清晰和深刻的，稍微晚一点时候，可能就回忆不起来了。
关于内容的梳理格式，用excel、word还是其他工具，都可以，只要能把问题说明白即可。
每次访谈完，我们都可以思考下是否本次访谈还有不足之处，是可以改进的。
记得有一次我访谈一位事业部的BU总，我觉得自己准备的已经较为充分了，包括产品核心理念、产品原型、本次访谈的主要问题，等等。而且在我去访谈前，各种要注意的事项我都再检查了一遍。可真正访谈中我发现还是有很多意料之外的事情出现了。比如，BU总希望不只看到原型，还希望看到原型交互的效果（至少是核心交互），否则他还需要自己想象。再比如，他希望知道业界竞品是怎么做的，但当时我对这个准备并不充分，因此没有很好的回答他。
之后，我在访谈中会评估是否有必要把原型做成带交互的，若需要，就把交互做出来。或者也会做成视频，方便用户理解。
我们访谈后回忆整个过程，若发现还有待改进之处，可以梳理出来，在之后的访谈中尽可能规避这些问题。当然，我们也要根据下次访谈的实际情况调整，并不是一股脑儿都改进到下次的访谈中，要具体问题具体分析。
其实这不是访谈后立马要做的，而是把每一次访谈当成产品未来规划的输入。若访谈中合适纳入到产品规划的，可以把这些零碎的点进行整理，让这些点的需求形成价值。
记得在一次关于设计体系表格功能的用户访谈中，用户提出了很多我曾经并没有考虑过的功能（因为我服务的场景并不需要这些功能）。后来我也找了很多竞品，发现也并未有这些功能。可仔细思考发现，这些功能确实可以解决某些特定场景的问题，因此我将它们规划到了产品中，也可以说这是该表格的特色。
最后，分享给你一个小框架，是关于单问题调研的，我将其称之为4步法。
第一步：描述事实： 让被访谈者描述此问题发生的客观情形。
第二步：内心感受： 让被访谈者对该问题描述自己的感受。若感受非常不好，则可以描述为什么不好的原因。
第三步：使用场景： 让被访谈者描述该功能/菜单在什么情况下会使用；还可以谈谈使用频率。
第四步：解决方案： 让被访谈者简单聊聊他对此问题是否有建议的解决方案（若其描述不出来，也无妨；我们要是立马感觉有解决方案，可以主动与用户探讨）。同时，该方案是否被接受，需视情况再定。
为了方便大家回看「知果日记」的往期文章，我做了一份「知果日记」日·常·分·享·锦·集，会持续更新，欢迎你收藏和随时查阅。关注公众号，聊天窗口发「锦集」就可以领取链接。
好啦，知果今天的分享就结束了，如果你喜欢今天的文章，欢迎点赞 + 在看 + 分享；如果你想和知果进一步交流，也欢迎下方 加我微信， 一起交流、进步~
我的书籍与你分享
这是在我从业6年之际，写的一本合适B端从业者（产品经理、设计师、研发工程师等）的入门书籍 《B端思维-产品经理的自我修炼》,已经再印数次。
前些日子，有一位刚入门B端没有人带的小伙伴，因为认认真真自学了《B端思维-产品经理的自我修炼》，不仅形成了自己的B端认知体系，也帮助他找到了更好的工作。当他和知果说到这事儿的时候，知果真的很为他开心。
还有一些刚入门B端的小伙伴，看了书以后，对B端的认知有了很大地提升，在工作中更游刃有余了。
