第二章·Axure动态面板核心概念：面板状态、状态切换、交互触发条件、用例场景
用户场景：审批流原型中的“状态焦虑”
产品经理在评审会上演示请假审批原型时，经常遇到以下场景：
- 点击“提交”按钮后，页面直接跳到“审批中”，缺乏中间加载反馈。
- 驳回后想展示“重新编辑”状态，但原型只能切页或弹窗，无法在同一区域保持上下文。
- 开发追问“不同状态下哪些按钮可用？”原型无法直观表达。
这些问题本质上是面板状态管理缺失导致的。
业务问题：静态页面无法承载动态审批流程
传统Axure原型使用独立页面表达不同审批阶段，但存在三大硬伤：
- 切换成本高：每个状态维护一个页面，结构冗余，修改需要同步多个页面。
- 状态流转不直观：交互逻辑分散在全局交互中，开发难以提取业务规则。
- 交付物可读性差：UED评审时需频繁跳转页面，注意力被频繁打断。
用户访谈：来自一线PM的真实反馈
访谈对象：P公司电商组产品经理 Lisa
原话摘录：“每次改审批流原型，我都要同时改5个页面。最怕老板说‘这里加个待办状态’，因为要重新画一遍。如果能像APP的卡片一样在同一位置切换内容，就轻松多了。”
痛点提炼：①状态新增成本高；②状态间跳转关系不清晰；③原型无法表达“什么条件下进入什么状态”的业务规则。
需求拆解：四个核心概念的关联矩阵
| 核心概念 | 定义 | 审批流典型表现 | 用户痛点映射 |
|---|---|---|---|
| 面板状态 | 动态面板内[[Item.Status]]对应的视觉布局 |
待提交、审批中、已通过、已驳回 | 维护多个独立页面，内容重复 |
| 状态切换 | 从当前状态显示切换到另一状态的过程 | 点击“提交”后从“待提交”→“审批中” | 无法演示过渡动画与中间态 |
| 交互触发条件 | 导致切换发生的用户操作或变量变更 | 点击按钮、表单验证通过、回传状态码 | 开发追问“什么条件下触发？”PM无法给出精确矩阵 |
| 用例场景 | 特定状态下允许用户执行的操作集合 | 已通过状态下“撤回”按钮不可用 | 原型中所有按钮永远可点，误导评审判断 |
💡 经验公式：
审批流原型的业务完整度 ≈ 面板状态数 × 状态切换路径数 × 触发条件准确率 / 用例场景遗漏数
方案表达：用动态面板封装“审批状态容器”
将整个审批卡片区域设计为一个动态面板，内部放置若干面板状态。每个状态对应一个审批阶段（如“待提交”）。通过交互触发条件（按钮点击、变量匹配）驱动状态切换，并在切换的同时定义当前状态的用例场景（隐藏/禁用无关控件）。
⚠️ 常见坑位：
- 面板状态命名使用数字索引而非语义名称，后期维护时不知道“1”对应什么状态。
- 一个动态面板内放置超过15个状态，导致加载卡顿且交互列表冗长。
- 忘记为每个状态设置初始用例场景（如“待提交”状态下提交按钮可用，但变量尚未初始化）。
指标验证：如何衡量概念应用效果
| 验证指标 | 计算方法 | 目标值 |
|---|---|---|
| 原型状态切换正确率 | 用例走查中，预期状态与实际显示状态一致次数 / 总测试次数 | ≥95% |
| 触发条件覆盖度 | 已实现触发条件数 / 业务需求中列举的所有触发条件数 | 100% |
| 用例场景遗漏率 | UED评审中发现遗漏的禁用/隐藏控件数 / 总控件数 | ≤5% |
验收标准：交付物检查清单
- 动态面板内至少包含3个语义命名状态（如
[[Status_Ready]]而非[[1]]）。 - 每个状态切换交互均附带明确的触发条件描述（写在该交互的备注栏中）。
- 每个状态内所有控件均已设置用例场景（禁用/隐藏条件），且与需求文档一致。
- 提供状态切换矩阵表格（源状态→触发条件→目标状态），作为交互说明附件。
交付物模板（原型文件结构）
文件命名规则：项目名_审批流_动态面板_v1.0.rp
内部页面组织：
审批卡片（动态面板）—— 包含7个面板状态，每个状态以涂色矩形示意视觉框架。全局变量说明—— 定义[[ApproveStatus]]的枚举值及对应面板状态索引。交互触发条件总表—— 用Axure的“用例”功能列出所有触发路径。用例场景说明书—— 为每个状态输出按钮/输入框可用性矩阵。