B端设计师如何体系化了解业务？4个步骤快速搞定！

前言

接触 B 端设计的小伙伴会发现，很多业务具有角色多，业务场景复杂，功能链路长等特点，所以在工作中会经常遇到以下几个问题：

1. 突然被调配到新业务，拿到一个不熟悉的业务或者新产品，不知如何开展工作？
2. 换了一个新行业，面对一个从 0 —1 的新项目，应当如何熟悉新业务？
3. 面对较为复杂的业务，经常和业务方沟通讨论不在一个频道，又不知如何着手。

本文将从以下 4 个角度展开探讨，当设计师面对 B 端新业务时，应当如何快速熟悉业务并开展工作。

类似方法；

一、查行业和竞品

首先，不要一上来就急着看系统。线上的功能模块只是实现需求和业务目标的手段，并不一定是最优解，能够为客户解决问题的方式有很多，不一定非得是我们提供的互联网服务。所以如果我们一上来就着急走数据看系统，很容易就会把自己的眼界，局限于这些产品的功能界面中。

1. 查行业报告

首先需要明白自己从事的是一个什么行业，这个行业叫什么，是做消费品的、是酒旅还是建筑地产等。提供企业服务有做 saas 的、有做 Pass 的、有做平台数据对接的、也有本公司自研系统，第一步要建立起对这个行业有一个宏观的认识。

通过市面上的这些行业分析报告，可以了解到自己做的业务处在哪一个赛道，另一方面也能大概知道目前所做业务，在市场处在生命周期的哪一个阶段。比如下文就是艾瑞咨询关于中国 SaaS 产品的一个图谱，通过这些图谱不光可以了解我们公司产品所处地位，也能纵向知道公司产品的竞争对手有哪些。比如为企业提供 saas 零售电商服务的就有微盟、有赞、小鹅通等服务工具。

想了解这方面资料的同学，可以通过艾瑞咨询查看：https://www.iresearch.com.cn/

2. 查行业竞品

看竞品不仅是要看产品本身，还要比较它的行业地位，需要了解我们的产品在大背景下，处于一个什么地位，是行业头部，还是在追赶地位。同时，还要关注产品背靠的资源和竞品相比有哪些区别。比如这两年大火的 Scrm 运营工具——微盟的企微助手，背靠的资源就是过去几年通过商城零售产品积累的客户。以及微盟于2022年发布的WOS新商业操作系统中，企微助手与微盟其他产品的超强融合能力。

关于行业竞品，需要大家花点时间找一找，也可以通过相关的负责人问一问。这里推荐通过以下两个网站查询：

1. 36Kr 企服点评：https://www.36dianping.com/
2. 字母点评：https://www.zimudianping.com/#/

3. 查公司战略

了解公司战略并不是一句虚话，它涉及到你后期负责的业务的发展方向。比如微盟从 2020 年开始提出大客化战略方向，如果你是负责零售这一块的业务，你必须要知道你的客户群体是要以大客为主，大客和小客在需求痛点上是完全不一样的，所以这涉及到我们后期面对这些角色设计上的一些区别。

再比如微盟 2022 年新推出的 WOS 新商业操作系统 ，除了提供微盟的标准化产品解决方案外，还可以让更多的生态伙伴产品参与进来共建产品，包括 PaaS 平台，可以满足商家的个性化需求定制。这也会涉及到我们在产品设计，页面框架层搭建的兼容性，需考虑覆盖各类业务、以及产品对外的一致性等。

二、看产品和价值

看产品，是指看产品的业务文档，而不是看 prd 界面，需要了解产品的核心价值和目标客户群体。这个阶段，需要看产品在什么样的场景下，帮助哪一类客户，解决什么痛点或者问题。这个阶段涉及产品一切的文档资料，包括业务背景、需求文档、宣传文档、产品白皮书、销售资料和公众号等，我们都需要尽可能多的，主动性去找相关资料和数据查看。

1. 看产品的专业词汇

很多 B 端产品都是服务于很垂直的领域，所以不免涉及到专业领域的一些词汇。比如 CDP 产品，我们在了解这个产品时，需要知道一些基本概念，比如什么是多渠道标签，标签的类型有哪些，什么是文本标签、多值标签、日期标签等；用户分群里的人群包、自定义人群和系统人群，以及常说的圈人条件是指什么。

