对于如何理解业务，应该是一个困扰着大多数 B 端设计师的问题。曾经初入B 端的我，多次在方案评审会上被质疑懂不懂业务？本文我想跟大家分享一些，我自己在 B 类设计中如何去了解业务的一些思路和见解。如有偏颇还请见谅！

对于初入 B 端设计的小伙伴来说，可以能有一个问题，那就是 B 端设计为什么要懂业务？这是因为 B 端产品存在明显的业务属性。在这里可以通过 B 端产品跟C 端产品的用户特征的比较来建立对 B 端产品的认知。

首先， C 端产品的服务用户通常是个体，是零散存在的。如果把 C 端的用户抽离成模型，会发现用户是「离散」的，那么在设计的过程中只要搞定这个单点的用户就可以了。

但是，对于 B 端产品来说，通常服务的是企业/组织，是集中存在的。如果把 B 端的用户抽象成模型，会发现这些用户通常是以「组织架构」的形式存在的。这样就会造成用户存在层级，从而导致决策链路较长，利害关系人较多的问题。那么这就需要在设计的过程中去搞定这一群人。

所以 B 端产品相比较于 C 端，「用户特征的差异形成了业务壁垒」。

B 端的用户更具有鲜明的「职业特征」和「行业属性」。

通常在设计 C 端产品的时候，可以很轻易的通过「共情」方式带入到产品的设计过程中。但是对于 B 端设计时这个方法却失效了，因为在产出设计方案时候，大概率的不可能去体验 B 端产品中的不同角色的工作流程和任务流程。因为 B 端产品的使用者遍布公司的各个层级，而作为设计师你也不可能有机会今天做一下财务工作，明天去体验一下老板如何管理公司。

所以作为 B 端产品的设计师，通常是通过「理解业务」然后去「理解需求」，来保证方案设计产出的有效性。而不理解业务的设计师，在方案产出的过程中非常容易与产品经理、业务方产生分歧，所以作为设计师要「理解业务」。

那业务到底是什么？作为设计师的该如何去理解业务呢？

站在设计师的角度，「业务」到底是什么，又该「如何去理解」呢？

在 B 端产品设计调研/需求会议时，通常会听见产品经理讲这个业务是什么什么一个情况，要解决什么；也会听见业务方讲做的是那个行业，这个行业是什么一个情况。那业务到底是什么？该如何去理解业务呢？

我们在聊业务的时候，到底是在聊什么？

通常在产品设计的过程中，把业务分解为「行业模式」和「业务流程」两个方面来讨论。那业务到底是什么？理解业务其实就是说：你既要懂这个行业的模式，还要懂这个企业的业务流程。

行业模式和业务流程是相辅相成的，行业模式模式是很直观的一种体现，更加的宏观，颗粒度会更粗；业务流程是具体到企业运转层面，更加的微观，颗粒度更细。一个企业的业务流程，在某种程度上是行业模式的具体体现；而行业模式其实更像企业业务运转的指南针，无论企业的业务流程如何运转，其实都离不开这个行业的框架和模式以及政策法规对这个行业的约束。

我们知道了业务是什么，那作为设计师理解这些业务有什么用呢？

可以从两个方面来看：

• 「懂行业模式」，可以理解行业现状，并且了解它的客观规律，从而避免出现设计目标与未来行业发展趋势偏离的状况；
• 「懂业务模式」，可以通过理解行业中某个企业业务运作流程，来还原场景，从而实现更好的方案产出，来满足需求。

理解了业务是什么以及作为设计师为什么去理解业务，接下来我们讨论一些该如何快速的去理解业务。这这里把这个过程拆分为两步：

• 第一步是理解行业；
• 第二步是理清业务。

关于行业，在这里我想给大家提供的是一个行业分析的思路与框架，而不是从0-1的去如何分析一个行业。大家可以基于这个框架进行自身/企业/客户所在行业的分析与研究。

对于行业首先要了解行业的类别有哪些？其实对行业的分类有很多，通常行业分类从区分目的来说有两大类：管理型和投资型。可以参考联合国的国际标准产业分类和中国统计局国民经济行业分类标准对行业的划分进行基础的了解。

作为 B 端产品的设计师，该如何去快速了解一个行业呢？对于行业分析来说，有很多成熟的方法与策略，而且每个方法都按照不同的方法和思路去分析，但是通过一些实践之后，发现这些分析更多偏向战略层，更多的是需要产品经理去做的事情，而对于设计师来说投入巨大的精力和时间去进行分析总结反而有些本末倒置。

根据设计实践，提取和总结 B 端设计师需要关注行业信息，并把他们划分为 3 个维度，分别是行业的边界、行业的演变和行业的竞争。设计师，可以通过针对性调研，快速构建起对行业的认知，从而产出符合需求的设计方案。

