需要说清一个功能在界面层如何被走通时…

适用于规格化一个功能被用户逐步走通的屏幕级路径、分支逻辑和异常处理，而不是描述情绪化的端到端体验。

适用场景

解决思路

1. 先定义这张流程图要达成的目标（用户要完成什么）。
2. 识别流程的入口点（一个或多个）。
3. 先画 happy path（主成功路径）。
4. 再加入决策点与分支。
5. 再补充错误路径与恢复方式。
6. 标记所有退出/结束点。
7. 标注后台正在发生的系统动作。
8. 用图形约定表达元素：入口点用圆形/椭圆；屏幕/页面用矩形；决策用菱形；用户动作（Action）用圆角矩形；系统进程（后端操作）用带侧边条的矩形；结束点用带边框的圆形；连接线用箭头表示流向。
9. 按需要选择流程类型：任务流（task flow）= 针对特定任务的单一路径，线性；用户流（user flow）= 依据用户类型或选择产生多条路径；线框流（wire flow）= 流程图与线框缩略图结合。
10. 做流程标注：标注屏幕名称与关键内容。
11. 做流程标注：标注每个分支处的决策依据。
12. 做流程标注：标注错误条件及其处理方式。
13. 做流程标注：标注系统事件与通知。
14. 做流程标注：标注时间延迟或异步过程。
15. 最佳实践：一张流程图只对应一个用户目标。
16. 最佳实践：先画 happy path，再逐步增加复杂度。
17. 最佳实践：必须包含错误路径与边界情况路径。
18. 最佳实践：保持流程图可读，单张图不要放太多分支。
19. 最佳实践：使用一致的符号/图例约定。
20. 最佳实践：给每条箭头标注触发条件或动作。

适用边界 · 注意事项

• 需要表达情绪化的端到端体验弧线时，改用 journey-map（design-research），而不是本流程图。
• 分支过多、超出单图可读范围时，不要硬塞进一张图，应拆分成多张流程。
• 不用于非屏幕级的系统架构或纯后端数据流表达。