【职造便利店】B端业务整合思路

对于从事B端产品设计的小伙伴来说，各大平台的整合或者说业务的整合是日常工作中常会出现的一种情况。这种情况的出现往往是因为公司早期业务较少，本身逻辑也较为简单，所以不会出现多个底层平台业务交集的情况，那么难免在早期构建各平台架构的时候就会出现各自为战的问题，我们俗称烟囱式的做法。而这种做法一定程度上是一个大的平台其发展期间要经历的必然过程，因为谁也不能保证未来的3-5年行情不会变化，业务依然按部就班，而一旦变化发生你所谓的高瞻远瞩在一定程度上就会面临调整。而就B端来说，降本提效永远是一个主旋律，那么如何发挥资源的最大效用就是我们应当考虑的首要问题，而对于这个问题我们简单的可以解释为，如果我们将资源用在最具通用性的地方，让其可以横向拉通各大烟囱的核心模块，那么其资源的效用我们就可以发挥到最大。如此，整合就是我们一个避不开的话题。那么面对如此繁多的信息，我们该如何剥茧抽丝找到适合我们整合的思路，这就是下文所要描述的主要问题。

前言

明确产品方向

在整合之前，我们首先要明确我们整合后的平台或者说整合后的产品，其产品方向是什么，简单来说一句话“「什么样的用户」，在「什么样的场景下」使用你的产品，完成「什么样的任务」，需要「什么样的资源支持」”。细分下来产品方向可能会拆解为四个维度，分别为：核心目标、产品形态、核心用户、依赖的其他平台（每个维度的解释如下图）。

确定业务存在的核心问题

明确产品方向之后，要去看看你目标方向下对应的业务整体存在的核心问题是什么。虽然我们在整合业务时，每个业务都会面临其特有的问题，但依然可以发现有很多问题是有共性可寻的，普遍在整合初期我们通常会面临两大维度，四个方面的问题（如下图）。

我们可以从“人”和从“物”两大维度来分析，首先从人（用户）来看，人规定了业务的流程，业务流程又规定了参与角色所涉及的任务流程。而公司初期业务线往往不多且较为简单，各角色任务也较为单一，各任务之间互不统属也无必要的交集就导致各个业务流程和任务流程的设计容易各自为战。但是当业务发展到一定程度，需要各任务之间进行配合的时候，其原有各自为战的状况就成了“提效”路上一个很大的阻碍。当一个角色所做的本职工作一样，但对接不同业务线或任务流时，却要以不同的方式对接，其闹心程度可想而知。

其次，从物（业务）来看，当业务越来越庞大，支持现有业务运行的底层平台也会越来越多，完成一个大的工作流往往会跳不同的平台去完成子任务，很多时候还会伴随线上与线下节点并存的情况。那么无疑，把所有的子任务集中在一起完成，打通其各个环节连成一个整体，其对于用户体验的提升无疑是至关重要的。

明确落地节奏

根据常见的通用问题，其实我们就可以安排对应整合落地的节奏，往往大体有四步可以供我们参考（如下图）

首先，将原有可线上化的流程完成线上化，打通各个节点之间的关联，避免用户需要不断的跳出跳入才可以完成整体任务。其次，在流程拼接之后需要对其路径进行优化，这是降本提效的关键，整合之后的平台虽然对于产研来说是一次资源的集中，在部门内部可以达到初步降本的效果，但对于用户来说，他们的直观感受仅仅只是不再需要过多的跳转，本是降了，但效率的提升其实感觉并不明显。所以优化路径，简化原本必须完成的琐碎工作就是解决用户痛点的一个必要手段。当路径的问题解决完成之后，再去构建整个系统的权限体系，去辅助完成上下游协作效率的提升，最后通过用户的直观反馈和数据验证来迭代后续的产品。而后文，重点来阐述一下前两步我们该怎么做。

七步成诗

关于业务整合落地的步骤大致有七个关键的环节（如下图）

业务挖掘

先来说第一步，业务挖掘可以理解为业务的调研，这里和通常大家所说C端的用户调研有所区别。C端调研的目的往往是为了得出来用户模型，去帮助我们寻找一个用户在最自然的状态下能使其最愉悦的那个点是什么，从而支撑我们去寻找产品的发展方向。而对于B端来说，我们面对的往往是客户，客户和用户不同，客户代表的是一种角色而不是一个自然人。就角色而言，工作本身在一定程度下就是反人性的，是不得已而为之的结果，包括学习也是。所以，当我们在B端调研时，首先寻找的就不是用户愉悦的点，而是用户恐惧的点，去发现业务流程中最让用户恐惧的环节，帮助他减少恐惧，这才是我们首要解决的问题。那么如何完成业务挖掘的闭环呢？大致可以有如下六个子环节（如下图）

