交互流程描述方法：流程图符号规范、泳道图与状态机

交互流程描述是将设计意图转化为可执行、可评审结构的关键技能。本章聚焦三种核心描述方法：标准化流程图符号提供通用视觉语言，泳道图明确角色职责与交接，状态机刻画对象连续状态变化。掌握这三类方法能覆盖绝大多数交互场景的描述需求。

适用场景

前置条件

• 已确定描述范围和粒度（页面级 / 任务级 / 原子操作级）。
• 团队已对齐符号基本含义，避免自创符号。
• 具备绘图工具（Figma / Draw.io / Mermaid 等）或模板。
• 交互需求文档已有明确的功能列表和用户角色定义。

操作步骤

4.1 标准化流程图符号

1. 选定起始与终止 – 使用圆角矩形（终端符）标记开始和结束。
2. 绘制操作步骤 – 矩形（处理框）表示原子操作或页面。
3. 判断与分支 – 菱形（决策符）表示条件判断，每个出口标注“是/否”或结果。
4. 连接顺流 – 箭头线表示流转方向，避免交叉或远距离跨越。
5. 合并与循环 – 使用圆形（连接符）跨页跳转；回环箭头表示循环或重试。

4.2 泳道图

1. 定义角色泳道 – 每一列或行代表一个角色 / 系统。泳道标题明确角色名称。
2. 绘制角色内的活动 – 在对应泳道内放置矩形处理框，每个活动只能属于一个角色。
3. 标注角色间交接 – 箭头跨越泳道时附加消息或数据标签，注明协议（HTTP / 消息队列 / 文件等）。
4. 突出关键路径 – 用高亮或粗细区分主流程和异常分支。

4.3 状态机描述

1. 枚举所有状态 – 列出对象可能经历的有限状态（如待支付、已支付、已取消）。
2. 定义状态转移 – 每一条转移需标注触发事件和动作（如“支付成功 → 已支付”）。
3. 识别初始与终态 – 使用实心圆表示初始状态，双层圆表示结束状态。
4. 检查状态完整性与互斥性 – 确保没有遗漏状态且同一时刻不冲突。

输入输出物

责任边界

• 交互设计师 – 选择正确的描述方法、绘制主流程、维护符号规范一致性。
• 产品经理 – 提供前置条件、确认角色划分与状态定义。
• 开发/测试 – 基于图表开展实现与用例编写，反馈描述歧义或遗漏。
• 评审主持人 – 组织逐节点评审，重点检查跨泳道交互和状态转移条件。

记录材料

异常处理

验收标准

• 符号使用完全对齐项目内定义的符号对照表，无自创或歧义符号。
• 泳道图中每个活动有且仅有一个所属角色，跨泳道箭头附带可读的交互描述。
• 状态机中初始状态、每个中间态与终态均已定义；转移线上注明触发事件与动作。
• 所有图表示例附带创建日期、版本号、作者姓名。
• 评审记录中无“符号不清楚”“角色不明”“状态遗漏”类遗留问题。

模板示例：泳道图字段定义

以下为泳道图描述字段的推荐表格格式，用于在文档中直接定义每一跨泳道交互：

| 跨泳道交互编号 | 源泳道   | 目标泳道 | 交互内容                     | 触发条件       | 返回消息 / 异常处理 |
|----------------|----------|----------|------------------------------|----------------|---------------------|
| LN-01          | 用户端   | 服务端   | POST /api/payment            | 用户点击“支付” | 200:支付成功/400:余额不足 |
| LN-02          | 服务端   | 结算系统 | 消息队列: request.payment    | 接收到LN-01请求 | 确认收到 + 错误重试策略 |
| LN-03          | 结算系统 | 服务端   | 消息队列: response.payment   | 处理完成       | 同步状态机转移     |

将此类表格附在泳道图旁，可消除描述歧义，成为开发与测试的直接依据。状态机描述的字段可参考 状态 → 触发事件 → 前置条件 → 后置动作 → 下一个状态 列结构。