上周给一个后台产品做原型评审，老板指着登录后的首页问：“这个页面，管理员和运营看到的怎么一模一样？”我承认当时偷了懒，三个角色共用了一套页面。会议室的气氛一下就变了，从“看原型”变成了“讨论权限边界”，方案也没讲下去。后来我把这套 Axure 多角色登录原型彻底重做了一遍，从那以后，凡是涉及账号体系的评审，基本都是一遍过。
这篇教程，我打算把这么一套可以拿去评审、甚至可以直接甩给前端当交互参考的多角色登录原型，从头到尾拆一遍。包括页面架构怎么规划、全局变量怎么设计、登录按钮的条件分支怎么编排、登录后不同角色内容如何切换、以及我在实测中踩过的几个坑。适合有一定 Axure 基础、正准备做账号/权限模块原型的同学，也适合想搞清楚“全局变量 + 动态面板 + 条件判断”三者怎么配合使用的朋友。
1. 多角色登录，卡住无数评审的“最后一公里”
1.1 原型里的多角色，到底在模拟什么
多角色登录原型，本质上是模拟真实系统中的“身份控制”逻辑。放在后台产品里，最常见的角色就是管理员、运营、普通用户三种：管理员看到数据总览和成员管理入口，运营看到任务工单和审核列表，普通用户看到个人中心和订单记录。更严格一点的系统，同一张订单列表也会因为角色不同，行级操作按钮都不一样。
但很多教程直接把重点放在“画三个长得不一样的页面”上，这就本末倒置了。多角色登录原型真正要解决的问题是：登录成功后，系统根据当前登录者的身份，渲染不同的信息架构。你可以把 Axure 原型当成一个简化版的前端框架，把角色当成一个全局状态，所有页面组件都根据这个状态决定显示内容。架子搭对了，后面页面做得再粗糙，逻辑也是清晰的。
1.2 我见过最典型的三种翻车做法
第一种，所有角色共用一套登录后页面。登录按钮“单击 -> 打开链接”完事，根本不存在角色差异。评审现场老板一问“管理员和普通用户看到的一样吗？”就冷场。
第二种，复制三个主页面，分别改成管理员版/运营版/用户版。信息倒是勉强齐全，但后面只要公共样式改一处，比如顶部导航加个 logo，就要同步改三个页面，遗漏一个就前后对不上。
第三种，只做了登录页，登录成功之后弹个提示“登录成功”，然后没有然后了。这种原型连演示都撑不过三十秒。
这三种做法的共同病根，是把“登录”当成了终点，而没有把“登录后的身份”当成整个原型的数据源头。
1.3 合格的多角色登录原型，应该满足什么标准
我给自己定过四条约稿标准，你可以拿去直接当验收清单：
- 一次登录，全程生效：登录时确定的角色，在后续所有页面切换中都保持有效，不需要重复登录。
- 角色差异由数据驱动：不是靠“复制页面改文案”，而是由一个全局变量（比如 role）统一控制。
- 有基础权限边界：用户未登录时直接打开主页面，会被弹回登录页；登录状态下访问登录页，也会被带回主页面。
- 演示好讲故事：评审现场我可以快速切换身份，给不同角色演示对应界面，不用重新关浏览器开页面。
按这个标准来做，你的原型就不再是几张静态稿，而是一个能跑通完整业务闭环的交互 demo。
2. 动工前的架构决策：页面怎么分，登录态往哪放
2.1 先别急着画页面，选好架构方案
我在重做这套原型时，先花半小时想了三个方案，最终选了第三个。方案对比给你列出来：
| 方案 | 做法 | 优点 | 缺点 |
|---|---|---|---|
| A. 多页面复制 | 登录页跳转到不同角色的独立页面 | 直观，适合角色数量少、页面差异极大的场景 | 公共部分难维护，角色越多越乱 |
| B. 单页面动态面板 | 登录页和主页面都在一个页面里，用动态面板切换 | 交互流畅，不需要页面跳转 | 页面层级深，评审时演示不贴近真实站点结构 |
| C. 登录页+主页动态面板（推荐） | 登录页是独立页面，主页面独立页面，主页内部用动态面板切角色状态 | 贴近真实产品，公共结构统一，角色内容隔离 | 需要理解页面级跳转和面板状态切换两层逻辑 |
我用的方案 C。原因很实在：真实产品里，登录页和主站一定是两个 URL，让人家技术同学看原型的时候，也能对应上“这里会路由跳转”。但主站内部的管理员首页/用户首页，通常共用同一套布局框架，只是内容区不同，这正是动态面板最擅长处理的场景。
2.2 全局变量：整个原型的“内存空间”
多角色登录的核心，是几个全局变量。Axure 的全局变量面板（顶部菜单“项目 -> 全局变量”）里，我会建三个变量：
| 变量名 | 初始值 | 用途 |
|---|---|---|
| role | 空 | 存角色标识，登录成功后写入 admin / user |
| userName | 空 | 存当前登录账号，用于欢迎语等展示 |
| isLogin | 0 | 存登录状态，1 表示已登录，0 表示未登录 |
这里有两个细节提醒一下。第一，Axure 全局变量默认按字典序排，命名时别用“角色”“账号”这种中文名，后面写条件判断的时候，中英文混在一起特别容易看走眼。第二，isLogin 我刻意不用布尔值 true/false，而是用字符串 “0”/“1”。因为 Axure 全局变量在条件判断里对布尔值的处理有时候很拧巴，用字符串最稳。
2.3 页面树规划
我的页面结构是这个样子：
- Login（登录页）
- Main（主页面）
- 角色内容区（动态面板 pnl_main）
- state_admin：管理员首页
- state_user：普通用户首页
- 角色内容区（动态面板 pnl_main）
如果角色变成三个，就再增加一个 state_operator。动态面板的状态数控制在 3 个以内时维护成本还扛得住，超过 3 个我会建议拆独立页面，后面第 6 节单独聊。
3. 登录页搭建：卡片式角色选择比下拉框耐看
3.1 登录页的元素清单
登录页不需要复杂花哨，但分工要明确。我从上到下摆了这几个元素：
- 品牌 logo 区（一个矩形放文字即可）
- 用户名输入框：命名为 inp_username
- 密码输入框：命名为 inp_password
- 角色选择区：管理员卡片 card_admin、普通用户卡片 card_user
- 登录按钮：命名为 btn_login
- 提示文字标签：命名为 tip_message，默认设为不可见
命名这件事，我建议你从一开始就养成习惯。后面写条件判断的时候，元件列表里清一色的 inp_username、card_admin，逻辑一眼就懂；你要是起名叫“用户名框”“admin卡片”，倒也不是不能用，只是当交互分支多起来，光找元件就得找半天。
3.2 卡片式角色选择的交互实现
为什么不用下拉框？原因是“选择身份登录”在真实产品里越来越常见，比如商家端和买家端互切、管理端和用户端分离，卡片式选择比下拉框更有产品感，演示时也更有细节可讲。
实现方式：
- 放两个大小一致的矩形，管理员卡片写“管理员”，普通用户卡片写“普通用户”。
- 选中动态面板工具里的“选中效果”，分别给两个矩形设置“选中”样式，比如选中时边框变成主题色、背景加深。
- 默认把 card_user 设为选中状态（右键 -> 选中）。
- 交互：单击 card_admin 时，设置 card_admin 选中 = 真，同时设置 card_user 选中 = 假。card_user 同理，反向操作。
这样可以保证任何时刻只有一个身份被选中。登录按钮判断时，直接看哪个卡片是选中状态，就能确定用户打算以什么身份登录。
3.3 初始化全局变量和提示文案
在 Login 页的页面加载时事件里，我把全局变量重置一遍：role 赋空、userName 赋空、isLogin 赋 0。这样每一次从这个页面进入原型，都能从干净状态开始。你可能会说，登录成功后又跳回登录页，重置变量会不会把状态删了？不会，我们会在 Main 页里加一层兜底判断，保证已登录用户不会停留在登录页，这层逻辑到第 5 节讲。
提示文案 tip_message 一开始设为隐藏，它的作用有两个：一是拦截空输入，二是提示账号密码错误。别小看这个标签，没有它，登录按钮点击后没有任何反馈，评审现场你会被问“怎么没反应”。
3.4 演示账号与密码
为了让评审时有真实感，我在原型里内置两个演示账号，直接写死在判断逻辑里：
- 管理员：admin / 123456
- 普通用户：user / 123456
你完全可以换成自己的业务账号，甚至可以在判断逻辑里多写几组，只要保持逻辑分支清晰就行。
4. 登录按钮用例：条件分支的编排顺序决定成败
4.1 分支优先级：先拦空，再验身份，最后路由
Axure 里同一元件可以添加多个“用例”（Case），从上到下依次判断。顺序非常重要。我的登录按钮用例是这样的：
| 用例 | 条件 | 动作 |
|---|---|---|
| Case 1 | 输入框 inp_username 为空 或 inp_password 为空 | 显示 tip_message，文案“请输入账号和密码” |
| Case 2 | card_admin 选中 且 inp_username 为 admin 且 inp_password 为 123456 | 设置 role=admin、userName=admin、isLogin=1，打开链接 Main |
| Case 3 | card_user 选中 且 inp_username 为 user 且 inp_password 为 123456 | 设置 role=user、userName=user、isLogin=1，打开链接 Main |
| Case 4 | 账号密码正确但与所选身份不匹配 | 显示 tip_message，文案“所选身份与该账号不匹配” |
| Case 5 | 以上都不满足 | 显示 tip_message，文案“账号或密码错误” |
为什么要这个顺序？因为空值校验是成本最低的拦截，理应最先执行；接着再判断“账号密码是否正确”；最后判断“身份和账号是否匹配”。如果你把 Case 2 写在最前面，条件命中后后面的用例就不会执行了，所以“身份不匹配”这种提示永远不会出现。
4.2 条件判断的具体写法
在 Axure 里点击 btn_login，添加“单击时 -> 添加条件”，然后按如下方式配置 Case 1：
- 条件 1：元件 inp_username 的元件文字 等于 空
- 逻辑关系选“或”
- 条件 2：元件 inp_password 的元件文字 等于 空
这里注意：Axure 判断“空值”不是填一个空格，而是在值区域空着不填，或者直接选择“空”。我和不少新手交流过，他们常在值区域打一个空格，导致判断永远不成立，排查半天才发现是这里的问题。
Case 2 的写法是三个条件用“且”连接：
- 元件 card_admin 的选中状态 等于 真
- 元件 inp_username 的元件文字 等于 admin
- 元件 inp_password 的元件文字 等于 123456
Case 4 要判断“账号密码正确但与身份不匹配”，我可以偷个懒，用两个条件组合：inp_username 等于 admin 或 inp_password 等于 123456 都不足以表达“一组账号整体匹配”，所以稳妥做法是在 Case 4 里多列几组：
- 且：card_admin 选中 且 inp_username 为 user 且 inp_password 为 123456
- 或：card_user 选中 且 inp_username 为 admin 且 inp_password 为 123456
这样两个分支合并成一个用例，提示“所选身份与该账号不匹配”。
4.3 给用例命名，也是在给评审讲故事
Axure 允许给每个用例重命名。我强烈建议你把 Case 1 改成“空值拦截”，Case 2 改成“管理员登录”，Case 3 改成“普通用户登录”，Case 4 改成“身份不匹配”，Case 5 改成“密码错误兜底”。
原因有两点。第一，自己在后期维护时，打开交互面板看到的是业务语义，不用一个个点开看具体条件；第二，评审时把交互面板投出来，给技术同学看分支结构，一份带命名的用例列表就是一份缩略版时序逻辑，比嘴上讲清楚得多。
4.4 登录成功后的跳转方式
打开链接时，我选“当前窗口”，而不是“新窗口”。多角色登录演示中，新窗口会带来两个麻烦：一是浏览器标签页变多，评审容易被分散注意力；二是全局变量在新窗口的会话存储不一定可控，容易造成登录态丢失的假象。所以全部用当前窗口跳转，路径是 Login -> Main，返回则是 Main -> Login。
5. 登录后的角色差异落地：首页、菜单与权限守卫
5.1 用动态面板承载三种角色首页
Main 页面里，我放了一个动态面板 pnl_main，宽度撑满内容区，里面建三个状态：state_admin、state_user。每个状态里我各放了几张由矩形拼成的假数据卡片，比如管理员状态是“成员总数”“待审核数量”“数据趋势”，用户状态是“我的订单”“常用功能”“消息通知”。
这样设计的好处是，Main 页面只有一个，地址统一，但内容区会根据角色变量切换成不同的状态。评审时切换身份，用户看到的是同一套框架下的不同业务界面，非常接近真实系统的体验。
页面加载时的交互这样写：
- 添加“页面加载时 -> 添加条件”
- Case 1：如果全局变量 isLogin 等于 0，打开链接 Login（当前窗口）
- Case 2：如果全局变量 role 等于 admin，设置 pnl_main 为 state_admin
- Case 3：如果全局变量 role 等于 user，设置 pnl_main 为 state_user
这套逻辑把“进入主页面”和“渲染角色内容”绑定在一起，确保只要到了 Main，就必然有一份对应当前角色的首页。
5.2 导航菜单随角色切换
首页内容切了，左侧菜单也得跟着变。我在 Main 页面左侧放了另一个动态面板 pnl_menu，状态 adminMenu 和 userMenu。两个状态里分别画几个菜单项矩形，管理员菜单是“数据看板”“用户管理”“系统设置”，用户菜单是“我的工作台”“我的消息”“个人资料”。
在页面加载时，跟着 pnl_main 一起切换。这里的诀窍是：菜单和内容区是两个独立的动态面板，不要包在一起。因为真实系统中的侧边栏和内容区本来就是两个组件区域，分开控制以后，你想做“菜单不变只换内容区”的过渡也更灵活。
5.3 已登录用户访问登录页，自动弹回主页面
既然 Main 页加载时会检查 isLogin，那 Login 页也得有对应守卫，否则会出现这样的怪现象：登录成功进入 Main，然后用户手滑点了浏览器回退，又回到 Login 页面，整个登录态看起来“消失”了。
解决办法是在 Login 页的页面加载时事件里加一个守卫：
- 如果全局变量 isLogin 等于 1，打开链接 Main（当前窗口）
这样无论用户从哪个入口回到 Login 页，只要登录态还在，都会被立刻拉回主页面，从体验上就模拟了“已登录用户不需要重复登录”的常规逻辑。
5.4 把当前角色显示在页面上
我习惯在 Main 页顶部放一个用户信息条，显示“你好，[[userName]]（[[role]]）”。这里的 [[ ]] 是 Axure 引用全局变量的语法。你可以把 userName 和 role 组合成可读文案，比如用条件判断把 admin 转换成“管理员”、user 转换成“普通用户”，直接展示在右上角。
这样做的价值在你评审时体现得很明显：你切换身份登录后，页面上明确写着“你好，admin（管理员）”，评审者能立刻确认当前演示的是哪个角色的视图，不会出现“你刚才说的是哪个账号来着”的困惑。
6. 实测排坑：刷新丢状态、回退越权与角色膨胀
6.1 刷新页面之后，全局变量到底还在不在
这是个高频问题。Axure 生成的 HTML 里，全局变量默认存在浏览器的会话存储中。我的实测结果是：同一个浏览器标签页内按 F5 刷新，全局变量一般还在，不会丢；但如果你复制地址到新标签页或者重新打开浏览器，变量就会恢复成初始值。
针对这个限制，最稳妥的做法就是我在第 5 节写的守卫逻辑：isLogin 不等于 1 就回登录页。这样哪怕评审者自己在新标签页打开了 Main 地址，原型也会把他安全地送回登录页，而不是让他看到一份没有登录态、变量为空的残破页面。这套兜底属于“用逻辑对抗工具限制”，也是原型健壮性的体现。
6.2 浏览器回退造成的“假登出”
除了登录成功后的回退，还有另一种回退场景：用户在 Main 页面里切了几个动态面板状态后按回退键，可能整个数据流混乱。Axure 是纯前端工具，不可能拦截浏览器回退行为，但我们可以通过页面加载时的守卫，把回退后停在 Login 页的问题解决掉。这也算一种“带痛但不致命”的妥协方案，真正要彻底解决，还是得靠实际产品里的路由控制，原型阶段别花太多时间在这里。
6.3 动态面板切换的动画处理
pnl_main 切换状态时，如果直接用默认“无动画”，角色内容切换会非常生硬；如果切的是差异很大的页面，还会让人恍惚“是不是整个页面跳走了”。我建议在条件切换到角色状态时，给动态面板加一个“淡入”动画，时长 400ms 左右。注意，菜单和内容区如果同时切换，不要两个面板都加动画，否则会出现明显的双层闪动。我通常是内容区加淡入，菜单区直接切无动画，视觉上更稳。
6.4 角色数量膨胀之后，怎么重构
当角色超过 3 个，动态面板状态会暴增到一个不好维护的程度。我的经验是：角色多的时候，别硬塞在动态面板里。改用“角色路由页”，也就是给每个角色建一个独立页面，Main 页面只负责根据 role 变量决定打开哪个角色的页面入口。管理员、运营、客服、财务……每多一个角色就多一个页面，逻辑上更加清晰，也符合真实后台系统独立模块的设计习惯。
6.5 进阶玩法：用中继器模拟账号库
如果你希望原型里能“真实校验”一批账号，而不是只写死两组，可以尝试用中继器做一个小型账号库。大致思路是：中继器里存用户名、密码、角色三列数据，登录时给中继器添加筛选条件，匹配输入的用户名和密码，然后用中继器可见行数量判断是否找到账号，再从命中的行里读取角色字段赋给全局变量。
这个方案比写死判断要更接近真实后端的校验逻辑，但 Axure 没有特别直接的“按主键取值”函数，需要借助筛选、可见行统计和隐藏文本中转，实现起来有点绕。如果你时间充裕可以尝试，但第一版原型我建议先用第 4 节的静态判断方案，先把逻辑跑通，再考虑升级。
写在最后：多角色登录原型的演示小技巧
这套原型做完之后，我特别建议你在 Login 页底部加一排“快捷入口”，三个小按钮分别写着“一键登录：管理员”、“一键登录：普通用户”。每个按钮的交互不用走输入框，直接设置对应全局变量然后跳转 Main。这样评审现场你要切换身份，一次点击就能完成，远比一个一个敲账号密码来得高效。
我个人在使用中还发现一个心得：多角色登录原型的价值，不只是展示界面差异，而是帮需求方把“谁能干什么”这个话题提前暴露出来。评审时你带着角色切换的演示去，往往比带着几十页标注文档更能推动决策。这套用全局变量 + 动态面板 + 条件判断搭起来的原型，说到底，就是用原型语言把“权限决定界面”这句话讲清楚了。