最开始，我们的调研目的通常是站在业务的角度去了解业务的全貌。这里补充一句，站在业务角度和站在功能角度去聊，你要问的问题是不一样的，这会导致我们之后撰写的提纲有本质性的区别，所以先明确你要什么才能有明确的思路去了解什么。那么以摸底业务全貌为前提，这里重点表述一下提纲的撰写方法，和聊天时应当重点关注的内容。我们先来说提纲的撰写，虽然没有一种说法第一个问题必须是什么，紧接着该问什么的思维定式。但在编写提纲时，依然有可发散的维度供我们参考，重点三个方向：用户的目标与行为、使用产品的历史、用户的观点和机会。特别提一句，如果你的B端产品涉及到对外的商业化，还要加上商业化这一部分，去调研一下你所设计的B端产品其盈利模式是什么样的。其次，当你进入真正的聊天环节时，重点记录的内容有两个部分，业务流程及节点产出，它们是帮助你构建业务全貌的线和点，而不同线和点的交织就是你心中业务的面。（小记：聊的时候拿一个录音笔，最好带语音转移功能，对于之后的整理很有帮助）

流程梳理

业务访谈完成之后，就要根据你所记录的内容进行其业务流程的梳理，个人的产出物往往是一张业务流程图。梳理时重点注意三件事。分别为：勾勒横向业务流程主体、补充管控点、统一话术的差异性。这里分别解释一下这三件事的具体内容是什么。

勾勒横向业务流程主体：

先有必要说一下什么是横向及纵向流程，横向流程往往指的是为了最终目标所需要的整体工作流，以教育机构为例，我们的最终目标必然是让学生上好每一堂课，而为了制作一门好课所要经历的阶段是很复杂的，我们首先要根据以往的上课情况制定当前的教学目标，有了目标我们会根据目标再规划所讲的内容，最后还要经过老师反复的备课，无误后这门课才能展现在学生和家长面前。那么，为了一门好课我们所经过的制定目标--规划内容--教师备课这一系列流程我们就习惯称其为横向流程，其特点是可以概括的解释为了完成一件大事我们要经过那些步骤。同样，我们也看到组成横向流程的各个节点往往包括了一个核心的子任务，而想完成这个子任务其实还要经过一系列繁琐的步骤才能算完成。以规划内容为例，可能会经过小组讨论教学要点，根据要点匹配对应的教学内容等一系列子环节，那么这些子环节所组成的我就简单称其为纵向流程。

当我们调研完业务之后，首先要构建的当然是为了完成最终目标而搭建的整体业务框架，那么勾勒横向业务流程主题就是首当其冲的环节，这是为了将目前各业务线的流程梳理完成之后，便于下一步的整合与统一。

补充管控点：

有些环节会因为某些特殊情况，存在流程的分支或者逆向，需要我们提前给予标注。比如不同角色之间的交互，或者同一任务在不同场景下存在的不同状态是否会导致流程的改变，这个需要提交梳理明白。

统一话术的差异性：

很多业务线之中的角色，其表达习惯各有差异，但是任务的实质其实是一件事，这个需要我们在梳理流程的同时，反复与调研对象进行确认。以教育行业为例，很可能每个学部学科的老师都有自己工作的习惯，那么在聊天时，其表达的话术也会带有各自学部学科的色彩，但是当你在梳理时，大概率你会发现站在你的角度，其实很多事情的本质是一样的，只是语文老师习惯这样说，数学老师习惯那样说。那么为了之后你整合范围的明确，你需要反复沟通过后，将这些点换成较为统一的话术表达。

整体流程梳理如下图

共性抽离

这里多说一句，业务整合的关键简单来说就三个字“找共性”，但什么情况下找什么类型的共性，会根据你项目目标的不同，其所找的共性类型也是不一样的。举个简单的例子，我和一个关系不错的兄弟决定出门浪一浪，是要去酒吧呢还是单纯的去干饭。如果我们这次出门的目标是改善伙食，那么我们的共性就很可能是吃了一个月食堂，想来换换口味，如此干饭就是我们必然而然的选择。而如果我们这次出门的目标变成了想解决我们的单身问题，那么酒吧就会是我们的最优选，醉翁之意不在酒嘛！这时候寻找的共性就是我们都是屌丝。对于业务，其实思路亦然。

