第 3 章：Axure 中的角色与用户管理设计方案

3.1 用户场景

在企业级后台系统、SaaS 平台或内容管理系统的原型设计中，权限验证是绕不开的核心环节。以下三类典型场景直接驱动本章方案的设计：

• 产品经理验证权限边界——同一功能页面在不同角色（管理员、编辑、访客）下的可见性、可操作性差异需要在原型中真实呈现。
• 交互设计师展示角色切换——演示用户从登录到进入系统全流程中，角色信息如何影响界面状态，便于评审时快速达成共识。
• 开发团队对齐信息传递路径——明确用户身份数据在页面间如何流动，减少前后端联调时的理解偏差。

3.2 业务问题

在 Axure 原型中模拟权限交互时，以下三个问题反复出现：

1. 登录环节过于简陋——直接跳过高保真登录页，导致角色与用户身份的绑定关系无法在原型中闭环。
2. 角色信息无法跨页面传递——每个页面单独设置角色状态，一旦需要调整就要重复修改 10+ 个页面，维护成本极高。
3. 评审时角色切换效率低——测试人员需要手动修改多个局部变量才能切换角色，容易遗漏且无法复现 Bug。

3.3 需求拆解

将业务问题转化为可落地的功能需求与非功能需求：

3.4 方案表达

整体方案围绕“一个登录页 + 一个角色选择器 + 一套全局变量”展开，三者通过交互事件串联成完整的用户身份管理闭环。

3.4.1 模拟登录页面设计

• 页面元素： 用户名文本框（[[txtUsername]]）、密码文本框（[[txtPassword]]）、登录按钮、错误提示动态面板（默认隐藏）。
• 预设账号表： 使用 Axure 的“数据集”或全局变量内置一个 JSON 结构，包含 3~5 组用户名、密码与角色映射。
• 交互逻辑： 点击登录按钮时，条件判断输入值与预设表是否匹配。匹配则跳转至角色选择器页面；不匹配则显示错误提示面板。

3.4.2 角色选择器设计

• 展示形式： 推荐使用单选卡片组（Radio Button Group + 卡片样式），每个卡片包含角色图标、角色名称和一句话权限描述。
• 角色列表： 固定三个角色——系统管理员（全部权限）、内容编辑（发布/编辑/删除）、访客（仅查看）。
• 交互逻辑： 用户点击某张角色卡片后，系统将所选角色写入全局变量 userInfo.role，同时自动跳转到系统首页。

3.4.3 用户信息存储（全局变量）

全局变量是连接登录页与所有功能页的“数据总线”。推荐使用以下结构：

全局变量 userInfo 结构（JSON 格式说明）：
{
  "id":       "U001",         // 用户唯一标识，登录时写入
  "name":     "张明",          // 用户真实姓名
  "role":     "admin",         // 当前角色：admin / editor / viewer
  "token":    "tk_a1b2c3d4",   // 模拟登录凭证
  "avatar":   "avatar_01"      // 头像编号，用于页面个性化展示
}

• 生命周期： 从登录成功开始创建，在浏览器标签页关闭前一直存活；支持在“角色选择器”中重新赋值 userInfo.role。
• 读取方式： 任何页面的动态面板条件判断中，直接引用 [[userInfo.role]] 即可获取当前角色值。

3.5 方案流程总览

下图完整呈现了从模拟登录到角色选择、再到全局变量存储与页面跳转的完整数据流向：

3.6 指标验证

方案是否有效，需要在实际原型中通过以下指标进行测量：

3.7 验收标准

• 登录页： 输入正确账号密码可跳转至角色选择器；输入错误时显示对应的错误提示，且停留在登录页。
• 角色选择器： 三个角色卡片均可正常点击；点击后 userInfo.role 被更新为对应值；点击后自动跳转至系统首页。
• 全局变量： 系统首页加载时，页面顶部展示当前登录用户名与角色标签；在首页任意位置点击“切换角色”可返回角色选择器。
• 跨页面一致性： 从系统首页跳转到任意二级页面后，页面中引用了 userInfo 的元素（如用户名、权限按钮）均正确显示。

3.8 交付物模板

本章对应的 Axure 源文件应包含以下标准交付物，便于团队复用与评审：

3.9 条件判断规则与动态面板状态说明

为了让方案可直接落地，下面给出登录页和角色选择器的核心判断规则与状态定义：

3.10 测试用例表（验收阶段使用）

以下测试用例可直接复制到测试管理工具中，用于原型交付前的功能验证：