方法论如何用（通用方法论）

从0到1设计一款B端产品，分不开两个阶段，一个是整体设计阶段，另一个是详细设计阶段。其中都有哪些工作需要准备，一起来看看作者是怎么说的，希望对产品初学者、一直在做产品功能设计的产品人带来帮助。

几天前，跟两个工作5年以上的产品经理聊产品设计。令我惊讶的是，他们居然不清楚B端产品的设计分为两个阶段，一个是整体设计阶段，另一个是详细设计阶段。

分析原因，大概是因为他们一直在基层岗位拧螺丝，接触的都是详细设计阶段的内容，对整体设计不熟悉也就不足为奇了。这就是在大厂拧螺丝的弊端吧。

有感于此，我才准备写本篇文章，从整体上介绍如何从0到1设计一款B端产品，并努力做到图文并茂吧。希望能对产品初学者、一直在做产品功能设计的产品人有一些帮助，让他们从更高的视野来看待产品设计这件事。

文章较长，目录如下。

一、第1次业务调研

在决定好做某个方向的产品，并联系好调研的客户之后，就开始了第1次业务调研。

这里有一个常见的误区，认为业务调研是一次完成的。实际上，由于B端产品涉及的业务较为复杂，所以，业务调研往往不是一次就能完成的，通常需要多次调研。

多次调研并非随意调研，而是按照由上至下、由大致小、从粗到精的顺序进行调研。就像剥洋葱一样，从业务框架开始一层一层剥，直至业务细节。

1.1 调研前的准备工作

由于是第1次业务调研，也是第1次与客户接触，所以我们需要给客户展现我们的专业性，让客户信赖我们，让客户相信我们。所以，在第1次业务调研前，需要了解行业里通用的业务模式。在与客户沟通交流的时候，能够与客户平等对话。

比如，客户想做一套自己的电商系统，那么在去客户那里调研前，我们需要搞清楚通用的电商业务模式。

1.2 调研的目的

第1次业务调研的目的如下。

1. 明确业务范围；
2. 梳理客户的业务现状；
3. 了解客户业务的痛点和问题，以及客户的期望。

1.3 调研哪些内容

由于我们已经知道通用的业务模式，所以调研的重点就放在客户个性化的业务上，如此可以减轻我们调研的负担。

具体来说，需要调研的内容包括：梳理整体业务流程、明确客户的痛点/问题以及期望，了解客户的组织架构。

1.3.1 整体业务流程

由于本次调研的目的之一是明确业务范围，所以不用调研业务细节，只需要弄清楚客户的整体业务流程。

一般来说，整体业务流程需要达到的细度是，能够表达出各参与方在哪里做什么事情。换句话说，就是搞明白三要素：参与方、现有业务系统、各参与方在业务系统中的业务活动。

我们以某电商的业务为例，说明整体业务流程，如下。本篇文章后续的例子，将基于该电商的业务展开。

在梳理整体业务流程时，需要注意两点。

首先，需要搞明白业务流程中存在的痛点和问题，这是我们后续做方案时需要解决的。

比如，在上面的某电商整体业务流程中，供应商通过线下手工方式给平台提供商品信息，由平台在电商平台端录入商品信息。随着买家需求的增长，供应商和供应商提供的商品信息均在逐渐增多，平台录入商品信息需要的人力也逐步增加，这给平台带来很大的负担。

其次，需要搞明白客户现在用的系统有哪些，各个系统的作用是什么，客户对这些系统的替代或集成是怎么考虑的。这是我们后续考虑系统集成方案的基础。

1.3.2 组织架构

B端产品的客户往往具有多层级组织架构。比如，集团下面有各个公司，公司下面有子公司，子公司下面有孙公司，孙公司下面有门店、项目部等。

了解清楚客户的组织架构，将有利于后续的权限设计。

1.4 调研后需要交付什么

调研结束后，不是简单跟领导汇报调研情况就可以的，而是需要写一份调研报告。调研报告的内容包括：

1. 客户业务现状，会用到整体业务流程图，并辅以文字说明；
2. 客户业务存在的问题，以及客户的期望；
3. 哪些问题可以用产品解决；
4. 问题的优先级列表。

调研报告完成后，需要与客户沟通并获得客户确认。

二、整体方案设计

客户认可调研报告后，我们开始产品整体方案的设计。相比于细节方案设计，整体方案设计更宏观，不涉及业务细节和产品原型。

2.1 整体方案流程设计

根据我们在第1次业务调研中得到的痛点和问题，对客户整体业务流程进行改进，形成整体方案流程。

整体方案流程需要表达出的三要素是，参与方、系统（现有的和将要做的）、各参与方在系统中的业务活动。

