编辑导语：产品架构有时候不仅仅是产品经理的职责，也是产品设计师在产品架构搭建时需要了解的模块之一。那么作为B端设计师，哪些产品架构知识是需要了解的呢？本篇文章里，作者便进行了相应总结，一起来看看吧。

前言

产品架构一般情况下是产品的工作职责，但是设计师补充产品架构的基础之后，一定程度能判断跟你接触的产品的水平如何，有的时候也可以在架构讨论的时候给与自己的意见。

一、什么叫做产品架构

定义：是一套将功能分类整合，形成抽象化的业务模型。

作用：架构可以帮你理清楚每个业务模块/功能间的边界，以及它们之间的关系。

二、产品架构模型分类

产品架构模型按照目的和内容不同分类为商业活动和管理活动。产品架构 2 种分类：

1. 商业活动：帮助企业把资源卖出去，或者是买进来，常见的产品小鹅通，1688等等。常见的交付方式就是ERP（进销存为主）。
2. 管理活动：帮助企业人和事（包括项目）理清楚，典型的产品类型就是：hrm（人事），OA（协同办公）。

1. 商业活动

如果只是讲一个内容分类的话会比较抽象，所以这里讲一个小李开果园的例子，来方便设计师来理解。

来讲故事了！

小李本身就有自己的一片果园，打算要卖出去，假设发展顺利的话通常会进行三个阶段：

• 第一阶段：产业比较小的话，只要做好记录就能知道清楚经营状况。
• 第二阶段：在产业逐步发展之后，只是通过记录已经没法知道经营状态了，只能通过订单来查看经营状态。
• 第三阶段：在有一定体量的用户，就需要一定用户（例如公众号维护，小程序等等）维护工作，维护回头客。

那这三个阶段可以抽离出三个模块：商品管理，订单管理，客户管理。三个模块又有不同的功能模块：

1）商品管理：

1. 商品管理：可以针对上架的商品进行增删改查，上下架的基础操作。
2. 商品分类：商品在前后台进行分类和标签，便于后台管理和用户查看。
3. 商品信息：管理不同类型商品的基础信息，对商品进行介绍。
4. 库存管理：可以进行商品库存管理。

2）订单管理

1. 订单详情：订单列表的查看，支付产生新的订单，支持订单增删改查。
2. 订单处理：正向交易有关业务，实物到店/到店核销，取消订单的操作等等。
3. 订单退单：逆向订单有关业务，交易后处理退款/退货等等。
4. 评价管理：处理评价/维权等等

3）客户管理

1. 客户管理：客户信息的基本信息管理，支持增删改查。
2. 客户权益：理清楚不同等级客户所享受的权益，以及不同的等级成长值，将用户的生命周期（LTV）。
3. 客户分群：将相同特征客户标签化，便于不同的信息PUSH。
4. 客户运营：针对不同的用户，进行不同的场景化营销。

故事的延伸：

如果小李开到了线上的话，就会延伸出：

1. 店铺管理；
2. 库存管理（当库存重要到一定程度，会单独拿出）；
3. 物流管理；
4. 资金管理；
5. 营销管理；
6. 数据表盘。

2. 管理活动

管理活动主要分成3类：

1. 管人：管理人力资源方向（例如：hrm）。
2. 管事：管理项目/事务进度或者是审批等事务（例如：oa）。
3. 管资源：资源的进出与记录（例如：erp）

拿典型的hrm为例：

常见的架构：员工管理，考勤管理，薪酬管理，工资管理。里面的功能分别又有不同的功能。

1. 员工管理：员工花名册，岗位管理，招聘管理。
2. 考勤管理：考勤规则，打卡记录，请假打卡，考勤记录。
3. 薪酬管理：薪酬方案，计薪周期。
4. 工资管理：查看详情，发放工资，审核工资。

这里有个特殊情况如果有个模块足够的复杂，操作的频率足够高的话可以单独给拿出来。招聘管理中来讲，白领招聘招聘如果到可以拓展为发布需求/管理需求/管理渠道/人才库就可以专门拓展为一个单独的功能。

三、好的产品架构如何呈现？

SaaS基础产品的行业产品深入时候种子用户群区域稳定，架构稳定的话用户的话可以降低用户的学习成本以及操作效率。针对公司的话可以提高续约率以及减低客诉成本。

针对SaaS的发展周期知识补充：

通常是4个周期：基础产品完善期，行业产品深入期，生态建设期，再创新。

分别的重点不同：

• 基础产品完善期：通过调研出来核心场景并且满足核心场景下的与用户需求，另外是随着业务细化也会不断地增加功能。
• 行业产品深入期：针对于当前行业业务提出深入完善的解决方案。
• 生态建设期：如果SaaS产品到了这个阶段，客户可以提出一些个性化定制。
• 再创新：可以延长产品生命周期，符合当前客户的需求，拉开与其他家产品的区别。提升品牌相应。

案例举例

首先我们要知道什么架构，要知道业务流程以及如何梳理出它的稳定框架包含什么。