行业边界是企业/客户的价值取向。通常以企业/客户的追求为原点，以企业/客户的能力为半径，去画一个圆。那么在对行业的边界进行理解的过程中，通常需要理解：

• 行业的定义和政策法规
• 提供的产品与服务是什么

在理解行业的定义和政策法规这一条中，需要明确「行业在解决什么问题的」和「政策法规允许哪些可以做、哪些鼓励做、哪些必须做和哪些不能做」。

理解提供的产品和服务是什么这一条，需要明确当前「行业中普遍存在的产品和服务是什么」。

行业的演变代表的行业的历史状态与未来的发展方向。需要找到行业的演变史，从中看到行业发展与趋势。同时推演的出不是行业阶段解决方案的变革与演化。这有助于在产品的设计过程中，找到新的突破口至关重要。

在这个过程中，需要找寻到「行业的历史发展路径」、「未来趋势」、「解决方案变化状态」，然后明确「行业当前处于什么发展阶段」、「未来会往哪些方向发展」、「发展过程中解决方法都经历了哪些变化」。以帮助我们理解这个行业的演变。

竞争是在商业环境下不可不可避免的。作为 B 类业务的设计师，要对行业中的上下游供应链和竞品解决方案做到心中有数，从而避免闭门造车的尴尬。

对于上下游供应链，需要明确公司/客户当前处于上下游供应链的那个位置，能不能向上或者向下拓展。

对于竞品解决方案，由于 B 类业务的复杂性和独特性，通常不太容易获取到相关的解决方案。但是可以通过竞品的展销会和官网进行相应的推导。对于一些成熟且小众的行业，我们可以去查阅国标文件来建立相关认知。

如果可以找到相应的竞品，就需要总结「竞品都有哪些」并进行一个曾经的划分，然后选取相应的竞品来对比他们之间的差异化是什么，跟你当前的产品有何异同。

前面探讨了如何快速的了解一个行业，接下来聊一下，当进入一家公司或者接触到新的客户时，该如何快速的理解业务流程和业务情境。作为设计师，必须对公司/客户的业务有一个清晰的理解，而不仅仅是当前工作的部分。设计师具体的工作需要与业务的目标相匹配，作为设计师要系统的思考和理解公司/客户的全部价值观，进而发现和产出更具价值的设计方案。

成功的 B 端产品，往往是由需求（用户/客户的想法和需求是什么？）主导的，同时兼顾总体的可行性（能否执行？）和生存能力（是否理解业务？）。作为 B 端设计师从项目的一开始就要对整体的业务流程有一个总体的认知，这有助于判断客户/用户的需求是否能在实际中得到满足，以及理解他们为什么有这样的需求。

在设计的过程中要让用户、业务和技术需求之间达到平衡，才能够让设计出的产品/方案更具竞争力。因此，需要设计工作开始之前就要对整个组织的产品和服务进行了解。

通常进入企业或者接受项目的时候，产品经理或客户会提供给一些相应的资料，需要从这些资料中快速的捕捉或提取出重要的信息以便在后续的讨论中能够与产品/客户保持一致。

理解公司/客户的业务，就意味着需要进行一些调研&研究。通常会按照企业/客户的业务领域-涉及的角色-业务流程这个框架进行调研和研究。来进行快速建立对公司/客户业务的认知。

对于这些信息看起来应该是产品经理或者业务经理的事情，但是作为 B 端设计要扮演多种角色，需要明确项目的目标，特别是在复杂 B 类产品和业务目标比较广阔的情况下更要深入到业务中去才能产出优秀的解决方案。

这个框架有助于设计师理解项目对公司/客户的重要性，以及了解公司/客户如何衡量项目是否成功。通过这个框架可以快速的抽离出影响设计决策的关键信息，这就会使方案产出站在一个更加有利的位置，便于针对整个项目的不同阶段采取最合适方法，产出最合适的方案。

接下来让我们一起来探讨该框架下不同部分的细节。

4.1 业务领域

对于业务领域，通常会在产品给出的文档或者项目启动会议相关的文档中得到。这些文档通常宏大而宽泛，需要在这些文档中快速抽离出为客户/用户提供的产品和服务，为什么这些产品和服务最终可以和竞争对手区分开来。

这个过程可以理解为为你的业务构建画像，使用构建业务故事的方式来建立业务画像。需要回答

为了解决/达到（什么目的），我们设计/构建一个（什么样的）体系/系统，可以（帮助公司/客户达到什么目标）。

同时通过设计实践总结了一些相关问题来帮助设计师去进一步明确公司/客户业务的画像：