如果我们发现自己的产品还没有整理这些信息，我们可以通过竞品的官网，或者到竞品的用户手册、帮助中心等模块找到这些信息。我们还是拿 CDP 举例，下方就是就是火山引擎和 Growing IO 的帮助文档，熟悉了这些专业词汇，可以让我们可以更快的了解产品，当然如果你有时间，也可以帮助自己的产品去整理这一份文档。

2. 看产品的价值

怎么去看一个产品的价值点，这个较为复杂，我们可以借用一个工具叫价值主张画布（The Value Proposition Canvas），它可以帮助我们很好的去理解产品和目标群体之间的关系，清楚地描述出产品帮助客户解决了哪些问题，和创造了哪些收益。

价值主张画布内容较多，感兴趣的同学可以看一下《价值主张设计》这本书，这里我们简单总结分为「价值地图」与「客户洞察」两个板块。

价值地图：描述产品为客户创造的价值，包括产品与服务、创造价值、解决痛点

1. 产品服务：我们给客户提供的是一种什么样的产品或服务
2. 解决痛点：产品解决了用户的哪些难题
3. 创造价值：产品让客户获得哪些好处

客户洞察：帮助我们理解客户，包括客户的任务、客户的痛点以及客户的收益

1. 客户工作：是指客户利用系统要做哪些工作日常及事项
2. 客户痛点：客户在本来工作流程中遇到的问题及阻碍
3. 客户收益：指客户通过购买该系统，获得的盈利来源

三、理功能及流程

1. 理产品功能大图

一定要看核心业务或者产品功能的大图，理清业务功能模块、数据之间的来源去向关系，整个平台的数据是怎么流转的，以及最后是怎么形成逻辑闭环的。这时最好多向身边的同事多多请教，避免埋头苦干，可能自己纠结了半天的问题，可能都抵不过同事的一点点拨。

比如近两年大火的私域运营工具 SCRM，其核心本质是一个社交化的私域运营工具，其 PC 端功能主要分为 4 块，引流获客 — 促销运营 — 营销转化 — 决策管理，下图就是是微盟企微助手产品功能模块大图。

2. 理数据流程

业务流程相对是一件相对复杂的事情，不同产品的流程侧重点不一样，有些产品的流程会牵涉多个角色，这个时候需要找到对应产品负责人，要到不同权限角色的账号，因为不同权限角色的账号功能也不一样。有了账号，了解每一个功能菜单帮助客户解决了什么问题后，就可以建数据走流程了。

① 找到核心功能模块

首先找到该业务的核心功能并熟悉它。比如拿 SCRM 产品举例，微盟企微助手、微伴助手和微盛企微管家都将「活码」这个菜单功能排在头部位置，一方面是从产品的使用频率考虑，另一方面它也是产品的核心功能模块。怎么找到核心功能模块？你可以通过产品的导航、或者产品官网的介绍，找到产品的核心功能模块。

② 关注不同角色的工作

和 C 端产品不同，B 端产品角色相对固定，我们需要关注有哪些角色、角色之间的协同关系、工作的场景、目的和操作链路。概括起来有以下三个内容：角色信息、工作内容、考核指标。

1. 角色信息：包括角色名称、工作职责、能力维度等。比如 SCRM 产品会有老板、运营负责人、员工等角色。
2. 工作内容：具体场景、内容描述、目标和期望。比如老板会看整体数据及基本分析结果，运营负责人会维护整个系统的信息和数据分析，包括创建派发任务等，员工更看重任务完成等。
3. 考核指标：一般会结合任务而需要完成的考核指标，这个和每个产品的特性有关。

③ 体验并感受产品

在体验产品的过程中，把自己带入产品的角色中去，用我们专业的眼光走查一遍产品，比如产品的框架设计如何？里面操作流程是否符合用户认知？各功能模块的交互是否一致？是否会有操作的错误的判断可以结合自己的交互走查表，不过仍需注意，不要陷入到产品的细节体验中去，毕竟我们要做的是熟悉各个功能模块。