在这里举个例子，方便读者理解，以美容院的管理客户预约的流程为例子。

1）C端/B端流程

因为用户使用场景不同，用户目的不同以及用户所处的角色不同等等原因，通常分C端消费者以及B端用户，所经历的流程也会有差异：

1. C端消费者：点击预约-填写相关信息-生成预约单。
2. B端用户：消费者通过电话/微信进行预约，B端用户负责在PC端添加预约记录。流程：添加预约-填写预约信息-保存生成预约单。

2）可以梳理出稳定的架构

B端功能需求通常来源于需求池（开发，产品设计师，服务团队，各种用户群收集的需求），B端的特殊点在于每个用户有他自己的需求。就拿创建预约页中的填写预约信息来说，不同类型的用户会有不同的需求：

1. 例子01-商家A的用户需求是消费者指定技师，那在功能操作上就是预约列表排班以及创建预约页的时候进行选择技师。
2. 例子02-商家B的需求是降低消费者爽约率，那产品那边的操作就是添加一个消费者支付订金的功能，来降低消费者的爽约率，这种商家一般是大的店家。
3. 例子03-商家C的需求是用户可以自主在网上进行预约，那产品的操作就是只填写手机号。

3）相较于B端，C端会比较统一

1. 预约列表页：添加预约，预约列表，查看详情，开单页面；
2. 创建预约页：填写相关信息，以及保存；
3. 预约完成页：预约详情，开单。

4）总结一下B/C之间的其中差异

1. B端用户需求不一致会导致不同的功能删减；
2. C端用户需求较为统一，差异小。

四、那我们如何处理产品架构

1. 将场景需求拆分成功能

这个是产品的主要责任，设计师只要初步了解一下就可以了。产品的职责之一就是将需求进行产品化。

在工作流程之中，设计师主要是用于判断需求的真实性，如何PUSH到产品经理。产品要在场景评审中把用户需求讲为一个故事方便团队其他同学理解。

以SaaS为例，我们作为设计师要根据反馈的来源（是否是KA客户）/客户分级/反馈的数量与频次，来判断产品讲的需求商业价值以及用户是否高频的场景。

2. 将不同的功能按照不同的维度进行分类，组成基础框架

在项目流程之中常常是先拿符合通用模版的功能，进行归类整合，切勿浪费精力重复造轮子。

这里举一个美容院的例子：

1. 服务管理：创造服务，查看服务；
2. 客户管理：查看会员，添加会员；
3. 订单管理：查看订单，修改订单，退款，查看退款订单，查看评价，回复评价。

注意点：优先级选用通用的商业活动架构。

有时会出现不符合通用模块的功能，一时间很难找到通用模板根据业务，根据业务重要程度和复杂性单独整合，如果功能足够复杂度够高的话，就可以单独给拿出来，类似于ERP中的库存管理可以直接拿出来。

3. 处理好模块之间的内容

1）先处理静态模块

• 静态模块定义：不产生数据流，模块之间加数据其他模块没有数据变动；
• 模块举例：服务管理、客户管理、员工管理。

2）再处理动态模块

• 静态模块定义：一旦数据变动会产生数据流干扰，模块之间加数据其他模块有数据变动；
• 模块举例：物流管理、订单管理、资金管理等等。

就好比就好比母鸡下了蛋，先放到不同的篮子里面，然后做成分别不同的样子。

五、那如何判断产品架构好坏

1. 1级导航是否具备足够的稳定性和拓展性；
2. 2级3级导航的归纳是否具备了合理的分组归纳；
3. 判断是否应该作为全局导航。

1）稳定性与拓展性

判断功能的拓展性的标准是：保证功能的清晰，且稳定的路径。

导航模块优化的注意点：

1. 不同周期，用户功能不一致：拿电商后台来讲，用户前期会更多地使用商品管理，后期用户偏向于用户管理。
2. 设置功能一定要放到最后：设置功能相当于房子里面的杂物间，与其他模块没有必要的关系，操作频率也很低。
3. 尽可能少的导航顺序：导航的排序尽量不改变用户习惯。

六、架构解决的两个问题

一个架构就像是超市中的货架设计一样，一个好的货架设计既可以让内部人员知道补货时候放在哪里，又能让用户能快速找到功能。

如果没有好的框架思维，会导致好多功能都要做，如果做不好分类，便会对内部和外部带来较大困扰：

1. 对内部：不断堆砌功能，开发成本越来越高，底层架构会不稳定。
2. 对外部：用户看到的是繁杂的信息，无法高效完成任务，反而会造成困扰。

七、总结

今天主要分享的是产品架构与功能，主要内容有架构的定义与作用/商业活动通用架构/场景需求清单/三步法确定产品架构内容。

这一篇也是我最后一篇关于“设计师要了解的产品知识”，之后慢慢地会回归B端设计本身。

资料来自 美芳老师《且曼B端设计》

本文由 @一只鸡腿 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议