第3章 Axure基础元件与交互：动态面板、中继器、交互用例、条件设置

3.1 用户场景：权限原型中的典型交互困境

产品经理在设计权限系统原型时，常遇到以下三类高频场景：

• 场景一：不同角色看到不同页面。如管理员进入控制台能看到“用户管理”菜单，普通成员则看不到。若用独立页面为每个角色复制一份，将导致原型膨胀且难以维护。
• 场景二：同一按钮在不同权限下反应不同。例如“删除”按钮，对管理员直接弹出确认框，对普通成员则提示“无权限”。静态原型无法表达这种条件分支。
• 场景三：权限列表需动态渲染。角色与权限的对应关系经常变动，若手动绘制每个角色的权限表格，每次需求变更都需要重新出图，效率极低。

3.2 业务问题：静态原型无法表达权限变化

使用传统“堆页面”的方式做权限原型，会带来三个业务层面的问题：

这些问题的根源在于：原型缺乏“状态管理”和“数据驱动”能力。动态面板、中继器、交互用例与条件设置正是弥补这些能力的核心工具。

3.3 需求拆解：四个核心能力

从产品需求表达的角度，四个元件分别对应权限交互中不可或缺的四种能力：

3.4 原型方案表达：元件组合方案

结合四个元件，可以构建一套完整的权限交互原型方案，分为“数据层”和“呈现层”两部分：

• 数据层（中继器 + 条件设置）：中继器存储用户权限数据集，每一行记录包含 user_id、role、permission_level 等字段。条件设置读取当前选中用户的 role 或 permission_level 值，作为判断依据。
• 呈现层（动态面板 + 交互用例）：动态面板的不同状态对应不同的权限视图（如“管理员面板”“编辑者面板”“查看者面板”）。交互用例监听用户操作（如点击“进入管理后台”按钮），先触发条件判断，再根据结果切换到动态面板的对应状态。

中继器数据集示例字段：
┌─────────────┬──────────────┬──────────────────┐
│ 字段名       │ 数据类型     │ 示例值            │
├─────────────┼──────────────┼──────────────────┤
│ user_id     │ 文本 (Text)  │ U001             │
│ role        │ 文本 (Text)  │ admin            │
│ level       │ 数字 (Number)│ 3                │
│ department  │ 文本 (Text)  │ 技术部           │
└─────────────┴──────────────┴──────────────────┘

3.5 交互逻辑：权限状态机与条件分支

权限交互的核心逻辑可以抽象为一台“状态机”：用户操作触发事件 → 中继器提供权限数据 → 条件设置进行判断 → 动态面板切换到对应的状态。下图展示了这一完整流程：

流程中的关键交互逻辑拆解如下：

1. 事件触发：用户点击某个受权限控制的元件（如“编辑”“删除”“进入管理后台”），交互用例捕获该事件。
2. 数据查询：中继器根据当前用户的标识查找对应的权限记录，返回 role 与 permission_level 值。
3. 条件分支：条件设置对返回值进行判断。例如 [[Item.role == 'admin']] 或 [[Item.level >= 3]]。判断结果为“真”则走左侧分支，“假”则走右侧分支。
4. 状态切换：动态面板根据分支结果切换到对应的状态（有权限状态 / 无权限状态），每个状态下放置不同的内容或提示。
5. 结果呈现：用户看到功能界面或权限提示，完成一次完整的权限交互闭环。

[[Item.role == "admin"]]          // 精确匹配角色
[[Item.level >= 3]]               // 数值比较
[[Item.role == "editor" && Item.department == "技术部"]]  // 多条件与

3.6 验收标准

在原型交付前，使用以下验收点检查权限交互的完整性与正确性：