与C端产品相比，B端产品在业务处理，逻辑流程要复杂，要严谨。同一件事务从发起到结束，会涉及到不同角色人员处理，角色上发生交叉，而同一个角色的人也会在不同的环节处理不同的事务。如果不能找到合适的角度来分解用户需求，让产品在业务操作层和逻辑层做好分离，那么设计产品感觉就像是解一堆麻绳子。用户访谈一定是要在产品启动之前有过深入的研究和分析。下面聊下B端产品的访谈时，个人认为的要点:
做好用户群体，用户角色的分类。访谈之前，根据用户对产品的熟悉度，做一个简要的分类肯定是必要的，即用户群体的分类。一般情况下，会有三大用户群体的分类：
- 对行业产品不了解，也没有使用过公司产品的;
- 对行业产品有一定的了解，使用过公司产品或同类产品一段时间；
- 对公司产品或行业产品非常熟悉，使用过公司产品很长时间；
上述三类用户是最基本的覆盖，用户会因为对产品的熟悉度不同，而提出差异非常大的需求。如果只是听取某一方的声音，很容易被用户带走。用户只会站在自己立场，面对当前的遇到的问题，提出需求。常见的情况就是，没用过产品的人很难给到建设性意见，声音也少，但不意味着对他们的访谈是没有意义的，恰恰是非常有用的，着重点在于有没有了解群体的痛点。而那些高级用户可能因为对产品非常熟悉，提出了很多高级性，专业性的需求和功能点，但不具备普适性。
按用户角色来区分同样是非常重要的分类。B端的产品往往会有多个角色。比如说，物流管理软件，里面的角色有会业务员，主要负责基本货运录入管理；财务，主要负责账目的核销。网点老板，关注业务运营状况，查看统计分析报表。从用户角色来分类的话，也要做相应的分类：老板（高管），经理及操作员。同高管访谈可以了解他们对产品的宏观期望与建设目标；同经理访谈可以了解他们工作处理，业务管理上的目标；同操作员访谈可以获取到操作上的建议。要意识到这一点，访谈时要根据访谈对象确定不同的调研目标。不同的访谈对象的需求可能有冲突，比如说，操作员希望高效快捷录入，而经理希望尽可能详尽记录工作每一环节。了解他们自各的目标，理清不同目标之间的复杂关系，平衡好各方的利益，来满足他们需求。
把控访谈目标，既要有的放矢，又要灵活自如。 基本的访谈大纲不用说，访谈之前大家都会做。做访谈大纲是主要为了在访谈时能够把控访谈目标，而不至于碰到那些侃侃而谈的访谈对象，直接被带着走了，最后草草收尾。大纲只是概要说明，就像小学语文学习的三点式总结，是套式。访谈需要控制时间，一般1个小时左右会比较合适。很少有用户会就某一个点跟你聊两次，他们通常说过就不会再说了，所以如果在开始的时候没有聚焦好，后面时间长，用户不想聊了，只会空泛地跟你聊。为了获得较好访谈效果：
- 问题从大到小开始收敛。开始的时候让用户平滑地切入话题，然后开始将话题不断地深入，聚集缩小，来获得较为详实具体的回答。
- 灵活应对用户的跳变式的回答。我最早做访谈的时候，访谈大纲是按照产品模块来划分的，尽可能做到严谨有序。在实际访谈过程中，发现并不适用，比如说，我在跟用户聊功能点A时，它突然跳到B，而这时我得去找B所在位置来做记录，如果这样来回几次，很容易变得被动。所以设计大纲还是要考虑到访谈对象的思维模式，最好以话题形式来设计大纲，大纲内也做好分组。这样既能够保证记录好访谈信息，又能把握好访谈结构。
回忆式访谈，还原事实。 访谈不是个容易的活。不单单是提前做好准备，定好计划，到场拿着大纲去跟用户去聊既定的内容就可以了。访谈的对象的用户类型和角色总是在变的，但你在访谈时会去思考，拿前面的的访谈做类推和比较，很容易把自己带到危险的境地。访谈的目标很多时候是要验证某一推论，但是千万不要把你的问题直接抛给用户，这样会容易干扰和引导用户的回答。我知道，你心里肯定有在期望用户说出你希望看到的那个答案。我就比较怕做用户访谈时，非产品的人在旁边经常向用户提问：你有没有觉得xxx是/比较xxx？
- 采用「情景式」访谈，让用户通过回忆的方法来去陈述某一事实，不要给用户预设立场，也不要让用户思考。
- 对于一些比较重要而又让人怀疑的点，我可能会多维度去试探，确认用户是不是在欺骗你，但她本人可能并未意识到在骗你。比如你问某一位美女为什么不吃甜食，她可能告诉你她不喜欢吃甜的，但真实的原因可能是她怕变胖。
如果你只是问用户想要什么，通常只能获得期望性需求，而基本性需求和兴奋性的需求需要你去挖掘和思考用户行为动机。普通的需求一般都可以借助切入实际的工作场景提出合理的优化方案，而深层次看不见的需求就需要对业务进行深入理解，提出比用户现在更好的解决方案。
访谈之后做好归纳总结，但不要忘了，比这更重要的是敢于去大胆提出假设，再不断进行验证与迭代演进。
网友评论