B端设计师应该懂的产品架构知识

前言

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

1·为什么需要好的产品框架？

需要的意义

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

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

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

案例举例

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

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

C端/B端流程

因为用户使用场景不同，用户目的不同以及用户所处的角色不同等等原因，

通常时分C端消费者以及B端用户所经历的流程也会有差异：

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

可以梳理出稳定的架构

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

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

相较于B端，C端会比较统一：

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

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

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

小总结

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

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

上面讲到了为什么需要好的架构，那接下来细化通用架构模型。

通用架构模型及案例

那通用架构模型的定义以及作用是什么？

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

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

通用架构模型按照目的和内容不同分类为商业活动和管理活动。

详解通用架构 2 中分类

商业活动：帮助企业把资源卖出去，或者是买进来，常见的产品小鹅通，1688等等。常见的交付方式就是ERP(进销存为主)

管理活动：帮助企业人和事（包括项目）理清楚，典型的产品类型就是：hrm（人事），OA（协同办公）。

商业活动

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

来讲故事了！

1. 小李本身就有自己的一片果园，打算要卖出去，假设发展顺利的话通常会进行三个阶段：
   第一阶段：产业比较小的话，只要做好记录就能知道清楚经营状况。
2. 第二阶段：在产业逐步发展之后，只是通过记录已经没法知道经营状态了，只能通过订单来查看经营状态
3. 第三阶段：在有一定体量的用户，就需要一定用户（例如公众号维护，小程序等等）维护工作，维护回头客。

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

商品管理：

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

订单管理

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

客户管理

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

故事的延伸

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

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

那我们如何以SaaS如何做好调研的场景需求清单来处理业务框架

调研

以美容院为例，针对营销员进行调研出来的场景需求清单

这里有个表格

泳道图

通过调研出来的资料，针对业务流程进行用道泳道图梳理。可以直接表现业务流程，如果还有角色则可以加到后面。

这里有张泳道图

梳理框架3部曲

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

01·将场景需求拆分成功能

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

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

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

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

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

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

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

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

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

03·处理好模块之间的内容

先处理静态模块

静态模块定义：不产生数据流，模块之间加数据其他模块没有数据变动

模块举例：服务管理、客户管理、员工管理

再处理动态模块

静态模块定义：一旦数据变动会产生数据流干扰，模块之间加数据其他模块有数据变动

模块举例：物流管理、订单管理、资金管理等等

小总结

所以B端产品是一直在生长的产品架构，随着产品的发展架构会不断的发生变化。

管理活动

管理活动主要分成2类：

管人：管理人力资源方向（例如：hrm）

管事：管理项目/事务进度或者是审批等事务（例如：oa）

管资源：资源的进出与记录（例如：erp）

拿典型的hrm为例:

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

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

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

一个好的架构解决的两个问题

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

对设计有什么用

那上面描述了好的架构对产品的作用，那对设计的帮助就是设计时候选择一个“合适”的导航栏

那设计合适的的导航栏要注意什么呢？主要是要注意3个点：
1·1级导航是否具备足够的稳定性和拓展性

2·2及3级导航归纳的是否具备了合理的分组归纳

3·判断是否应该作为全局导航

稳定性与拓展性

判断功能的拓展性的标准型是：保证功能的清晰且稳定的路径比少点击一次的路径点击一次更重要。

导航模块优化的注意点：

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

本来这里就要结束了，但是在做最后思考的时候临时加了一个权限体系（产品主要做的），加起来成为全体体系。作为设计师主要是作为了解以及选修。

设计师要了解的权限体系设计

选修内容了解即可，深入聊的话会比较复杂。权限体系3要素：

1. 用户
2. 角色
3. 权限

用户

通常是登陆平台的使用者的基本信息（姓名,id,,手机号,所属部门等等）

角色

角色根据行业与所属公司架构不同角色定义不同，这里就讲一个默认/内置的角色：高级管理员

来源

高级管理员类似于主管一类的角色，这个角色来源于调研出的关键用户画像而得出来的。

权责

高级管理员是拥有最高/所有的权利角色，也是需要管理下面所有的角色。如果新入职一个员工，则需要高级管理员给他绑定相应的角色。

特殊场景

有的员工岗位特殊，则可以通过定义一个角色，来给他绑定赋予它相应的权限（角色是权限的载体）。

权限

什么是权限？

用于角色决定在系统上看见什么，做什么操作？这里涉及到了可见性和操作性

权限一般分为5类：

1. 模块权限：一般会涉及到不同版本看到的功能模块不同，不同的角色也是看到不同的模块。
2. 页面选线：可以通过自定义角色来控制哪个页面能被看到。
3. 操作权限：更高的角色拥有更多的操作权限。
4. 字段权限：相同的信息每个角色看到的信息不同。
5. 账号权限：每个账号只能看到自己账号权限的里面内容。

这里会比较复杂就做个小的总结：

其中用户的颗粒度最大，一个用户可以绑定多个角色和权限，一个角色可以绑定多个权限，所以颗粒度最小。最理想的的状态是一个用户绑定一个角色

总结

今天主要分享的是产品架构与功能，主要内容有架构的定义与作用/商业活动通用架构/场景需求清单/三步法确定产品架构内容，以及选修内容权限体系。这一篇也是我最后一篇关于”设计师要了解的产品知识“，之后慢慢的会回归B端设计本身。