做好B端业务调研，需要准备的一些内容

不管你是新入职一家公司还是被指派了一个新的需求任务，你总是避免不了去业务调研。甚至最好你能把业务调研当做是一个日常任务，定期跟业务大佬们聊一聊，找到一些需求设计上忽略的地方，同时增进下和业务的感情。

所以对于一个产品来说业务调研的能力是必要的。

与C端产品注重用户体验调研和对用户心智模型的揣测不同，B端产品更关注业务场景贴合度和产品对效率的提升程度，凭主观臆想是B端产品设计的大忌。

那么怎么进行B端业务调研呢？应该准备什么呢？下面我就说一下我的一些经验：我先把调研分为整体业务调研（适用于初入公司或者作为乙方了解甲方问题）和具体功能调研（适用于某个功能或者模块的迭代优化调研）。

一、整体业务调研

1. 为什么要做整体业务调研？

整体业务调研会比较大且宽，适合整体上了解一个业务，比如入职新公司，负责新的业务线。这类调研其实就是让你自己对于整体业务流程有个大方向的掌握。方便之后详细功能调研的时候，和业务方的理解一致。

2. 要了解哪些方面？

①组织架构和岗位职责和绩效考核规则

首先搞清楚组织架构和部门职责，才能更好的了解业务全貌，不疏漏重要部门和流程。

这一点上有的公司在新人培训的时候会专门有讲的，但是讲的可能会不太落地，也可以跟业务人员了解下她们眼中自己部门的职责和别的部门负责什么。

其次要搞清楚岗位设置及职责。这样才能理解用户分工，以及他们之间的协作和监督关系。这能帮助我们找到关键用户和关键环节，帮助我们提升产品设计的效率。

最后要关心每个岗位的绩效考核规则，绩效里面的数据反映了业务重点抓的方向。

【示例】

②业务概况

需要从整体上了解企业的经营模式和业务流程。比如销售管理系统：如果企业是制造业，销售部门的职责往往是做好渠道铺货工作，维持分销价格秩序，与生产部门协调好产品交付时间与质量；如果客户是经销型企业，那么引入有竞争力的商品，找到有意向购买的客户，并通过供应链做到不积压不缺货，才是经营的核心。

如果设计的是一套SAAS产品，不仅要梳理客户的经营策略，还要梳理整个行业的经营策略（保证标准化产品的普适性，整体规划好产品的拓展方向）。

一些常见的指标：销量（年销售额）、销售网络架构、战略方向、竞争对手。

产品经理不要局限于场景，不要局限于流程，应该站在企业经营的思路上去思考。就想需求需要知道用户的根本目的是什么一样。企业让你做事的根本目的是扩大企业销售额，是盈利。

③现有的系统

了解清楚目前有哪些系统，每个系统负责什么功能，如果有条件的话，亲自操作一下系统的功能，且拿到主要的表单字段。

④业务痛点和期望

业务期望不能漏掉，产品的上线最重要的是解决业务最关心的问题。

注意区分角色，获得不同角色的业务痛点和期望和优先级，这个有利于对后续的计划做整体规划。

⑤报表

报表是管理层关心数据的表现，反映了真正的整体业务方向。

比如你看到市场部门的数据是电话触达量，那么可能公司市场部目前只负责了清洗线索的作用，并没有为有效线索和线索质量负责。那么可能目前公司业务还是以销售为主，你可以根据这个推论再了解更多的信息。

⑥业务流程图

通过业务流程图详细的了解业务情况。知道系统或者功能目前处于哪个环节，解决了哪些问题。

来源：可以是业务本身就有，或者愿意提供对应的资料。也可以是自己调研后输出的结果（如果是自己输出的，需要找业务确认1~2次）。

注意自己绘制的好处：需要绘制具体的业务流程图，再好的聊天也不如动手画出来整体的业务流程，涉及到哪些系统，做哪些主要的操作。画的时候你自然而然的会产生一些问题帮助你更好的理解。

【示例】

二、具体功能调研

上图是整个需求流程，这个流程可以看出需求调研所处的位置和重要性。

1. 为什么要做具体功能调研？

详细功能调研针对具体需求和问题进行调研。这类在精不在广，通过深入挖掘业务问题，首先在需求上线前能借助调研结论输出产品方案，其次需求上线后能主观的验证产品方案是否实现预期效果。

2. 调研阶段

类比于社会学上的调研，需求调研可分为4个先后的阶段。

1. 需求早期：具有探索性质，重点在于从用户角度收集领域知识，广泛而开放地讨论问题，较少深究细节。

2. 需求中期：用户模式初步显现，设计师开始提出开放式和明确的问题，形成初步轮廓，问题更关注细节。

3. 需求后期：用先前收集到的信息，对功能和需求进行假设性访谈。封闭性问题大量增加。

4. 需求上线：主要为了验证效果，确认用户的问题是否解决，使用情况是否如预期。

3. 要了解哪些内容？

类似于整体业务调研，具体需求调研也包含下面几个内容：

• 业务流程：通过业务流程图详细的了解业务情况。知道功能目前处于哪个环节，解决了哪些问题。

