上周给一个后台产品做原型评审老板指着登录后的首页问“这个页面管理员和运营看到的怎么一模一样”我承认当时偷了懒三个角色共用了一套页面。会议室的气氛一下就变了从“看原型”变成了“讨论权限边界”方案也没讲下去。后来我把这套 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 / useruserName空存当前登录账号用于欢迎语等展示isLogin0存登录状态1 表示已登录0 表示未登录这里有两个细节提醒一下。第一Axure 全局变量默认按字典序排命名时别用“角色”“账号”这种中文名后面写条件判断的时候中英文混在一起特别容易看走眼。第二isLogin 我刻意不用布尔值 true/false而是用字符串 “0”/“1”。因为 Axure 全局变量在条件判断里对布尔值的处理有时候很拧巴用字符串最稳。2.3 页面树规划我的页面结构是这个样子Login登录页Main主页面角色内容区动态面板 pnl_mainstate_admin管理员首页state_user普通用户首页如果角色变成三个就再增加一个 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 2card_admin 选中 且 inp_username 为 admin 且 inp_password 为 123456设置 roleadmin、userNameadmin、isLogin1打开链接 MainCase 3card_user 选中 且 inp_username 为 user 且 inp_password 为 123456设置 roleuser、userNameuser、isLogin1打开链接 MainCase 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 的元件文字 等于 123456Case 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_adminCase 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。这样评审现场你要切换身份一次点击就能完成远比一个一个敲账号密码来得高效。我个人在使用中还发现一个心得多角色登录原型的价值不只是展示界面差异而是帮需求方把“谁能干什么”这个话题提前暴露出来。评审时你带着角色切换的演示去往往比带着几十页标注文档更能推动决策。这套用全局变量 动态面板 条件判断搭起来的原型说到底就是用原型语言把“权限决定界面”这句话讲清楚了。