从需求到功能，B端产品设计四步法

B端产品的基本面，是讲究产品可用性的，各个链条环节的问题，都会影响最终结果。

这也是B端产品要求重逻辑和专业性的原因。

所以，一个B端产品经理自身产品设计的质量和效率，直接决定了项目的结果与效率。

那么，在B端产品设计中，有没有一些像产品五步法一样的方法，能指引产品设计，让大家少走一些弯路呢？

过去一段时间内，我自己在部门内也做一些论证，也提炼了一套我认为比较有效的方法，我称之为“B端产品设计四步法”。

接下来，我们按步骤讲解下：

1、拆需求（用户->场景->需求）

一个最小的子需求，应有3个要素组成：用户**在**场景下的**需求。

那一个完整的大需求，就需要N多个子需求所组成。

但是，一个人如果想要直接面向子需求颗粒度去分析，对于大项目复杂项目，基本是不可能完成的任务。

在这里，我建议大家使用「角色×流程」象限图表法。

按照这个框架，我们需要依次代入每个用户的视角，来穷举不同用户在不同场景下的需求点。

PS：场景1、2、3、4，尽量按照信息流的时间线顺序（大概率是可以的）。

注意，在这个环节大家不要考虑任何系统功能和实现，就用白话来描述需求点。因为后边有其他步骤来做转化的事情。

按照以上的原则，把各个象限表格填写完成。

完成第一遍之后，还需要继续第二遍，第三遍的review。

在后边的每一遍检查中，可以尝试按不同流程（例如场景中包含的信息流、资金流、实物流等等）、按不同用户（例如按照用户生命周期时间线）来交叉比对信息。

串联时候，一定要做到保证逻辑（不是系统逻辑，而是自然逻辑）自洽。

读到这里，有人可能会问：这个象限图表，看起来不就是多个用户在驱动一个流程场景变化，能不能就是一个流程图来呈现呢？

大部分场景下，是不能等同的。

严谨来说流程图更多是单一主线随时间变化的呈现，但是这个图表中，其实会包含更多个流程图，例如上边说的信息流、资金流、实物流等等。

另外，还有一些前置准备信息、后置信息，都跟流程没太多强耦合关系。画成流程图，特别容易遗忘这些需求点。

第1步「拆需求」，是产品设计最重要的一环，这个环节有偏差，后边几个环节都要跟着重新返工，会影响整体项目效率。所以，大家一定要在这个环节多花一些功夫。

2、需求转译事件

当第1步完成之后，我们就会得到不同用户一个个明确的需求点。

那么第2步，我们就侧重于需求怎么达成，这里给一个公式。

一个需求的结果 = 事件1+事件2+事件3+……

其中，事件X=用户**通过**做**

一个事件，可以是一个页面的按钮点击，也可能是一个逻辑的执行，也可能是一个sop的执行等等。

注意，不同事件之间，可能有先后顺序或依赖关系。

在这一步中，因为是事件视角，就要关心能不能达成的问题，尤其是一些核心卡点。看哪些事件的完成，依赖外部、依赖资源、依赖技术可行性等等。

理论上，在这一步，就需要大面上确定各个事件的可行性。如果是关键环节不能达成，那就要寻找替代方案，如果找不到，那基本上也就不能继续往下走了。

不少人，就是在这个环节内，没有对关键环节做论证，导致详细方案出完才发现有卡点，需求做不了。

我自己的经验，第2步完成之后，才能去做项目立项。

3、事件模块化聚合

第1步是按照用户视角。

第2步也是按照用户视角和功能视角。

完成前两步之后，所有需求都被事件转译，接下来我们需要收敛一下功能点。

大家发现一个事件的元素组成是：用户**通过**做**，这里面通过“**”这个对象，更多就是领域模块。例如交易订单、促销、支付、清结算、业财、物流等等，当然这个模块颗粒度可以更粗也可以更细，大家根据实际情况来决定即可。

这个步骤的主要作用，就是将离散的功能点所需要的承载体，聚类聚合。

因为需求最终落地的最细划分会到模块，而模块一般情况其实跟岗位职责是对应起来的。例如A同学考虑A模块的设计，B同学考虑B模块的设计。

另外，功能点聚类之后，也能一次性get到大需求内所有对单模块的影响点，便于一次性分析，省得来回倒腾。

4、详细设计

完成以上3个步骤之后，其实产品设计的主要工作基本就完成80%。

剩余的，就是如何落地到具体细节设计和描述。要不就是新增一个能力，要不就是改动一个能力。

详细设计的对象，可能是页面的交互、一个自动脚本、系统校验逻辑、线下SOP等等。

产品设计一定要结合现在系统的现况。一方面是现在系统的逻辑，另一方面是新能力叠加已有能力的成本。

这个环节会用到专业知识和设计经验，每个人情况不同，我默认大家这个环节已经比较熟练，不再赘述。

不管如何，如果前面几个步骤做得比较扎实，这个第4步我觉得问题不大。因为到这个步骤，技术已经完全跟产品站在同一个起跑线了，会“补位”或“掰扯”产品功能如何实现的。