针对平台录入商品信息负担重的问题，给出了解决方案。建设一个电商供应商端，由各个供应商提交商品信息，然后平台负责审核商品信息。这可以降低平台录入商品信息的负担。同时，供应商提交的商品信息需要经过平台审核，可以有效避免供应商录入信息不规范的问题。

2.2 产品定位

产品定位是要阐明，系统（产品）为谁提供什么服务。

我们举的例子中，电商供应商端的定位是，为供应商提供商品信息提交与管理等功能。

如果系统涉及的参与方比较多，那么可能需要将系统拆分为若干子系统，并分别阐明各子系统为谁提供什么服务。

2.3 功能模块设计

功能模块设计，就是考虑为用户提供哪些功能模块，以满足产品定位。

这是一个做加法的过程，把能想到的功能模块都罗列出来。在这个过程中，可以参考竞品的功能模块。

2.4 应用架构设计

应用架构设计的目的有两个，一个是说明各个功能模块之间的关系，一般指数据流转关系；另一个是说明系统的功能模块与公司内部其他功能模块间的关系，是改造还是重新开发。

由于电商系统中已经有订单管理模块，且订单管理模块包含订单及其状态等信息，所以电商供应商端不需要重复开发订单管理模块。为了实现电商供应商端的订单列表和订单取消申请两个模块，只需对订单管理模块的接口进行改造。

2.5 产品路标设计

产品路标设计，就是依照业务优先级确定功能模块的实现节奏，即YY1年MM1月DD1日实现哪些功能，YY2年MM2月DD2日实现哪些功能……

做完以上5个步骤，就完成了产品的整体方案设计。在进行第2-n次业务调研前，需要与客户确认整体方案。

三、第2-n次业务调研

3.1 调研哪些内容

第1次调研的内容比较宏观，所以第2次调研需要搞清楚各个功能模块所涉及业务的现状、存在的问题和痛点，以及用户的期望。

具体来说，需要梳理出各个功能模块所涉及的业务流程，并画出业务流程图。同时，需要对客户的报表需求进行调研。

如果第2次调研后发现还有一些细节没有弄清楚，那么就需要更多次调研。但是，最好在调研前做好调研计划，每次调研内容尽量系统、全面，以减少调研的次数。因为客户一般都比较忙，不太容易约调研时间。

3.2 调研需要交付什么

调研完成后，需要产出调研报告，并与客户确认。调研报告的要点与第1次调研后输出的调研报告相同。

四、详细方案设计

4.1 详细方案流程设计

根据第2次调研得到的业务问题、痛点和用户期望，对当前的业务流程进行改进，并分别绘制各个功能模块详细方案流程。

详细方案流程描述的是角色A在系统B中做事情C。换句话说，详细方案流程的三要素是角色、系统、活动。

通常，用跨职能业务流程图表示详细方案流程。

4.2 页面流转图设计

页面流转图是比详细方案流程图更细节的图。相比详细方案流程图，页面流转图描述的是角色A在系统B中为了完成事情C需要的操作D，以及操作涉及的页面。可以看出，页面流转图的要素是用户操作和页面。

基于页面流转图，可以梳理出产品的页面有哪些，这是后续产品原型设计的基础。

4.3 产品原型设计

产品原型设计大家都比较熟悉，就是把设计意图形象、直观地表示出来。

不同的公司，产品经理在原型设计时的分工稍有不同。有交互设计师的公司，产品经理画出线框图就行。如果公司里没有交互设计师，那么产品经理需要把交互设计也做出来。

对于B端产品，最重要的是解决客户的业务问题，而不是把用户体验做到极致。所以，我们会看到很多B端产品的设计很low。这不是因为B端产品经理的审美水平不行，而是因为客户并不需要高大上的用户体验。但这并不是说用户体验就不重要，可以随意瞎搞，而是不需要在用户体验上花费大量精力。

4.4 权限设计

B端产品的特点之一是，客户的组织架构复杂。为了保证数据的安全，需要进行功能或数据的权限控制，这就涉及到权限设计。

通常，权限设计分为功能权限设计和数据权限设计。功能权限设计是对页面中功能点的访问权限进行设计。功能权限设计有一套经典的理论模型——RBAC模型，一般的B端系统都会基于这个模型设计功能权限。

数据权限设计是对用户能够查到的数据范围进行设计。通常而言，用户的数据权限和他在组织架构中的节点有关。

4.5 埋点设计

为了量化产品的使用效果，同时记录用户的使用行为，需要进行埋点设计。通过埋点，可以获取用户的行为数据，进而对该数据进行分析，从而得出有价值的结论，例如，如何改进产品的功能。

至此，就完成了一个B端产品从0到1的设计。

作者：产品经理伯庸；产品经理伯庸；

本文由 @产品经理伯庸 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。

,