本页目录

业务流程驱动的B端产品设计方法

四层架构：业务在前，交互在后

杨堃的方法论有一条清晰的纵轴：业务建模 → 数据建模 → 权限建模 → 交互设计。每一层是下一层的输入，跳过任何一层都会在后续暴露问题。

业务建模解决"客户的业务怎么跑"。数据建模解决"系统需要哪些实体和关系"。权限建模解决"谁能看什么、改什么、批什么"。交互设计解决"页面怎么呈现、操作怎么安排"。

和C端产品方法的核心区别在于：C端可以从用户体验倒推功能，B端必须从业务流程正推系统设计。顺序反了，产品基本上要返工。

业务建模不是列功能点。它的起手式是两个问题：这个业务涉及哪些角色？每个角色在流程中做什么决定？

具体操作是画角色泳道图——把所有参与者放在不同泳道里，标出每个人在流程中的动作、决策点和数据交接点。泳道图画完，业务的骨架就出来了。

这一层的关键输出不是"系统应该有什么功能"，而是"业务流程的真实运转方式"。功能是从流程里推导出来的，不是拍脑袋列出来的。

业务流程确定后，下一步是抽象出核心数据实体。一个采购系统至少涉及供应商、采购单、审批记录、入库单、付款单这些实体。实体之间的关系（一对多、多对多、从属、引用）决定了数据库设计和接口逻辑。

数据建模阶段最容易犯的错是"想到什么加什么"——需求讨论中蹦出一个新字段就直接塞进表里。正确的做法是先确定实体边界，再决定每个实体包含哪些属性。属性服从实体，实体服从流程。

这一层做扎实了，后续的开发返工率会大幅下降。做不扎实的代价往往在上线后才显现：数据不一致、接口调不通、报表拉不出来。

权限建模是B端产品区别于C端产品的核心技术难题之一。它不是"加个权限管理模块"那么简单，而是一套贯穿所有功能模块的横切逻辑。

杨堃把权限拆成三个维度：功能权限（能不能用某个功能）、数据权限（能看到哪些数据）、操作权限（能做哪些修改）。三个维度交叉组合，形成权限矩阵。

权限建模的位置在数据建模之后、交互设计之前。因为权限规则直接影响页面呈现——同一个页面，不同角色看到的字段、按钮、数据范围都不同。如果交互设计完了才补权限，页面结构可能需要大面积重做。

到这一层才进入产品经理最熟悉的领域：页面布局、操作流程、表单设计、列表和详情的切换方式。

但B端的交互设计和C端有一个根本差异——B端的交互复杂度来自业务规则，不来自用户心理。一个审批表单上有多少字段、哪些字段必填、字段之间有什么联动关系——这些全部由前三层决定，交互设计师能调整的空间其实有限。

这意味着B端交互设计的核心能力不是"让页面好看"，而是"让复杂业务规则在页面上可理解、可操作"。表格设计能力、表单联动逻辑、批量操作的效率优化——这些是B端交互设计师的核心技能。

四层不是瀑布式的单向流动。开发过程中经常出现这种情况：交互设计阶段发现某个权限规则在页面上没法优雅实现，需要回到权限建模层调整；数据建模阶段发现业务流程图遗漏了一条异常分支，需要回到业务建模层补充。

这种反馈是正常的。但杨堃强调的关键点是：反馈方向必须是向上的——下层发现问题，回上层修正。不允许在下层就地发明新规则。交互设计师不能自己决定"这个字段不需要权限控制"，必须把问题带回权限建模层讨论。

这种"向上反馈、不就地决定"的约束，是B端产品质量控制的核心机制。