我们再看看我们之前所梳理的业务流程，你要找的共性是什么呢？首先我们的目标是希望业务线流程的统一，其实这是一个多合一的过程，那么怎么才能合一呢？其节点所做的事是一件事，我们就可以合成一个关键节点。那么依照这个思路我们会发现，这个时候找的共性类型其实来自于业务本身。做这件事的时候最好找一面大墙，将之前梳理的业务线全部贴出来，然后用笔去切割模块，这样的话共性因子的模块化一目了然。（如下图）

在做共性抽离时，带领小组线下的实践（如下图）

模块重组

切割完模块之后，来到了我们整合的重头戏。依赖于之前的共性因子模块化，你会发现你所要整合的整体工作流往往会拆解成几个关键的步骤，每个步骤对应一段任务流程。这时，可以说横向流程已经梳理完毕，接下来你要做的是找到这些横向流程的环节中，有哪些环节是需要一个较为复杂的纵向流程来支持用户完成的，这种需要纵向流程支持的环节我这边称其为“域”。以教育行业内容生产业务流程为例，横向流程的要求大概率会需要老师去制作讲义，课件等各种内容，最后组装成成品课。但单独拿出某一个内容来看，其生产过程又是一个复杂的流程，需要老师找各种资料，去编辑，去打标签等等...，这就是上文提到的所谓的纵向流程。找纵向流程的意义是为了之后方便梳理需要哪些底层平台来供给用户达成最终的横向目标，如教育行业制作一门好课。

这里再多说一句，横纵向业务流程的交叉拆解本身是一个剥洋葱的过程，一步到位往往不现实，也容易出错。设想一步到位的后果往往是容易将不同层级的信息混淆，而导致交集的存在，这样你的模块就不太好划分了。整体思路的阐述其实如下图，业务调研后对于横向业务流程的整合我们会得出一个基于业务整体目标的大工作流，找到这个工作流里的域，去梳理域的纵向流程，然后再找纵向流程里的共性你就可以得到支持用户完成工作流时需要的底层平台有哪些，我这里将这些底层平台称之为库

按照如上思路，我们开始梳理域的纵向流程，然后去寻找这些纵向流程里哪些节点涉及到如上所说的库，最后通过共性进行排重就可以得到库的全集，我以当时所梳理的教育行业内容生产的部分“域流程”为例（如下图），红色标签所示即为库的内容。

架构分层

拿到库的全集之后，接下来就要捋清这些库所组合的层级架构是什么，紧接上一步（如下图）。依然是找共性，不过这次找的是其内容类型的共性，从上到下我们依次来看。我们将类似基础信息存储的库放在一层，称其为底层架构的维护。将官方生产的资源放在一层，称其为知识点内容维护。在往上，随着用户使用官方资源组装完内容之后，还需要一些第三方资源予以补充或拼装，这里我把其称之为元素拼装内容层。当基本内容制作完成之后，往往老师们会根据自己的风格添加一些个性化的内容作为点睛之笔，比与自己相关的图片，视频等等，将这些内容放在一层，我称其为自定义内容层。当所有内容组装完成之后，需要给这些内容来一次包装我们就会涉及到各种模板，那么针对于众多的模板我统一需要一个衣橱供其维护，这里我便称其为模板维护层。最后贯穿所有层级，我们还会涉及到数据的校对与反馈，这里便是数据监控层。其实我们从上到下来看这张图，你会发现它是一个从底层到表层的逻辑递进关系。

当我们初步归类其各个库的层级之后，接下来要划分每个层级中各个库的功能界限（如下图），同样还是找共性，将可以并行一层的内容二次整合，比如元素拼装层的内容和自定义内容层的内容，从用户的场景看，它们都属于用户在通过官方内容拼装完成之后对于整体内容的补充，所以合并入一层，统称其为内容补充层。而对于同属于知识点内容维护层的历史备课数据我却要在该层级内单独划分出来，因为与前三个不同，前三个是官方自产自销，用户拿来即用。而历史备课数据确不是官方自产，而是由用户生产但是官方提取的内容。最后加入信息流转机制，用来支持用户C端内容生产平台整体工作流的底层产品架构我们就推导出来啦！