• 目前存在的问题：用户描述清楚目前的问题，结合具体使用场景来理解问题。

• 根本目的：找到用户的根本目的，不要关注用户给的”方案“，关注目的。

• 现状：目前是怎么解决的，使用什么方式

• 用户期望：记录用户希望的结果，避免需求偏离方向。

4. 需要注意哪些调研原则？

虽然调研内容是类似的，但具体需求调研需要关注更多的细节，更深挖，这些细节可以汇总成一些基本的调研原则。

下面列出了我觉得比较重要的原则（建议多看about face这本书）

①原则一、在交互发生的地方进行访谈

遵循上下文调查的首要原则，进行访谈的地方位于用户实际使用产品的地方非常重要，这不仅可以让我们有机会观察到正在使用的产品，也了解交互发生的环境，从而可以更深入的洞察产品的约束条件和用户需求和目标。

近距离的观察环境可能发现访谈者之前没有提到的任务线索，例如，注意一下他们需要的信息类型（桌面上的纸张或者屏幕边缘的便条），不充分的系统（手头参考资料和用户手册），任务的频率和优先级（收件箱和发件箱），他们遵循的工作流类型（备忘录、图标、日历）。

②原则二、避免一组固定问题

使用固定一组问题，不仅冒着疏远访谈对象的风险，而且可能错失丰富而有价值的用户数据。

调研的整个前提是，作为调查者，我们是无法充分了解领域，去预先假定我们要问的问题。我们必须从访谈者那里了解到哪些是重要的。这意味着心中知道某些问题类型非常有用。

这里有些面向目标的问题非常有用。

• 【机会、诉求】当前有什么活动在浪费你的时间？？？

• 【目标】什么事情会使你一天过的很愉快或者很糟糕？？？

• 【优先级】哪些是最重要的？

• 【信息】什么帮助你做决定？

还有一些面向系统的问题：

• 【功能】你使用产品做得最多的事情是什么

• 【频率】产品哪些功能你用的最多

• 【偏好】系统哪些地方你最喜欢

• 【失败】你如何解决遇到的问题（目前系统不能满足）

• 【经验】你使用什么快捷键

对于商业产品，面向工作流的问题会很有帮助。

• 【过程】你一早上过来，做的第一件事是什么？之后呢？

• 【发生的事情和循环】这件事多久做一次？什么事情每周或者每月做一次？

• 【特殊情况】典型的一天如何度过？什么会是不寻常的事情？

为了更好的理解用户的动机，问一些面向态度的问题：

• 【期望】你如何看待五年后的情景

• 【避免】你不愿意做什么？什么事情你在拖延？

• 【动机】关于你的工作，什么是你最满意的？什么是你最先开始解决的？

③原则三、首先关注目标，任务其次

首先要理解用户行为的原因，是什么激发了不同角色个体的行为，他们想达到的目标是什么。—-最重要的不是关注他们的任务！！！理解用户是重要的，而且任务必须仔细记录，但是这些任务也会进行调整，以便于达到最终的目标。

④原则四、避免让用户成为设计师

要引导用户一起进行问题研究，但是避免探讨解决方案。一般用户给的解决方案只是对他本人比较好，一些特殊的方法，没有经过深思熟虑。只要记录下来，表示会参考即可。如果用户说了，可以使用，这样的设计如何帮助你，这样的问题把用户拉回讨论。

⑤原则五、避免讨论技术性问题

不要让用户过多的关注是否可实现，而是关注于自己到底想要什么，想解决什么问题。

⑥原则六、鼓励讲故事

鼓励用户讲自己的体验小故事：如何使用它，对它怎么看，使用的售后还会与其他人产生什么交互，在什么场景下使用它。用户故事能够帮助我们更好的理解用户的诉求。

⑦原则七、请求演示和讲解

完成其他问题后，请求访谈者演示和讲解。记录下（最好拍摄）用户是如何使用产品的。

⑧原则八、避免诱导性问题

避免使用答案有引导性的问题。就想律师会利用他们的权威性，使用建议答案，无意识的使访谈对象产生偏见。例如：

• 是否X特性会对你有帮助？

• 你喜欢X功能，是吗？

• 如果能获得X特性，你认为自己会使用它？

⑨原则九、认为自己是个小白，而不是业务专家

放弃自己产品专家的身份，做一个小白。不要害怕问一些非常简单和愚蠢的问题。当你问出这些问题的时候，他们会很乐于描述的更详细一些。做一个倾听者就好了。

⑩原则十、讨论中使用开放性的问题和封闭问题去引领讨论方向

开放性的问题鼓励用户多描述细节，当你需要获取更多的信息的时候，多使用此类问题，比如“what”“how”“why”。

封闭性的问题鼓励用户简短回复，当现在的讨论方向走偏的时候，或者你想暂停讨论，那么使用此类问题，比如“DID you”“would you”“Do you”。

综上所述，根据上面的内容和原则，希望你能更好的完成需求调研~

Remember：

永远提前准备好调研问题和文档，不要想当然的觉得自己已经很熟悉流程了，能现场发挥把握调研方向！

如果能参与其中（轮岗一段时间）比任何形式的调研都有效果，特别是在认识业务的初期。