这样的好处，可以避免产品因历史的包袱问题而带来的眼界束缚，完全用一个全新的观念和心态体验新产品。在建数据流转的过程中，我们可以得到一个小白用户对于这个产品的使用体验，在使用的过程中，也可以记录下来自己的行为和感受。对于很多新的产品团队来说，一份新手用户对于产品的认知和体验感受也是一份宝贵的资料，因为等我们真正熟悉业务产品时，很有可能会忽视这些旧问题。

在建数据的过程中，可以结合之前相关业务文档一起看，一边走一边了解每个功能模块的前世今生和具体细节，同时产品的数据流转一定也要多走几次，尽可能理清数据业务的流转逻辑。

④ 特殊产品仍需和线下实践结合

有些特殊化的产品，流程比较复杂，需要亲身经历和体会。比如拿物流的 WMS 仓储系统来说，如果不到现场亲历入库、出库、盘点和分拣等实体操作，光通过系统和文档，很难知道现场作业人员的所思所想，和不同角色所要关注的点。

只有亲历了一遍现场以后，才会知道作业环境的嘈杂和混乱，所以有些特殊化的系统，还是需要自己体验走完一遍这个流程比较好，毕竟纸上得来终觉浅，绝知此事要躬行。

3. 理交互规范

有了对整个产品功能模块的了解，下面就是熟悉产品的交互框架，还有一些组件库。尽可能做到在实际设计时让这些组件做到复用，这样可以帮助我们节省很多时间，也可以避免很多交互上的错误。

四、问对人说对话

通过前面的一系列自主调研及建数据流转，对我们所要负责的业务有了一个较为清晰的认识，这中间我们也会产生很多问题，不免需要上下游的小伙伴们打交道，怎么和小伙伴沟通讨论仍需掌握一些方法。

1. 问对相关业务人

我们需要找到业务的关键人，特别是刚去一个新公司面对一个新业务的情况下，这个时候需要了解业务的人员组织架构，找到对应的负责人，当然我们不可能上来就让人家给我讲讲业务和人员架构。

1. 找到对应负责人。比如我们可以这么说，不知道你有没有时间，或者你是否能够推荐团队里面的大佬能够给我讲一下，以便我们后续更好的配合及开展工作。
2. 问问题不要过于笼统。在和对应的业务产品沟通的时候，你不能直接说，你能不能给我讲讲这个功能或者业务，这个问题太过于概括和开放，对方一下接不住这个问题。如果对方没有做准备，很有可能在他和你讲的过程中，还会涉及一大堆技术和行业词汇。

2. 说对话的一些有用技巧

1. 把问题整理好，可以集中性的问，不要一个个的去问，以便不停反复占用别用时间，毕竟谁也不喜欢不停地被人打扰。
2. 如果是一些抽象复杂的问题，提前发给人家，让对方也有个准备时间。
3. 在向别人请教的时候，如果能够带上纸笔作记录更好，以表示对别人的尊重，等到回到自己的工位后，也可以自己画出产品的业务的流转图，加深自己对于产品的理解。
4. 如果可以，给别人带上一杯奶茶啥的，毕竟没有人有义务无条件帮助你。

相关技巧：

关于新入职的同事，或者被调到一个新业务时，我们需要向当前业务骨干设计师请教业务问题时，也需要掌握一点说话技巧。我曾在群里看到一位前辈分享过一个表达话术，和大家分享下：

总结

关于了解业务，我们整体的思考框架是，先整体再局部从大到小，从行业入手了解行业竞品，产品是怎样的商业运转模式，再通过价值主张这个工具，了解产品各个功能模块的价值。

找到产品的对应负责人，了解业务或者产品的组织架构，知道产品的核心模块是哪些，清楚不同角色的之间的流转关系是怎样的，将角色之间的流程串联起来，就能够达至了解业务。最后，我们对产品的掌握了解差不多了，其他的非核心模块，可以在后期做项目的时候，一边做一边了解。

希望本文对你有所帮助。

参考文献

Yves Pigneur《价值主张设计》

欢迎关注作者微信公众号：「小高杂谈」