1. 权限交互原型概述
1.1 用户场景：产品经理的权限设计困境
某SaaS平台需要重构后台管理系统，产品经理小张面临典型权限难题：
- 角色混乱——运营、审核、管理员职责交叉，操作权限边界模糊；
- 数据泄露——普通运营人员能查看全量客户订单明细，超出职责范围；
- 审批卡顿——敏感操作（删除数据、修改配置）缺乏流程管控，事后追责困难；
- 原型沟通成本高——每次评审都要口头解释“谁能做什么”，开发与测试理解不一致。
场景提炼：权限设计的本质是在“业务效率”与“安全合规”之间找到平衡点，而Axure交互原型是统一团队认知、前置验证规则的关键载体。
1.2 业务问题：权限设计四大痛点
| 痛点 | 业务表现 | 后果 |
|---|---|---|
| 角色定义不清 | 同一人兼任多角色，权限越级 | 数据泄露、操作失控 |
| 资源粒度粗糙 | 只能控制菜单可见，无法细化到按钮/字段 | 交互设计反复返工 |
| 流程缺失 | 敏感操作无审批、无日志 | 安全审计不通过 |
| 原型与实现脱节 | 需求文档写“有权限控制”，原型未画出具体交互 | 开发理解偏差，测试无据可依 |
1.3 需求拆解：权限体系三要素
一套完整的权限交互需求可拆解为三个核心维度，任何权限设计都围绕这三者展开：
- 角色（Who）——定义用户身份集合，如管理员、编辑、审核员、访客。角色之间可能存在继承或多角色叠加。
- 资源（What）——被保护的对象，包括菜单、页面、按钮、字段、API接口、数据范围等。
- 操作（How）——对资源执行的动作，常见有查看、新增、编辑、删除、导出、审批、撤回等。
需求拆解要点：在原型阶段，需要将“角色-资源-操作”三元组映射为可视化的界面元素。例如“运营专员只能查看本组订单（资源），不能编辑（操作限制）”，对应的原型应明确展示按钮置灰、数据过滤、页面跳转等交互状态。
1.4 权限体系的核心价值
| 价值维度 | 业务收益 | 原型验证点 |
|---|---|---|
| 安全性 | 防止越权操作与数据泄露 | 越权访问时是否阻断并提示 |
| 效率性 | 角色与权限自动匹配，减少人工配置 | 角色切换后界面布局是否自适应 |
| 合规性 | 满足等级保护、GDPR等审计要求 | 操作日志与审批流是否完整闭环 |
| 可扩展性 | 新增角色或资源时无需重构体系 | 权限矩阵是否支持动态增删行/列 |
下图展示了从业务痛点出发，经过需求拆解与权限体系设计，最终通过Axure原型交付并达成课程目标的完整链路：
1.5 Axure原型交付物全景
本课程中，每一类权限需求都会输出对应的Axure原型交付物，形成完整可验证的交互方案：
- 权限矩阵面板——以表格形式展示角色与资源操作的关系，支持勾选、禁用、继承状态可视化。
- 角色管理流程原型——覆盖角色创建、编辑、删除、克隆、成员绑定等全生命周期交互。
- 资源授权操作流——展示给用户/角色分配资源权限的具体步骤，包括搜索、批量选择、保存生效。
- 敏感操作审批原型——当用户执行删除/导出等高风险操作时，触发审批流程的交互闭环。
- 数据范围过滤器——演示不同角色登录后，列表数据自动过滤（如只看本部门、只看自己创建）。
- 验收标准清单——每条权限规则对应一条可测交互用例，直接作为测试用例依据。
1.6 课程目标与适用角色
课程目标：学完本课程后，学员能够独立在Axure中设计出结构清晰、逻辑完备、可直接用于开发评审的权限交互原型，并能够向团队清晰阐述每条权限规则的设计依据。
| 适用角色 | 核心收益 | 建议前置知识 |
|---|---|---|
| 产品经理 / 需求分析师 | 掌握权限需求的结构化拆解方法，输出高质量PRD | 基础Axure使用经验 |
| UX / 交互设计师 | 学会权限类交互细节（禁用态、提示、审批流）的原型表达 | Axure中继器、动态面板基础 |
| 前端 / 全栈工程师 | 理解权限交互全貌，减少开发中的理解偏差 | 了解RBAC模型概念 |
| 测试 / QA人员 | 获得可测的权限验收标准，提升测试覆盖率 | 有功能测试经验即可 |
1.7 验收标准：什么样的原型算合格
一个合格的权限交互原型，必须同时满足以下五项验收标准：
- 角色可识别——每个原型页面都能清晰标识当前登录角色，角色切换后界面状态随之变化。
- 权限状态可感知——禁止操作应呈现明确的视觉反馈（置灰+悬浮提示），不可直接隐藏按钮。
- 流程可走通——核心权限流程（如角色分配、资源授权、审批提交）在原型中可完整点击闭环。
- 边界有处理——越权访问、未登录状态、数据为空等异常场景有对应交互页面。
- 规则可追溯——每条权限限制都能在原型配套的验收清单中找到对应条目，开发与测试可逐条核对。
常见误区：不要在原型中仅用“文字描述”代替交互状态。例如写“管理员可见此按钮”是不够的，必须用Axure的条件判断+动态面板实际演示“当角色=管理员时显示，否则置灰”。开发需要看到的是可交互的规则执行结果，而非需求文档式的文字说明。