那么对于C端的用户而言，这些底层的平台其展现形式大概率是一个以SDK提供服务的弹窗，那么对于这些表现层的工作我们怎么才能在保证少即是多的原则下，以最少的样式Hold住用户的所有场景呢？还是老朋友“找共性”，不过这次要找的是用户操作流程的共性了。依然以上图内容生产的底层架构为例，你会发现里面有一部分内容是用户拿来即用，而官方负责管理。而另一部分内容是用户自己传输自己管理。那么针对这两个主要场景，其对应的用户操作路径一个是“找-再找-用”，一个是“找-管”，那么第一种场景其更需要精准定位，所以往往筛选的方式会更多，其模块布局也会突出筛选区域。而第二种场景更需要的是方便管理的功能，所以往往批量一类管理的操作会更会突出。（如下图）

功能拆分

底层的架构搭建完了，怎么规划用户在C端使用的核心功能呢？我们先来仔细思考一下，对于用户来说整体平台的工作流如果能够顺利完成，其需要哪些路标？如果我们将整体的工作流拆分为一个个子任务（域）的话，其纵向子任务（域）与整体横向工作流交叉的节点就是其设置路标最好的位置，也是我们应该外露的功能方向。所以我们要找的就是纵向子任务（域）其正逆向流程与横向工作流的“交点”，然后排重推导出功能集合。

接着上文的内容，还是以教育行业内容生产为例，我们来看看“交点”怎么找。依赖于我们模块重组步骤中梳理的横向业务流程，我们知道首先用户在进入我们的平台时，要先新建一个类似框架的东西，我这里把它成为大纲。那你有了新建，就要想想其对应的逆向流程是什么呢？我建完肯定允许用户删吧，那删完的东西放哪呢？于是回收站的构想就有了。而大纲创建完之后，开始依据大纲组装内容，那么内容也有对应的新建和删除，除此之外还需要保留一个已建内容的历史数据池，那么这样一个核心的列表模块就出现了。以此思路类推，后续阶段的各个子任务（域）其与横向工作流对应的交点功能（平台展示的核心功能）我们大致推导出了9个，其中包括7个业务功能和2个平台功能。为什么会有平台功能呢？因为作为一个大的平台，不论你的业务是什么就应该具备的功能，例如各种设置，以及一些用户使用平台过程中可能会用到的小工具集合。（如下图）

这里还要补充一点，功能拆分好了，底层架构也有了，准备实现落地。但往往一个大项目的上线是有时间限制的，虽然构思了这么多，还是要在落地前区分一下优先级。简单来说区分优先级的思路核心围绕一个原则，“没有它，整体横向工作流能不能跑的通”如果跑不通了，那它一定属于P0，比如上图我所规划的讲义域和课件域，因为这是内容生产必要的两大核心产出物。而如果你发现某些域没它也能跑的通，那它一定属于P1，比如上图的质检和排版，以前全部线下完成，如今不放在线上只是可能耗费的时间多一些，但整体工作流的完成是不影响的，所以我在最初规划的时候暂且划掉。当然有一种情况可以特殊对待一下，比如某个域或者某个模块，有了它之后整体工作流提效非常快，而且成本尚可，那么你可以以“摩托变单车”的方式先把它做上，然后再慢慢迭代其体验。结合CB端的规划，来一张全家福（如下图）

体验落地

写了这么多，读者可能认为我是一个产品，但其实我一个UX设计师，体验落地就不得不提啦！整体来说B端较之C端不同，其业务的复杂程度注定我们要首先满足业务的畅通，用户完成任务的效率，再去考虑纯体验提升的事情。整体思路依据“形，色，字，构，质”来搭建完成且系统的体验框架，保证体验统一的同时，合理的引导用户完成核心任务的流程。如果说上文所说的是产品体验层的事情，那么这里要说的就是交互及视觉体验层的事情了。具体细节这里不过多阐述，总结为两张图吧（如下图）

七步成诗，偏向于解决业务中大方向的问题，可是当用户进入我们的产品，开始具体使用时，有哪些思路可以帮助我们推敲功能细节的问题，以助于帮助我们迭代呢？也有一套小方法供我们参考，如下文所述。

业务思路拆解

简单来说，对于细节功能的推荐，四个步骤：找人，找行为，找诉求，找功能（如下图）

首先，我们要围绕核心用户找到对应的人。什么叫做对应的人呢？按照流程，我要找到核心用户其上下游角色，以及其相关的协同者和制约者，这四类人群便是所谓的核心用户的对应人群。依然拿教育行业内容生产为例，其人脉网围绕核心用户的交互情况可能是这样的（如下图）

