接触 B 端设计小伙伴会发现，很多业务具有角色多、业务场景复杂、功能链路长等特点，所以在工作中会经常遇到以下几个问题：
本文将从以下 4 个角度展开探讨，当设计师面对B端新业务时，应当如何快速熟悉业务并开展工作。
首先，不要一上来就急着看系统。线上的功能模块只是实现需求和业务目标的手段，并不一定是最优解，能够为客户解决问题的方式有很多，不一定非得是我们提供的互联网服务。所以如果我们一上来就着急走数据看系统，很容易就会把自己的眼界，局限于这些产品的功能界面中。
首先需要明白自己从事的是一个什么行业，这个行业叫什么，是做消费品的、是酒旅还是建筑地产等。提供企业服务有做SaaS的，有做PaaS的，有做平台数据对接的，也有本公司自研系统，第一步要建立起对这个行业有一个宏观的认识。
通过市面上的这些行业分析报告，可以了解到自己做的业务处在哪一个赛道，另一方面也能大概知道目前所做业务，在市场处在生命周期的哪一个阶段。比如下文就是艾瑞咨询关于中国SaaS 产品的一个图谱，通过这些图谱不光可以了解我们公司产品所处地位，也能纵向知道公司产品的竞争对手有哪些。比如为企业提供SaaS零售电商服务的就有微盟、有赞、小鹅通等服务工具。
看竞品不仅是要看产品本身，还要比较它的行业地位，需要了解我们的产品在大背景下，处于一个什么地位，是行业头部，还是在追赶地位。同时，还要关注产品背靠的资源和竞品相比有哪些区别。比如这两年大火的Scrm运营工具——微盟的企微助手，背靠的资源就是过去几年通过商城零售产品积累的客户。以及微盟于2022年发布的WOS新商业操作系统中，企微助手与微盟其他产品的超强融合能力。
关于行业竞品，需要大家花点时间找一找，也可以通过相关的负责人问一问。
了解公司战略并不是一句虚话，它涉及到你后期负责的业务的发展方向。比如微盟从2020年开始提出大客化战略方向，如果你是负责零售这一块的业务，你必须要知道你的客户群体是要以大客为主，大客和小客在需求痛点上是完全不一样的，所以这涉及到我们后期面对这些角色设计上的一些区别。
再比如微盟2022年新推出的WOS新商业操作系统 ，除了提供微盟的标准化产品解决方案外，还可以让更多的生态伙伴产品参与进来共建产品，包括 PaaS 平台，可以满足商家的个性化需求定制。这也会涉及到我们在产品设计，页面框架层搭建的兼容性，需考虑覆盖各类业务、以及产品对外的一致性等。
看产品，是指看产品的业务文档，而不是看prd界面，需要了解产品的核心价值和目标客户群体。这个阶段，需要看产品在什么样的场景下，帮助哪一类客户，解决什么痛点或者问题。这个阶段涉及产品一切的文档资料，包括业务背景、需求文档、宣传文档、产品白皮书、销售资料和公众号等，我们都需要尽可能多的，主动性去找相关资料和数据查看。
很多B端产品都是服务于很垂直的领域，所以不免涉及到专业领域的一些词汇。比如CDP产品，我们在了解这个产品时，需要知道一些基本概念，比如什么是多渠道标签，标签的类型有哪些，什么是文本标签、多值标签、日期标签等；用户分群里的人群包、自定义人群和系统人群，以及常说的圈人条件是指什么。
如果我们发现自己的产品还没有整理这些信息，我们可以通过竞品的官网，或者到竞品的用户手册、帮助中心等模块找到这些信息。我们还是拿 CDP 举例，下方就是就是火山引擎和 Growing IO 的帮助文档，熟悉了这些专业词汇，可以让我们可以更快的了解产品，当然如果你有时间，也可以帮助自己的产品去整理这一份文档。
怎么去看一个产品的价值点，这个较为复杂，我们可以借用一个工具叫价值主张画布（The Value Proposition Canvas），它可以帮助我们很好的去理解产品和目标群体之间的关系，清楚地描述出产品帮助客户解决了哪些问题，和创造了哪些收益。
价值主张画布内容较多，感兴趣的同学可以看一下《价值主张设计》这本书，这里我们简单总结分为【价值地图】与【客户洞察】两个板块。
1）价值地图
描述产品为客户创造的价值，包括产品与服务、创造价值、解决痛点。
2）客户洞察
帮助我们理解客户，包括客户的任务、客户的痛点以及客户的收益。
一定要看核心业务或者产品功能的大图，理清业务功能模块、数据之间的来源去向关系，整个平台的数据是怎么流转的，以及最后是怎么形成逻辑闭环的。这时最好多向身边的同事多多请教，避免埋头苦干，可能自己纠结了半天的问题，可能都抵不过同事的一点点拨。
比如近两年大火的私域运营工具SCRM ，其核心本质是一个社交化的私域运营工具，其PC端功能主要分为4块，引流获客 — 促销运营 — 营销转化 — 决策管理，下图就是是微盟企微助手产品功能模块大图。
业务流程相对是一件相对复杂的事情，不同产品的流程侧重点不一样，有些产品的流程会牵涉多个角色，这个时候需要找到对应产品负责人，要到不同权限角色的账号，因为不同权限角色的账号功能也不一样。有了账号，了解每一个功能菜单帮助客户解决了什么问题后，就可以建数据走流程了。
1）找到核心功能模块
首先找到该业务的核心功能并熟悉它。比如拿SCRM产品举例，微盟企微助手、微伴助手和微盛企微管家都将【活码】这个菜单功能排在头部位置，一方面是从产品的使用频率考虑，另一方面它也是产品的核心功能模块。怎么找到核心功能模块？你可以通过产品的导航、或者产品官网的介绍，找到产品的核心功能模块。
2）关注不同角色的工作
和C端产品不同，B端产品角色相对固定，我们需要关注有哪些角色、角色之间的协同关系、工作的场景、目的和操作链路。概括起来有以下三个内容：角色信息、工作内容、考核指标。
3）体验并感受产品
在体验产品的过程中，把自己带入产品的角色中去，用我们专业的眼光走查一遍产品，比如产品的框架设计如何？里面操作流程是否符合用户认知？各功能模块的交互是否一致？是否会有操作的错误的判断可以结合自己的交互走查表，不过仍需注意，不要陷入到产品的细节体验中去，毕竟我们要做的是熟悉各个功能模块。
这样的好处，可以避免产品因历史的包袱问题而带来的眼界束缚，完全用一个全新的观念和心态体验新产品。在建数据流转的过程中，我们可以得到一个小白用户对于这个产品的使用体验，在使用的过程中，也可以记录下来自己的行为和感受。对于很多新的产品团队来说，一份新手用户对于产品的认知和体验感受也是一份宝贵的资料，因为等我们真正熟悉业务产品时，很有可能会忽视这些旧问题。
在建数据的过程中，可以结合之前相关业务文档一起看，一边走一边了解每个功能模块的前世今生和具体细节，同时产品的数据流转一定也要多走几次，尽可能理清数据业务的流转逻辑。
4）特殊产品仍需和线下实践结合
有些特殊化的产品，流程比较复杂，需要亲身经历和体会。比如拿物流的WMS仓储系统来说，如果不到现场亲历入库、出库、盘点和分拣等实体操作，光通过系统和文档，很难知道现场作业人员的所思所想，和不同角色所要关注的点。
只有亲历了一遍现场以后，才会知道作业环境的嘈杂和混乱，所以有些特殊化的系统，还是需要自己体验走完一遍这个流程比较好，毕竟纸上得来终觉浅，绝知此事要躬行。
有了对整个产品功能模块的了解，下面就是熟悉产品的交互框架，还有一些组件库。尽可能做到在实际设计时让这些组件做到复用，这样可以帮助我们节省很多时间，也可以避免很多交互上的错误。
通过前面的一系列自主调研及建数据流转，对我们所要负责的业务有了一个较为清晰的认识，这中间我们也会产生很多问题，不免需要上下游的小伙伴们打交道，怎么和小伙伴沟通讨论仍需掌握一些方法。
我们需要找到业务的关键人，特别是刚去一个新公司面对一个新业务的情况下，这个时候需要了解业务的人员组织架构，找到对应的负责人，当然我们不可能上来就让人家给我讲讲业务和人员架构。
1）找到对应负责人
比如我们可以这么说，不知道你有没有时间，或者你是否能够推荐团队里面的大佬能够给我讲一下，以便我们后续更好的配合及开展工作。
2）问问题不要过于笼统
在和对应的业务产品沟通的时候，你不能直接说，你能不能给我讲讲这个功能或者业务，这个问题太过于概括和开放，对方一下接不住这个问题。如果对方没有做准备，很有可能在他和你讲的过程中，还会涉及一大堆技术和行业词汇。
关于新入职的同事，或者被调到一个新业务时，我们需要向当前业务骨干设计师请教业务问题时，也需要掌握一点说话技巧。我曾在群里看到一位前辈分享过一个表达话术，和大家分享下：
关于了解业务，我们整体的思考框架是，先整体再局部从大到小，从行业入手了解行业竞品，产品是怎样的商业运转模式，再通过价值主张这个工具，了解产品各个功能模块的价值。
找到产品的对应负责人，了解业务或者产品的组织架构，知道产品的核心模块是哪些，清楚不同角色的之间的流转关系是怎样的，将角色之间的流程串联起来，就能够达至了解业务。最后，我们对产品的掌握了解差不多了，其他的非核心模块，可以在后期做项目的时候，一边做一边了解。
希望本文对你有所帮助。
参考文献Yves Pigneur《价值主张设计》
本文由 @小高杂谈 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
关注微信
