如何理解复杂的B端业务

背景

众所周知，消费互联网红利已见顶，曾经的C端产品补贴大战的场面可能以后都很难看到，当前产品获取用户的成本已经越来越高。人口红利的消失加之劳动力成本的不断攀升，让过去粗放式的增长模式越来越难以适应新的市场环境，尤其在互联网行业，当风口变短，裁员潮的背后大多存在着盲目扩张的情况，精细化管理已经势在必行。

2018年2C互联网巨头在企业服务市场动作频繁，腾讯、美团、阿里、百度四家公司相继宣布进行组织架构调整，B端产品的发展和被重视已经非常明显。

可是，对于很多设计师来说，遇上B端产品往往有点不知所措，业务太复杂了。

2020H1，我接手了一条新的业务线（原BD业务，现KuBOSS系统），是一个面向公司内部角色用户，辅助SaaS商业化，集客户、订单、商品、交易、运营、销售、结算、数据等为一体的十分复杂的系统产品。

面对这样复杂的B端产品，光去理解业务就是一个很难的问题。经过一些时间的了解和整理，我主要从业务和用户的角度，尝试着抽象总结一些方法，辅助大家去理解复杂的B端业务。

B端产品的特点

企业级B端产品，由于系统的复杂性和行业领域的专业性，我们设计师对用户、业务、产品等分析难度都会远远高于C端产品。并且由于B端用户往往是一个企业中的某一类角色，我们平时鲜有机会接触，无法使用设计C端产品时的同理心来对待。而且有些企业产品技术术语层出不穷，场景复杂交错，角色五花八门，存在很高的业务知识壁垒。当我们对业务理解不够深入，会直接影响到设计解决方案的深度和广度。

总结而言，B端产品往往：

1.角色多，场景互相交织

2.操作链路长，业务复杂

3.技术壁垒高，名词无法理解

B端产品的业务理解思路--以“任务”为视角

既然B端产品这么复杂，那我们该如何下手呢？

其实，不管是B端产品还是C端产品，设计的价值都是在于解决问题，提升产品体验性能和感官升级，设计的方式方法是相通的。差别在于，C端产品从用户视角出发，关注用户个人的场景、诉求、痛点和情绪，核心是满足用户的需求，关注用户的年龄、性别、收入、个性、习惯、消费模式等标签。

但是在B端产品中，我们抛开了用户作为个人存在的标签，我们更关注用户所代表的角色，它在工作场景中需要完成哪些任务，这些任务要做什么的，有什么目的，它使用什么工具，要去完成什么事情，需要跟其他角色配合吗等信息.

业务=商业+任务。

即为了达成某一商业目标需要执行的任务或工作项。

对业务的理解通常有三个层级：

1.页面级：落实到字段、按钮、基础组件等设计细节；

2.系统级：理解角色与信息架构的关系，功能的网状关系；

3.行业级：战略层的思考，商业目标的了解，业务上下游闭环的链接；

从任务视角出发，是我们解开复杂的B端业务的一个突破口，我们去看看到底有哪些人分别在做什么任务。

“任务”视角下的用户角色分析

提到角色分析，大家可能更多的听说是”用户画像”，用户角色跟用户画像有差别吗？

用户画像的正式名称是User Profile，大家往往把它和User Persona混淆，后者更恰当的名字是用户角色，是产品设计和用户调研的一种方式方法。当我们讨论产品、需求、场景、用户体验的时候，往往需要将焦点聚集在某类人群上，用户角色便是一种抽象的方法，是目标用户的集合。

由于B端产品通常要解决的是某类角色工作时发生的问题，我们不需要对用户自我本身做过多的社会、兴趣、行为等分析。我们更关注角色的分类、工作的场景、目的、操作链路、角色协同等信息，而且用户角色的属性往往相对比较固定，甚至同行业公司之间的差异也较小，与公司的整体组织架构相关。