找到人之后，我们就可以通过用户的访谈来了解用户的行为，通过行为我们就是推导出他们在使用我们产品时的诉求，而诉求就会成为我们挖掘功能体验的基石，总的来说这个逻辑是一个大的表格（如下图）。

每个模块中，小组成员以便签的形式往进补充内容，到了推导功能时，最好给大家一刻钟的时间，这段时间大家不要交流，只需埋头写方案，当方案都写完之后，统一贴在墙上做排重的处理，你会发现有很多不谋而合的情况。下图是我当时带领小组成员在进行workshop时的推导场景。

这个表格中，流程横纵向梳理是文章前半部分讲的重点，而流程有了之后，用户行为和诉求的推导其实是水到渠成的事情，有的在和用户的聊天过程中就能拿到，有的在流程梳理完之后其行为与诉求是显而易见的。所以，这里重点表述一下由诉求到功能的推导方式。

当我们分析用户诉求的时候，你往往会发现，对于用户诉求的拆解其实包含了两个大的方向。一个宏观方向，往往指引我们产品未来的发展要往哪走。一个是微观方向，往往反映的是用户在使用产品功能时其细节的体验问题，用户往往在聊微观问题时，很可能会直接给出自己希望的产品方案，但这个时候我们需要冷静冷静来想想用户当前诉求下，其背后隐藏的真实原因什么，这就可以用到我们常说的HMW的拆解方法啦！

我们先来聊聊宏观，拿我当时拆解老师内容生产时提的诉求为例，在整个内容生产当中，我们有一个环节要求老师制作讲义，讲义可以简单的理解为学生上课时手上拿的那本书。而老师在进行讲义生产的流程中，需要用到我们的讲义平台来完成内容的组装，然后再去下印厂。在与各个学部学科的老师聊完之后，你会发现一个很有趣的问题，虽然不同的学部学科都会用到讲义平台，但是文理科的老师其使用流程却有很大差异。所有的理科老师会直接在我们的平台上完成内容的组装，而文科老师却要在平台组装前多一个线下环节，他们需要先去Word编辑内容之后再来讲义平台导入内容，随后完成组装。了解完文理科不同的流程之后，一个疑问其实已经有了，为什么文科要多一个步骤呢？此时我们带着疑问来仔细思考下业务与平台的问题，你会发现理科其内容属性往往更偏向题海，而文科却偏向素材。题海顾名思义，而素材可以理解为对于文章的二次加工，文科老师经常会将一篇文章拆解成多个段落，并对应各段落编辑不同的试题或直接在文章上挖空让学生们填写。如此，如果从用户动作的角度来看，理科在公司本身拥有庞大题库的前提下，其需要的更多的是组装类功能，而文科则需要的更多是编辑类功能。再看我们目前的讲义平台，其仅仅满足了组装的场景，而编辑类场景并未覆盖。所以，如果未来想让我们的平台更好的覆盖所有学部学科，讲义平台一定会经历一次重构，而重构的目标至少是一个类word的编辑器，再加上我们原有满足的组装场景。这样的方向便是由用户诉求推导出的宏观方向。

再来聊聊微观，与用户聊天的过程中，我们经常会听到用户会说希望有个xxx功能来帮我解决xxx问题，比如，我在用户调研的时候，老师就说我希望有一个批量修改试题类型的功能，这样可以帮我节省很多修改试题标签的时间。这个时候你就要深度思考一下，老师说这句话的根本原因是什么，彻底解决这个问题是一个批量就可以完成的么？很多情况下，用户经常会用A功能去做B场景的事情，这是因为很可能B场景频率太低，导致优先级不高一直没有落地，或者该场景本事是一个新的方向导致我们目前还没有考虑在当前的版本中，那么你就不能顺着用户的思路去以B场景的逻辑硬套在A功能上对其修改。那么如何正确的发散并落地呢？HMW就此出场。

HMW其可以解释为“我们可以怎样...”，它标志着你要从理解者慢慢转变为分析者和创造者。首先，我们需要有明确的用户和问题，这个问题不能太大也不能太小，太大我们会发散的漫无边际，太小又没有发散的余地。当我们有了用户和问题之后，会有五个维度供我们挖掘，再由每个维度去拓展HMW1，HMW2...，最后再有每个HMW去细化到可落地的方案。（如下图）

