产品设计思路（一）：以<易盘点>为例

最近我在为解决公司的资产管理业务场景调研了一款固定资产管理saas软件 <易盘点> 。最近产品所遇到的问题包括：信息维护混乱，判断分支多，新功能的关联影响 。因此以易盘点为案例整理几点产品设计思路：1、属性设计；2、高内聚低耦合；3、逐级判断；4、报表与功能的关系；

一、属性设计

流程：用户与系统交互的实际业务场景（调拨）；

实体：单独存在的个体，被业务流程所引用（资产）；

属性：最小单元字段，被实体所引用（领用人，资产分类，所在位置）；

以资产作为实体，从编辑的角度，其属性类型包括：1、可任意编辑的文本字段；2、仅支持选择的选项字段（非配置项）；3、仅支持选择的选项字段（配置项）

1、可任意编辑的文本字段

示例：资产名称，品牌，型号，备注

特点：A，无规律且发散的字段类型，无通用性；B，该字段不产生其他数据交互，比如条件筛选，报表统计，条件判断；

2、仅支持选择的选项字段（非配置项）

示例：使用状况，购置方式

特点：有限的标准选项，用户无需配置且无法修改，比如购置方式中的采购和租赁，若用户配置仅会配置这两项。因此系统写死，减少用户无效操作的同时也便于用户快速熟悉产品

3、仅支持选择的选项字段（配置项）

示例：资产分类，位置，管理员；

特点：由于用户及实体的不确定性，系统无法确认选项值，只有用户根据自己需求才能配置属性选项。系统可以为了方便用户设置写好预设值并可编辑，例如几乎所有的资产管理都涉及办公电脑，因此事先设定的预设值有助于减少用户无效操作。

优点：A，方便可以被不同实体调用，例资产和调拨都调用位置管理；B，产品逻辑清晰，属性管理独立维护，不同实体混淆；C，数据源统一，属性维护将同步维护实体信息，例若地址写了错别字，仅需在地址管理修改后，资产信息将同步修改；D，信息维护规范，可拓展性强；

结论：我们往往从上往下设计，即先确认业务流程，再确认实体，后确认属性。属性需一开始设计时需要根据不同的类型采取不同的设计思路，否则后期的信息维护成本或重构成本较高。

二、高内聚低耦合

这个词其实来源于产品经理如何基于需求迭代产品（下篇1）：产品设计的高内聚低耦合，个人认为这个思想对产品设计很有意义。

高内聚

定义：在互联网产品（例如一款app）中的高内聚是指，在系统、模块、功能、实体等层面保证每个系统、每个模块、每个功能、每个实体在用户认知中的统一且单一，并符合整体特征、逻辑和自然。

案例说明：易盘点的所有的模块都是独立的，尽可能的拆分至最细，比如说，由于员工权限为自助盘点，自助领用等业务操作层面的权限，管理员权限为系统的功能和数据等权限，因此是不一样的领域，将权限拆分为角色和员工自助管理；组织架构和员工管理做拆分，员工管理在组织架构创建后的基础上做信息维护。

低耦合

定义：在互联网产品（例如一款app）中的低耦合是指，在系统、模块、功能、实体等层面保证每个系统、每个模块、每个功能、每个实体之间的联系是简单而不是复杂的。

案例说明；已知公司运营部希望为高净值的用户提供满减优惠，在活动管理创建领用优惠券的活动后，系统如何判断该用户是否满足条件。以下两种产品设计：

1、条件筛选满足高净值条件的用户后，批量添加用户名单；用户名单里的用户可参加活动；

2、用户管理中，为符合高净值的用户，打上标签；符合该标签的用户可参加活动；

前者的设计缺点：首先，在活动管理的模块需插入用户筛选条件和批量添加用户等用户管理的设计，即活动管理和用户管理的设计写到一起；其次，可维护性差，若后续新增用户满足高净值，需再次新增用户名单；

后者设计思路有两个优点：产品框架清晰，即活动管理只引用了用户管理的标签维度；信息易维护，后续有满足高净值条件的用户，只需给满足用户上标签即可；

结论：高内聚低耦合的产品设计可以减少功能冗余，判断复杂；

三、逐级判断

已知：人力部有员工A，且员工A名下无资产，此时用户希望删除人力部；以下两种产品设计：

1、在删除人力部时，若不存在员工名下的资产，则删除部门并删除员工

2、在删除人力部时，判断部门是否存在员工，若存在无法删除；删除员工时，判断员工是否存在资产，若不存在可以删除；

越级判断，看起来会令业务操作更省略，而逐级判断，看起来更为“繁琐”。但逐级判断的产品设计更单一，逻辑更清晰。这样的设计思路不会随着层级的扩展导致判断逻辑分支更多。而越级判断需要考虑各种维度组合的分支，而且一个操作执行多类结果也有用户无感知的风险。

结论：逐级判断的设计思路适应于多层级，多分支的产品设计场景，将操作判断仅同临近关系关联，比如说前置条件或后置结果。

四、报表与功能的关系

报表的本质是数据的呈现。至于数据的分析，挖掘是基于报表的基础上深入展开。

已知商品A，用户原价购买将附赠品，同供应商的结算成本为60；特价购买无赠品，成本为50；此时供应商结算的成本报表有两种产品设计：

1、成本报表判断商品属性，若原价则60，若特价则50；

2、订单表新增该字段<成本>，并判断商品属性，若原价则60，若特价则50；成本报表取订单表的成本字段

方案1的弊端是，若后续条件判断逻辑调整，功能及报表需一并调整。若报表设计和功能设计不是同一产品经理将会出现报表数据脱节的风险。而方案2避免方案1的风险，报表仅需拿到所需字段即可，无需知道该字段的背后取值逻辑。若该敏感字段如成本，价格等，需做好权限控制。

结论：业务流的数据表要为报表提供基础字段数据