产品经理画流程图，是为了把“大家好像都懂”的需求变成可以逐项确认的规则。一张有效的流程图应让团队看见谁在做、按什么顺序做、何时产生分支、失败后去哪，以及哪些环节仍待确认。
产品经理最常用的5个流程图场景
需求澄清：把叙述改成动作顺序
当需求写成“用户可以快速完成退款”时，真正待确认的是申请入口、资格判断、审核角色、退款方式和结果通知。先画主流程，再把无法确定的节点标成问题，评审会就有了明确议题。
这一阶段不必把所有页面都画出来。输出物可以是一张带问题标记的流程草图，例如“超过可退款时间后是否允许人工处理”“部分退款由谁审批”。问题被分派并有答复来源后，需求才从口号变成可执行规则。
业务规则检查：让条件和例外露出来
会员、优惠、审批、库存和权限规则很容易隐藏在长段文字里。流程图把判断节点显式展开，产品经理可以逐一核对“条件不满足时怎么办”“多个规则冲突时谁优先”。这类图的终点不是页面，而是业务结果。
在退款例子中，可以按订单状态、商品类型、支付渠道和申请时间拆分条件。不要为追求完整而猜测规则；无法确认的分支应保留待定标记，并链接到对应业务说明或负责人。
页面范围梳理：从功能路径推导页面
登录、下单、发布内容等功能，可以把用户动作、页面反馈和系统结果连起来。完成后再将关键节点映射成页面、弹窗或状态，减少原型做完才发现缺少失败页和空状态的情况。
退款路径至少可能涉及订单详情、申请表单、进度页和结果通知。是否需要新增页面，要根据现有页面能否承载状态判断，而不是简单地让一个流程节点对应一个页面。
跨团队评审：围绕同一节点讨论
业务、设计、研发和测试关注点不同。在线评审时，不要只问“流程有没有问题”，而应在节点旁标出负责人、输入、输出和待确认规则。修改结论留在同一张图里，避免聊天记录、文档和原型各自形成版本。
例如业务确认退款资格，设计确认用户是否看得懂失败原因，研发确认支付渠道回调与状态更新，测试根据每个判断出口建立用例。不同角色看同一条路径，但回答不同问题。
研发交付：说明边界，不代替接口文档
交付阶段的流程图用于说明页面、服务和异常之间的关系，但它不应替代字段、接口、状态码和数据约束。产品经理可以在节点上关联原型或文档，让研发知道哪里看交互、哪里看规则、哪里需要技术方案。
交付前再走一遍退款主线和失败支路，确认每个业务结果都有用户可见反馈，每个系统状态都有来源。若流程中仍出现“系统处理”这类无法验证的黑盒节点，应继续拆分或链接到技术设计。
不同场景应该画到什么程度
| 场景 | 最低需要表达 | 可以停止的信号 |
|---|---|---|
| 需求澄清 | 角色、主步骤、待确认点 | 团队能指出缺口并明确负责人 |
| 业务规则 | 条件、优先级、例外与结果 | 每个判断都有可解释出口 |
| 页面范围 | 用户动作、页面反馈、状态 | 页面清单与主路径能够对应 |
| 跨团队评审 | 责任边界、争议点、结论 | 结论已回写，不依赖口头记忆 |
| 研发交付 | 前端、服务、数据与异常关系 | 相关文档和原型有明确入口 |
画图时先选对层级
讨论业务怎样运转时画业务流程图；讨论某个功能怎样响应用户操作时画功能流程图。两者可以关联，但不要混在同一粒度中。具体区别可查看业务流程图和功能流程图对比。
一条退款需求如何贯穿5个场景
需求阶段先列出申请、判断、处理和通知；规则阶段确认资格与审批条件；页面阶段映射入口、表单、进度和结果状态；评审阶段把争议落到具体分支；交付阶段关联原型、接口和测试用例。流程图在不同阶段会增加细节，但主节点名称应保持一致，避免同一概念在不同文档中反复改名。
如果流程变化频繁，可以把“已确认规则”和“待确认问题”用文字标签区分。不要用颜色作为唯一信息，因为打印、投屏或色觉差异可能让标记失效。重要状态应同时使用文字说明。
这5个场景最容易出现的问题
需求澄清容易把方案当需求，业务规则容易漏掉条件冲突，页面梳理容易让每个节点机械对应新页面，评审容易只收集意见却不形成结论，研发交付则容易用一张大图代替接口和状态定义。流程图可以连接这些工作，但不能替代每个环节需要的专业资料。
更新流程时，先说明变化来自哪条业务结论，再标记受影响的页面、接口和测试用例。这样团队看到的不只是“连线被改了”，还知道为什么改、后续要同步哪些内容。
流程越接近交付，节点名称越要与需求和原型一致，避免用“处理一下”“系统判断”等模糊词。
在墨刀流程图中，可以用可编辑节点和连线整理结构，并围绕同一张图分享、评论和维护版本。先让图服务一次真实决策，再考虑颜色和排版；看完图仍不知道要确认什么，说明图形不少，但信息还不够。
