一、产品业务层
1.清晰的知道每个模块的应用场景，为不同角色解决的什么问题 —— 也就是“角色”、“场景工作流”、“解决方案”这三层。
在梳理产品方案时，反复问这仨问题：
当前模块是为哪些角色服务的？
对应角色的实际业务流是怎么样的？
他们的实际解决方案是怎样的？有哪些可以优化的？
2.角色之间的业务依赖，系统中包含的用户角色和边界条件 —— 角色的数据权限+颗粒度、角色的输入和输入。
厘清角色业务依赖，需要考虑这仨问题：
上游角色的输出是下游角色的输入，输入输出的数据颗粒度；
角色之间数据权限的隔离；
不同角色的业务流边界区别和待办事项。
3.有效业务数据的提取，不同角色需要关注哪些数据 —— 执行者角色和管理者角色需要关注哪些数据指标？
提取业务数据，需要关注：
执行者角色关注哪些数据维度和颗粒度；
管理者又关注哪些模块的数据维度和经营指标？
总结起来就是一句话：依照不同角色的实际业务场景输出对应的工作流和工作成果留痕。
二、产品基础层
1.产品要有逻辑清晰的信息架构，信息架构是产品最最底层的结构，需要拆分至原子字段级。从这四层出发：
产品模块的信息打散成原子字段列表，尽可能的穷举所有字段及其字段规则；
将字段组合成多个维度，比如商品的信息可以拆分为：基本信息维度、商品属性维度、商品价格维度、商品销售+营销维度、商品评价维度……
不同维度之间关联的产品模块。比如商品销售维度关联哪些产品模块：商品模块、订单模块、营销模块、用户模块……
产品模块结合业务流程，依照不同角色做业务数据输入、场景业务流逻辑和业务数据输出。
2.产品模块的“低耦合”和“高内聚”。高内聚确保模块内部的功能紧密相关且单一，提高了模块的可靠性和复用性；低耦合则减少了模块之间的依赖关系，使得系统更加灵活和易于维护。
高内聚的核心：一个模块只负责一个任务；模块内的元素之间高度相关；减少出错的可能性；
低耦合的核心：保持模块独立，依赖关系弱，只需要通过定义清晰的接口和使用消息传递等方式来实现模块间的交互。
总结起来也是一句话：将不同角色的业务流能抽象和自定义组合成产品框架，便于后续的易用性和扩展性。
三、产品设计层
1.功能设计形成范式 —— 同一类型的功能，保持一致性，让用户使用起来清晰明了（什么时候弹出，什么时候跳转…）
2.用户操作 —— 随时可以中断和继续，有明确的入口和明确的撤回意识，不论什么阶段都可以一步步撤回至初始态；
3.一定要做人话 —— 说人话，让用户一眼就明白是怎么回事。理解不是用长句子，要看场景，贴着场景说话，做用户能用明白的产品。不耍专业，不设置门槛；
4.让用户有强“安全感” —— 不能点击的要么隐藏，要么提示；能点击的，重点的二次反馈，非重点的需要给明确的反馈；
5.产品性能要提升 —— 别让用户等待，产品体验路径和响应速度，是产品体验的最重要的两个前提。要遵循习惯路径的设计，比少一次点击重要；
6.做好产品监控 —— 比用户更早知道问题的出现，在用户知道之前解决问题；
7.用好默认设置 —— 默认的设置表示产品是否能理解业务底层，很少用户会改默认设置，所以请提前根据业务习惯定义清晰。
总结下：B端设计C端化，是当前做B端产品的趋势；多去拆解C端产品和可视化设计交互。
以上内容还有很多调整空间，但是「产品业务层」和「产品基础层」是基架，当业务逐渐的复杂，不拆分清楚，后续的可实用性和可拓展性将会遇到很大的问题。
评论区可以沟通交流下……
