不少流程图只有“首页—详情—提交—成功”，看上去很顺。真正开发时才发现：未登录怎么办、库存不足怎么办、审核被拒怎么办、支付结果未知怎么办。
一张有用的流程图，应该让设计、开发、测试和业务看到同一套决策与边界。
01 从一个明确用户目标开始
流程标题不要写“订单模块”，而写“新用户完成一次预约”“运营审核一条申请”。目标越具体，越容易判断哪些步骤属于流程。
明确起点、完成条件和不在范围的内容，避免一张图无限扩张。
02 区分用户动作与系统判断
用户点击、输入和选择是动作；资格校验、库存检查和权限判断属于系统。用不同形状或泳道表示，避免所有节点都写成页面。
每个判断分支必须有条件和去向，不能只画“是/否”却不说明规则。
流程图必须覆盖的内容
| 元素 | 要回答的问题 | 示例 |
|---|---|---|
| 角色 | 谁在执行或接收 | 用户、审核员、系统、第三方 |
| 起点 | 从哪里、因何触发 | 扫码、通知、首页入口 |
| 动作 | 用户或系统做什么 | 填写、校验、支付、通知 |
| 条件 | 为什么走不同分支 | 登录、权限、库存、资格 |
| 状态 | 当前对象处于什么阶段 | 草稿、处理中、失败、完成 |
| 异常 | 出错后如何恢复 | 重试、补充、撤销、人工处理 |
| 终点 | 怎样算任务结束 | 成功、退出、转人工、取消 |
03 先画正常路径，再系统补异常
正常路径帮助团队理解主任务，但不能直接进入高保真。第二轮按登录、权限、数据、网络、第三方和用户反悔逐项检查。
异常不是越多越好，应覆盖高概率、高损失和不可恢复情况。
04 跨角色流程使用泳道
订单、审批和客服流程涉及用户、运营、系统和外部服务。泳道能看出等待、交接和责任。
如果某一步没有明确负责人，产品上线后很可能成为“系统显示处理中但无人处理”。
05 复杂规则用决策表补充
大量条件组合放在流程图里会变成蜘蛛网。可把流程保持可读，把资格、价格和权限规则放进决策表。
流程图、状态机和页面原型各有用途，不必让一张图承担全部细节。
06 用真实案例演练和版本管理
选取正常、边界和异常数据逐条走图，让业务、设计、开发和测试共同检查。
规则变化时更新流程版本和变更说明，避免团队继续使用旧截图。
常见问题
用户流程图和页面流程图一样吗？
不完全一样。用户流程包含目标、条件和系统行为，页面流程更侧重页面跳转。
流程图应该用什么工具？
任何团队易协作的工具都可以，清晰和版本管理比软件本身重要。
每个异常都要画吗？
优先覆盖高频、高风险和不可恢复异常，细节可放规则表和测试用例。
流程图需要写页面名称吗？
可以，但不要把所有动作都误认为独立页面，系统和后台处理也要表达。
什么时候可以开始画原型？
核心角色、主流程、状态和关键异常已确认后即可进入，并在原型中继续验证。