我们先来说说问题，第一步看似简单，但其实很关键，什么叫不大不小呢？这个不能光靠感觉，还要不断的练习，当初带领小组成员（8个同学）进行了3天的workshop，我们完成了2个命题的拆解，第一个命题我们在排完重之后的可落地方案有21个，而第二个命题在排完重之后只有13个，由此可见第二个命题我们范围给的有些小了。具体什么叫问题呢？如下图所示，图中包含了布棉老师在高阶产品课举的两个例子，这里我只阐述在个人工作中遇到的现实案例。依然还是教育行业的内容生产业务，老师们在制作内容时经常会去编辑素材，如上文解释宏观方向中所述文科老师生产内容的场景。这里就会遇到一个问题，老师会反馈编辑素材时不太方便，但是这个不太方便显然包含的范围太广了，广到无从下手，可是直接拿追问的问题直接拆又会太小，因为老师尝尝会说是因为某一个功能不好用导致编辑素材不太方便。如此，折中一下，我们就有了这样一个命题，“老师在编辑素材时花费了大量的时间”，以个人经验来看，先找到一个大方向，再找到一个小方向，然后折中再得出一个不大不小的问题会更靠谱一些。

综合得出命题之后，我们有五个维度发散，这五个维度分别是：否定，积极，转移，脑洞大开，分解。在此，对五个维度略作解释。

否定：重点考虑用户是否必要做这件事，或者说部分必要做这件事。需要深入思考这个问题产生的原因是什么，从而决定这个问题是否一定要解决或只解决一部分。（基于上文的命题，我们当时在否定维度下写了这样一条HMW，即“如何让用户减少编辑次数”，这个想法的逻辑是部分解决）

积极：C端常用的方向，通过激发用户动力，或减少用户阻力来解决问题（在积极的维度下我们其中一条HMW是，“如何缩短用户的素材编辑流程”）

转移：B端常用的方向，考虑是否可以通过间接资源帮助用户完成任务（在转移的维度下我们其中一条HMW是，“如何让第三角色帮助老师完成编辑”）

脑洞大开：最好玩的一个维度，先不要管靠不靠谱，能想到的都先写上（在脑洞大开的维度下我们其中一条HMW是，“如何让老师愉快地跨平台操作”，写完之后workshop的气氛瞬间活跃了）

分解：我们最终的目的是希望用户来我们的平台完成一个任务，但是完成任务的前提是如何让老师先进来，那么分解的关键就是将一个任务流程拆解成不同的步骤，从而将注意力由最后的节点转移到其他的节点（在分解的维度下我们其中一条HMW是，“如何让老师先编写讲义再同步素材库”，）注：编写完后的素材如果能够正常使用，必须经过底层的审核。

综上所述，我们有了这样一张大图（如下）

有了HMW，接下来就可以依据不同的HMW去细化落地的方案了。例如，基于上述否定维度下，如何让用户减少编辑次数的HMW，我们就可以细化为，通过批量操作解决问题或者通过模板来解决问题。基于转移维度下，如何让第三角色帮助老师完成编辑的HMW，我们可以细化为，通过AI识别老师涂画的方式让系统自动录入或根据知识点自动匹配来帮助老师解决问题。再有了众多方案后，小组成员排重得出所有方案的全集，随后根据其成本来选取最优解，这里包括产品，研发，设计各个部门的综合成本，最终我们选择了“讲义即编即用，入库流程后台进行”，将原有后置的环节并行在前一个环节之下，这样在没有做任何大改动的同时提高了用户编辑素材任务的整体效率，皆大欢喜。如此，通过HMW方法的分析，到最终方案的落地我们就有了一个完成的过程（结果如下图）。

功能思路拆解

最后呢，写一写在目前大环境中的一些个人感受。如今的大环境不由得让人想到98年的下岗潮，确实岗位的稀缺对于互联网中的人潮来说，竞争压力越来越大，说白了越来越卷。但是，在这一环境中我个人认为首先要考虑的是什么样的思维或者能力对于这个世界来说更具有通用性。站在设计师的角度，尤其是一个从事B端的设计师，其对于业务模型的理解和用户模型的理解直接决定了你所设计的方案会不会真正满足用户的需求。而这部分内容光靠纯卷UX是远远不够的，需要对于上游环节十足的理解才可以。希望这篇不能称之为方法论的总结可以给设计师一些工作中的思路，可以在某一天成为真正的产品设计师，欢迎各位大佬多多指教呀！

尾记

B端业务整合思路