注释：(User Profile用户画像，更多被运营和数据分析师使用，它是各类描述用户数据的变量集合。在大数据时代，企业通过对海量数据信息进行清洗、聚类、分析，将数据抽象成标签，再利用这些标签将用户形象具体化的过程。

个性化推荐、广告系统、活动营销、内容推荐、兴趣偏好都是基于用户画像的应用。当我们想要选择某部分用户群体做精细化运营时，会用用户画像筛选出特定的群体。

用户画像是一个复杂的系统，随着产品逐渐成熟，会根据不同的业务场景设计不同的标签，用户角色是精炼和概括，而用户画像需要齐全）

“任务”视角下的用户角色分析，重点应该关注：角色基本信息、工作任务内容、考核指标。

1.基本信息：包括了角色名称、工作职责、工作感受、能力维度等；

2.工作任务内容：包括了情景、内容描述、目标、痛点和期望；

3.考核指标：B端角色通常是企业员工，为了薪酬，所有一般都会有结合任务而完成的考核指标，了解考核指标可以在设计过程中更明确知道哪些内容是用户最关注的东西；

以我所负责的KuBOSS系统为例：

当我刚接手这个系统时，我从产品处得知了该系统有非常非常多的角色在使用，比如：CSC、CSM、财务、培训师、模型运营、销售、市场策划、商务支持、还有各类主管和总监等。那时的我面对这样一个用户角色如此多样并且根本不知道他们是做什么的，而且产品功能数量又如此庞大的产品，根本无从下手。

原BD系统（部分信息已做模糊处理）

我的策略是采用从“任务”视角的用户角色分析法出发，先从了解用户开始。从产品处得知，我们的用户最核心及最大的两类是CSC、CSM。由于当前没有数据埋点，我更多的是采用定性分析法，基于任务视角的用户角色，制定访谈问卷，联系用户，深度访谈后汇总和抽象整理信息，得出我对CSC、CSM两大核心角色的画像，并且得到了用户吐槽最多的可优化点，然后推动至业务组，push产品对优化点进行排期规划，对产品的体验优化起到了很棒的作用。

（用户画像部分信息已做模糊处理）

后续用同样的方式，我将对其他角色也进行汇总整理，让我对各角色的职责和日常工作场景起到一定的了解。

如何将带有很多不同任务的角色再深入运用至理解业务中？

当你得到一个又一个用户角色画像后，你对产品和业务的理解会逐渐有个似懂非懂的模糊印象，但是这个认知还处在一个点的散状分布，你需要理出一条脉络，即主线，将你的点状的多个任务和用户角色串联起来，形成一个体系化的结构状态。

那么怎么去梳理出这条主线呢？？

任何一家商业公司的目的本质是盈利。我们需要知道我们所负责的产品或业务线是如何实现或者辅助商业化变现的。基于此，我觉得可以从三个维度去思考这条业务主线是什么：

1.产品价值定义；

2.抽象业务模型；

3.业务协作规则；

产品价值定义：

与产品沟通、与业务方沟通、桌面研究等一切能获取信息的渠道，沉淀和总结出你负责的产品所承载的价值是什么，了解产品在商业化中扮演什么角色。

比如我所负责的KuBOSS系统，它是辅助公司商业化的支撑系统，可以总结出产品形态图，从整体上去了解该产品能提供什么能力。

抽象业务模型：

企业级B端产品往往会存在很多独立的业务个体。比如订单、客户、模型、方案、工单、培训等，我们可以选择某个业务个体出发，串联上下游的关系，结合任务视角的角色分析，了解该业务个体在整个生命周期中的情况。

以KuBOSS举例，当我们拿最核心的“客户”作为一个业务个体出发，它的整个生命周期为：自然流量-leads-意向客户-客户-断约/续约客户。即，我们可知道我们的主线是围绕着客户的整个生命周期去管理和服务，目标是获取更多的客户，并且不让客户断约。

业务协作规则：

当我们已经知道“客户”这个个体的业务模型后，基于“客户”的生命周期，串联任务视角下的角色，了解各角色是如何协作的，得出客户服务的协作关系图：

（协作关系图已做脱敏处理）

并且，基于这样的协作规则，我们将客户服务关系映射到系统的产品架构中，整理出业务的解构图，并且业务与产品形态划分是一一对应的关系。

（业务解构图已做脱敏处理）

这个例子是围绕“客户”这个业务个体抽象的业务模型和协作规则。任何一个个体我们都可以按此方法抽象整理。产品是不同的，但是方法是相通的。

总结

从任务视角出发了解用户，然后再将任务和角色串联到单个的业务模型中去，慢慢的就能对复杂的B端业务有个了解。之后我可能会再来探讨一下，B端的产品在设计表现上应该要注意什么，或者B端产品该怎么去度量设计价值等等。希望有机会再跟大家多多交流。

作者：莫提