• 公司/客户的主要产品和服务是什么？
• 产品或服务可以帮助客户/用户解决什么问题？
• 向什么样的群体提供什么样的产品和服务？
• 类似业务模式的竞品是谁？
• 公司/客户通过创造什么样的价值来与竞品区分？
• 公司/客户的产品和服务解决了哪些需求？
• 公司/客户的产品和服务给用户造成了哪些麻烦？
• 公司/客户的产品和服务为用户创造了哪些价值？

通过上述问题，会对公司/客户业务画像有一个基本的认知，虽然不是特别具体但是初始的印象，接下来会更深入的了解。

4.2 角色

角色是 B 端产品中的重要的构成要素，也是业务运作流程中必不可少的。在这个过程中要快速抽离出业务中的「决策链路」以及「角色」不同的特征。例如，角色之间的从属关系？这个角色主要负责什么？他 /她的工作是什么？他/她的业务目标是什么？

整理的关键点是，该如何找到这些角色并建立决策链路？对于如何找到这些角色，通常会使用两种方法：

1、分析企业/客户的组织架构得出涉及的相关角色，看到整个企业/客户的组织的大致分工都有哪些。

例如，销售部门分为销售支持、销售、运营等；只能部门财务、行政、人事等。我们可以通过组织架构快速了解企业/客户业务涉及的角色，以及一些关键的决策点。

这其实是一种不太需要投入资源，就可以得出一个大致的模型。我们拿到这个相对粗略的模型之后，我们还是要跟公司/客户相关人员进行一个信息的确认，以保证你信息的有效性。

2、参考类似企业/客户组织架构来得出相关角色。

这种方法，通常用在接手一个相对陌生或者公司/客户不能向你提供，你也无法获取到内部的组织架构时，就可以用参考类似企业/客户来看他的角色都有哪些。

在选择这些企业的时候我们要选择类似的标杆企业/客户，因为在某种程度上讲，他们之所成为标杆，模式是已经被验证过的。

4.3 业务流程

需要先来了解公司/客户的业务架构。找到并理解业务架构不仅可以对公司/客户的产品和服务有更好的了解，还能掌握相关活动、资源和合作方，以便后续的流程设计中更加匹配业务。

对于框架和获得，通常是由产品/业务方提供，如果实际工作中没有提供，我们可以通过搜索行业内的标杆企业，通过标杆企业来获得。

获得业务架构后，需要回答以下问题来帮助我们理解公司/客户业务架构中的细节：

• 什么关键活动可以为公司/客户创造收益
• 为了给用户创造价值，必须具备哪些资源（人力、财力、物力）
• 向用户提供产品和服务时，有哪些关键的合作伙伴或供应商
• 这些合作伙伴或供应商在产品和服务中扮演或从事哪个关键活动

最后要对整个业务运转流程有一个清晰的认知。

业务流程，通常会有产品提供。但是由于 B 类业务的复杂性和多样性，有时候我们紧紧靠产品提供的信息是无法产出有效的方案，这是就需要设计师亲自下场，对业务流程进行设计研究。

由于 B 类业务具有非常强的业务壁垒，那么「观察法」和「体验法」对于理解 B 类业务流程更加的有效直观。

通过观察的方式，可以帮助更好还原业务。在实际工作中使用的观察法有两种方式：

1、驻场：可以深入到业务需求方的工作场景，观察他们平时的工作方式。通常在这个过程中需要关注的是：

• 角色的工作流是什么样子的？有没有SOP？
• 在什么样的情境下，执行了哪些任务，完成了什么业务目标

当然这种方式成本很大，也不是所有的客户都会支持。所以实在不行跟业务方沟通让对方派一些资深的工作人员带我们体验业务流程。

2、资深业务人员带领体验：由资深的一线工作人员指导下，上手体验业务方的工作。

除了这观察法，还可以通过用户调研进行辅助和补充业务细节具体流程就不在这里展开了。

对业务的理解，需要循序渐进。本文阐述的方法与理论仅仅能够帮助你在接触到新的业务时快速的切入业务，实现有效的的方案产出，而非一日功成的「武林秘籍」。对于业务的理解和深入，是要依靠各位小伙伴的长时间的积累和洞察。另外，本文阐述的方法与理论还在不断迭代之中，如有一些谬误和不合理的问题还请多多包涵。希望能够给给各位从事 B 类业务的小伙伴一些帮助。

「1」Jodie Moule（澳）.用户体验设计成功之道「M」.北京：人民邮电出版社，2014

「2」唐纳德·高斯，杰拉尔德·温伯格.从需求到设计：如何设计出客户想要的产品「M」.台北：经济新潮社，2017

「3」林宏远（汤圆）.B端产品设计实战思维「EB/OL」，2022

「4」程功夫.SaaS 产品经理的从业之道「EB/OL」，2020