用户流程图怎么画？把正常路径、异常路径和业务规则一次理清

不少流程图只有“首页—详情—提交—成功”，看上去很顺。真正开发时才发现：未登录怎么办、库存不足怎么办、审核被拒怎么办、支付结果未知怎么办。

一张有用的流程图，应该让设计、开发、测试和业务看到同一套决策与边界。

01 从一个明确用户目标开始

流程标题不要写“订单模块”，而写“新用户完成一次预约”“运营审核一条申请”。目标越具体，越容易判断哪些步骤属于流程。

明确起点、完成条件和不在范围的内容，避免一张图无限扩张。

02 区分用户动作与系统判断

用户点击、输入和选择是动作；资格校验、库存检查和权限判断属于系统。用不同形状或泳道表示，避免所有节点都写成页面。

每个判断分支必须有条件和去向，不能只画“是/否”却不说明规则。

流程图必须覆盖的内容

03 先画正常路径，再系统补异常

正常路径帮助团队理解主任务，但不能直接进入高保真。第二轮按登录、权限、数据、网络、第三方和用户反悔逐项检查。

异常不是越多越好，应覆盖高概率、高损失和不可恢复情况。

04 跨角色流程使用泳道

订单、审批和客服流程涉及用户、运营、系统和外部服务。泳道能看出等待、交接和责任。

如果某一步没有明确负责人，产品上线后很可能成为“系统显示处理中但无人处理”。

05 复杂规则用决策表补充

大量条件组合放在流程图里会变成蜘蛛网。可把流程保持可读，把资格、价格和权限规则放进决策表。

流程图、状态机和页面原型各有用途，不必让一张图承担全部细节。

06 用真实案例演练和版本管理

选取正常、边界和异常数据逐条走图，让业务、设计、开发和测试共同检查。

规则变化时更新流程版本和变更说明，避免团队继续使用旧截图。

常见问题

用户流程图和页面流程图一样吗？

不完全一样。用户流程包含目标、条件和系统行为，页面流程更侧重页面跳转。

流程图应该用什么工具？

任何团队易协作的工具都可以，清晰和版本管理比软件本身重要。

每个异常都要画吗？

优先覆盖高频、高风险和不可恢复异常，细节可放规则表和测试用例。

流程图需要写页面名称吗？

可以，但不要把所有动作都误认为独立页面，系统和后台处理也要表达。

什么时候可以开始画原型？

核心角色、主流程、状态和关键异常已确认后即可进入，并在原型中继续验证。