1. 权限交互验证的业务场景与目标

1.1 业务场景与用户故事

在一次 SaaS 后台管理系统的迭代中，产品经理发现以下真实痛点：

• 营销人员无法查看财务导出的客户订单报表，但能编辑自己的推广计划。
• 财务审核员只能读取已完成的订单数据，不可修改商品价格。
• 超级管理员可以跨模块操作，但希望由开发人员通过 Axure 原型提前校验权限配置是否遗漏。

典型用户故事：

作为运营主管，我希望只有拥有“销售报表查看”权限的角色才能访问「数据中心-销售概览」页面，避免敏感数据泄露。

权限交互验证的核心矛盾在于：原型阶段必须模拟真实权限逻辑，而非单纯“画页面”。Axure 的动态面板、条件判断和全局变量正好承担此任务。

1.2 业务问题与需求拆解

从产品需求维度拆解为四个层次：

1.3 常见权限模型对比（RBAC / ABAC）

选择模型直接影响原型复杂度。下表对比两种主流模型：

1.4 用户角色与权限矩阵（交付物模板）

设计权限矩阵是产品经理在原型阶段的关键交付物。以下为标准化模板（以“营销模块”为例）：

该矩阵将作为 Axure 原型中全局变量赋值的依据。在原型中，每个页面/按钮的交互条件都对照此矩阵编写。

1.5 权限交互验证的目标拆解

1. 功能可见性验证：不具备权限的角色看不到入口菜单和按钮。
2. 操作可用性验证：具备查看权限但无编辑权限时，按钮置灰或点击无响应。
3. 数据范围验证：同一角色不同级别（如营销主管 vs 专员）看到的数据条目不同。
4. 边界条件验证：未登录、角色为空、超时等异常状态下全部拦截。

1.6 整体权限验证流程（SVG 框架图）

1.7 指标验证与验收标准

在原型评审前，需定义量化的验证指标：

1.8 交付物模板清单

本章结束后，你应该可以产出以下交付物：

1. 角色-权限矩阵表（Excel/在线表格，含所有模块与角色）
2. 权限交互验证流程图（如上 SVG，或使用 Axure 的流程图工具）
3. 测试用例表（含角色、页面、操作、预期结果、实际结果）

以下为测试用例表简化模板（用于 Axure 原型评审）：