刚开始接触Axure原型设计的时候遇到“多角色登录”这种需求我第一反应也是有点懵不就是登录页加个下拉框选完角色跳转到对应页面吗等真正做完一轮再回头看才发现这里面的坑远比想象的多。角色判断、权限差异、菜单显隐、登录状态重置每一项都藏着不少细节。这篇教程我想把多角色登录原型的完整做法拆开讲透从设计思路、页面规划到全局变量、条件判断、中继器模拟账号库再到常见的坑和排查思路全部一次说清楚。不管你是刚入门Axure的新人还是已经能用动态面板做交互的产品经理这篇文章都值得花十分钟仔细看一遍。1. 多角色登录原型的设计思路与方案选型1.1 多角色登录原型真正要解决的是什么问题先说一个很多新手会踩的误区。做后台产品、B端系统、企业内部平台时客户经常提一个需求“登录页能区分管理员、运营、普通用户不同角色进去看到的东西不一样。”新手一听马上就想那我在登录页放三个按钮分别跳转到三个页面不就行了这样固然能演示但它只是“三个入口跳三个页面”并不是真正意义上的多角色登录。为什么这么说因为多角色登录原型背后本质上要解决的是三件事身份识别系统怎么知道当前登录的是谁是什么角色分支控制登录后跳转到哪里不同角色进入的首页、菜单、内容区域有什么区别状态保持在原型内部角色身份如何传递切换页面后是否还记得当前用户如果只做静态跳转评审的时候别人会问那密码错误怎么办输入不存在的账号怎么办不同角色的菜单权限怎么体现刷新页面之后为什么又回到登录页了所以一个合格的Axure多角色登录原型至少要能模拟出“账号密码角色判断→按角色跳转→显示对应权限内容”的完整链路。1.2 三种主流实现方案优缺点对照我见过很多产品经理做多角色登录方法五花八门。归纳下来主要有三种方案适用的场景完全不同。先看方案A登录页放三个角色按钮每个按钮直接打开对应首页。这个方案最无脑三个按钮、三个交互事件写完收工。优点是快适合低保真demo、内部快速验证缺点是没有登录校验也没有账号密码输入过程根本没法演示“错误提示”“权限拦截”等真实逻辑。如果客户要求高保真原型这个方案基本过不了评审。方案B统一登录页通过全局变量记录当前角色再用条件判断控制跳转。这个方案是我个人用得最多的。登录页保留账号、密码、角色选择点击登录后做字符串比较如果账号密码匹配就设置全局变量userRole然后跳转到对应角色的首页如果不匹配就弹出提示。这种方式能模拟真实登录的基本流程同时不依赖额外的数据容器维护成本低适合大部分产品演示。方案C登录页中继器账号库动态面板权限渲染。这是最接近真实系统的做法。所有账号密码数据放在一个中继器里登录时先筛选匹配账号再校验密码再按角色跳转。后续的菜单显隐、内容区展示也全部基于变量和动态面板状态动态渲染。优点是真实感极强适合用户测试、给开发做交互评审缺点是搭建时间更长动态面板状态多了之后维护复杂。三种方案没有绝对的好坏关键看需求场景。我的习惯是如果时间紧且只是内部过一遍流程用方案A或B如果要做正式演示、给客户走查、甚至给开发当交互参考那直接上方案C。1.3 我推荐的组合方案与页面结构这篇教程里我打算按“BC混合”的方式来讲。具体结构是登录页还是那一个账号、密码、角色选择都放在上面登录校验则用中继器来做登录成功之后不是单纯跳转三个完全独立的页面而是通过“母版动态面板”的组合来实现权限内容差异。页面结构上至少要包含这些页面login登录页home_admin管理员首页home_user普通用户首页home_auditor审核员首页以及一个用来承载公共弹窗、提示框的页面或组件区如果不想做三个页面也可以把一个页面里的内容区用动态面板分成三个状态分别对应三个角色然后用变量控制显示哪个状态。这个取舍我在后面的章节里展开讲。页面层级清晰是后面所有交互逻辑能够顺利实现的前提。如果页面命名混乱条件判断引用错页面排查问题会非常痛苦。2. 动手第一步页面规划与组件准备2.1 页面层级与命名规范建议经常有同学做完原型发现交互怎么都对不上最后一看页面命名全是“页面1”“页面2”“副本页面3”。这不仅影响维护还会让条件判断和跳转选择变得极其混乱。我的建议是新建项目之后先把页面层级建好统一用英文小写下划线的命名方式。举个例子loginhome_adminhome_userhome_auditorcommon_tip提示弹窗页common_header顶部导航母版页关于母版也顺便说一句。Axure里的母版Master功能非常适合做多角色登录场景下的公共框架。顶部导航、侧边栏、底部信息这些三个角色首页都会用到的公共部分直接建成母版然后拖到三个页面里。后期改一个地方三个页面同步更新省去大量重复劳动。2.2 登录页组件布局与属性设置登录页是用户看到的第一张脸也是多角色登录逻辑的起点。布局上我不多啰嗦核心是这几个组件账号输入框密码输入框角色选择控件登录按钮提示信息区或弹窗先说密码框。这是很多新手最容易忽略的细节。拖一个文本框进来默认情况下输入密码会明文显示这在演示时特别尴尬。正确的做法是选中密码框在右侧“属性”面板里找到“Input Type”把它从“Text”改成“Password”。这样发布预览之后密码输入就会显示为圆点符合真实系统的体验。再说角色选择控件。这里有两种主流做法一种是用下拉列表框把“管理员”“普通用户”“审核员”作为选项放进去。优点是节省页面空间适合角色多的场景缺点是用户要多点一次交互过程多一步。另一种是放三个单选按钮或者干脆做成三个可点击的卡片按钮。优点是直观用户一眼就知道有几个角色可选点选效率高缺点是页面占地方。如果是给B端后台系统做原型我更推荐“单选按钮组”。因为后台登录页通常设计简洁角色选择做成单选组交互路径更短演示时也更容易讲清楚。组件摆好之后还有一个好习惯给每个关键组件命名。账号输入框叫txt_username密码框叫txt_password登录按钮叫btn_login角色单选组叫radio_role。命名起的规范一点后面写条件判断时你就能快速从下拉列表里认出组件不用一个个点开看。2.3 三个角色首页如何设计差异化登录页搞定之后就要规划三个角色首页了。这一步不要等到做交互的时候才想应该在搭建页面框架时就提前设计好每个角色的权限差异。我举一个常见的业务场景一个后台管理系统里有管理员、普通用户、审核员三种角色。管理员首页看到的是全局数据看板、用户管理入口、系统设置菜单、所有业务模块的权限。普通用户首页看到的是个人工作台、订单列表、个人信息维护侧边栏菜单比管理员少一大截。审核员首页看到的是待审核列表、审核记录、流程进度菜单更垂直。这些差异不光体现在菜单上还体现在首页内容区。所以做原型时三个页面要有意识地做出不同而不是复制粘贴只改个标题。从技术实现手段上看每个角色首页都用同一个顶部导航母版然后侧边栏和内容区分别处理。侧边栏可以直接在页面里放不同菜单内容区则按角色摆放对应卡片和列表。3. 核心交互逻辑全局变量、条件判断与中继器账号库3.1 定义全局变量角色、用户名、登录状态多角色登录的核心是“状态传递”。而Axure里记录状态最常用的手段就是全局变量。在Axure RP 9中你在页面里定义的是局部变量只能在当前页面用而全局变量可以在整个项目文件的所有页面之间共享。对多角色登录来说至少需要这三个全局变量userRole记录当前角色登录成功时赋值为“admin”“user”或“auditor”userName记录当前登录用户名方便首页做个性化展示loginStatus记录登录状态可以赋值为“1”表示已登录赋值为“0”表示未登录为什么要单独搞一个loginStatus因为后续页面里可能会做部分区域“仅登录后可见”的逻辑比如右上角显示当前用户名、未登录时显示“登录/注册”按钮。用loginStatus做全局判断比单纯依赖userRole更灵活。定义全局变量的路径很简单在Axure RP 9顶部菜单栏选择“项目 → 全局变量”或者在页面上方的项目名称旁边点开快捷菜单就能看到变量管理窗口。最后强调一点变量命名建议用英文不要用中文。虽然Axure支持中文变量名但在表达式拼接、函数调用时容易出编码问题排查起来非常麻烦。3.2 登录按钮交互条件分支怎么写最稳妥变量定义好了接下来就是登录按钮的交互逻辑。这一步是多角色登录原型里最关键的一个环节。选中登录按钮在右侧交互面板里选择“单击”事件点击“添加条件”。这里要理解Axure条件编辑器的工作方式一个交互事件可以添加多个Case也就是多个分支。每个Case可以设置一个或多个条件所有条件都满足时才会执行这个Case里的动作。对多角色登录来说我的习惯是先做“角色账号密码”三条件同时匹配的分支再做错误提示分支。举例第一个Case的条件设置如下条件1变量userRole 如何判断其实还没赋值这里应该判断的是登录框内容。如果角色选择用的是单选按钮组判断条件可以写成radio_role 的选中项 “管理员”同时txt_username 的文本 “admin”同时txt_password 的文本 “123456”三个条件用 and 连接满足后执行动作设置全局变量userRole为“admin”、userName为“admin”然后打开home_admin页面。第二个Case类似判断单选按钮组选中项是否为“普通用户”同时账号等于“user”、密码等于“123456”满足后跳转到home_user。第三个Case判断“审核员”对应跳转到home_auditor。第四个Case就是所有不满足的情况——弹出一个提示框显示“账号、密码或角色不对请重试”。这里要特别留意条件编辑器里的一个细节有些同学会把“变量值”和“部件值”搞混。在条件编辑器里如果你要判断的是页面某个输入框的内容要先在左侧选择“部件文字”然后选择具体的输入框组件如果你要判断的是全局变量才选择“变量值”。选错对象条件永远不成立。另外一个细节是字符串比较的严格性。Axure的字符串判断区分大小写而且不做自动去空格。如果用户在账号框里不小心多打了一个空格条件就匹配不上。这个我在后面“常见问题”里专门展开。3.3 进阶做法用中继器模拟账号库上面的写法有一个局限性账号密码是“写死”在条件判断里的。如果我要加一个测试账号就得去改条件判断非常麻烦。更接近真实系统、也更方便后期维护的做法是把账号数据放进中继器通过筛选匹配来校验登录。具体操作分这么几步第一步从元件库拖一个中继器到页面任意位置。你可以把它放在登录页的角落设置成不可见。反正用户不会看到它它只负责提供数据。第二步给中继器添加数据列。双击中继器进入数据管理界面添加四列username、password、role、displayName。然后填入测试数据比如admin / 123456 / admin / 系统管理员user / 123456 / user / 普通用户张三auditor / 123456 / auditor / 审核员李四第三步写登录逻辑。选中登录按钮在单击事件里添加条件这次要先对中继器做筛选。这里有一个Axure的复杂逻辑要实现建议拆成两步先设置中继器筛选条件筛选username txt_username的文本。然后判断中继器中的“可见行数”是否大于0如果大于0说明账号存在再取出第一行的password和role与密码框输入、角色选择做二次匹配。实际在做的时候中继器筛选用的是“添加筛选器”交互动作而取可见行数则需要通过表达式来实现。判断条件的表达式大致是[[repeater_users.visibleItemCount]] 0然后再加一层判断中继器某一行数据的password是否等于txt_password的文本。这个可以通过条件编辑器里的“值列表”选择“中继器 → 行 → 列值”来引用。这样做的好处是以后要加测试账号直接在中继器里加一行数据就行不用再去改交互逻辑。真实感也会强很多客户在演示时输入任意不存在的账号都能正确进入错误提示分支。3.4 登录跳转后的权限控制页面加载时读变量跳转到对应首页只是第一步。到了首页之后页面要根据当前角色动态展示内容。这块逻辑一般放在页面加载事件里。在home_admin、home_user、home_auditor三个页面里如果页面结构是独立的其实不用做太多判断——因为跳转本身已经区分了角色页面本身就是对应角色的专属页面。真正需要做判断的是那些“共用的区域”。比如每个页面右上角都要显示当前登录用户名这个区域的初始化就要看全局变量userName的值在页面加载事件里添加条件如果变量userName不等于空字符串就把某个标签文本设置为“欢迎[[userName]]”。再比如公共的侧边栏母版里有些菜单只有管理员能看到。那也需要在母版的页面加载事件里判断userRole然后动态隐藏或显示对应菜单项。如果采用“一个页面动态面板状态”的方式页面加载时就要根据userRole把内容区动态面板切换到对应状态。这块我在下一章详细展开。4. 菜单权限与内容展示动态面板到底怎么用4.1 三个独立页面 vs 一个动态面板页面在架构选择上很多人纠结角色首页到底是做成三个页面还是合成一个页面用动态面板控制我的看法是页面框架的公共部分差异不大时用“一个页面动态面板”更优雅如果三个角色的内容区差异极大、页面结构完全不同那直接做三个页面更清晰。多角色登录最常见的后台场景顶部导航是一样的侧边栏菜单有差异内容区差异更大。对于这种形态我推荐混合方案顶部导航和侧边栏框架用母版Master来承载菜单项在母版里根据userRole动态显隐页面还是做三个独立页面每个页面里的内容区按角色定制公共框架通过母版引用这种方案的好处是后期改顶部导航的“退出登录”按钮只需要改母版要增加某个角色专属的数据卡片只需要改对应页面不会互相干扰。如果确实想用一个页面演示三个角色那就在这个页面里放一个动态面板设置三个状态admin状态、user状态、auditor状态。登录成功后在页面加载事件里根据userRole切换到对应状态。这里要提醒一句动态面板状态多的原型维护起来真的会很痛苦。页面加载事件、动态面板状态切换、变量初始化全都缠在一起稍微改错一个状态名称整个演示就乱了。所以我个人做高保真原型时更偏向于多页面母版的组合。4.2 菜单权限显隐的三种实现方式先整理一下菜单权限常见做法各有各的适用场景。第一种直接控制组件可见性。选中某个菜单项在页面加载事件里添加条件判断——如果userRole不等于“admin”则隐藏这个组件。做法直接适合菜单项不多的场景。缺点是菜单一多判断条件要写一大堆。第二种动态面板状态切换。将整个侧边栏菜单做成一个动态面板不同角色对应不同状态。管理员看到状态一普通用户看到状态二审核员看到状态三。这样逻辑收敛只需要在页面加载事件里根据userRole做一次状态切换。缺点是如果状态之间差异特别大动态面板内容会很多。第三种在母版里做判断。侧边栏如果做成了母版就把动态显隐的逻辑写在母版的页面加载事件里。因为所有页面都引用了这个母版逻辑只要写一遍维护成本最低。我自己在项目里最常用的组合是侧边栏菜单差异化明显时用动态面板状态切换只是个别菜单项差异时用组件可见性控制如果三个角色共用一个框架直接在母版里写全局判断。4.3 退出登录与登录状态清理退出登录这个功能看着简单但很多原型里做得非常草率直接点击跳回登录页就完了。这样做的隐患是全局变量里的userRole、userName、loginStatus都还是旧值。如果过一会儿又用另一个账号登录角色判断逻辑会出问题。所以退出登录按钮的交互必须包含“变量重置”。正确做法是在顶部导航母版的“退出登录”按钮点击事件里做三件事设置全局变量userRole为“空”设置全局变量userName为“空”设置全局变量loginStatus为“0”然后再打开login登录页。如果你用的是中继器账号库界面上已经显示了当前登录用户名退出后还要把这个显示区域清空或隐藏避免出现“人都退出登录了右上角还显示欢迎XXX”的尴尬。还有一个细节是“刷新页面状态重置”。Axure原型里的全局变量是会话级的浏览器刷新之后全局变量会回到初始值页面会重新跳到登录逻辑。这在演示时是一个天然的限制但如果你要模拟“用户已登录态”的场景比如直接在浏览器里刷新后仍然停留在首页就需要额外做处理。我一般的做法是在首页的页面加载事件里加一个判断如果loginStatus不为“1”就自动跳转回登录页如果loginStatus等于“1”就正常展示。这样反而能模拟出“未登录用户直接访问首页会被拦截”的效果汇报时是个加分项。5. 常见问题与排查技巧实录5.1 密码框不隐藏和变量命名踩坑很多同学做完原型点击预览输入密码还是明文第一反应是Axure坏了。其实不是是你没把“Input Type”改成Password。这个属性在右侧属性面板里选中密码框就能看到默认是Text改成Password之后预览刷新一下才会生效。另外变量的命名问题一定要引起重视。用中文做变量名虽然Axure支持但在表达式里偶尔会出现字符编码错乱尤其是老版本。我自己也踩过坑后来统一规范所有变量名、组件名、中继器列名一律英文小写加下划线。登录用户名字段就叫user_name密码就叫password页面就叫home_admin。命名越规范后面写条件判断越顺畅。5.2 条件判断匹配失败的几个经典原因做登录逻辑时最让人崩溃的是明明账号密码都对但就是进不了对应页面。我从过往经验里总结出几个高频原因。第一个原因是大小写问题。Axure的字符串比较是区分大小写的。如果账号写的是“Admin”输入框里填“admin”两个字符串不相等条件判断直接失败。为了避免这个问题一个方法是统一约定测试账号都是小写另一个方法是在表达式里调用toLowerCase函数统一转为小写再比较。第二个原因是输入框前后空格。这个很隐蔽用户在输入的时候有时会多敲一个空格肉眼看不出来。建议在判断前用Trim函数把输入内容两端的空格去掉表达式写法类似[[txt_username.text.trim()]]第三个原因是条件编辑器的比较类型选错了。Axure里有“等于”“包含”“以开头”“以结尾”等选项。如果你错选成“包含”那么“admin”判断“admin123”也会成立逻辑就不可控了。所以账号密码这种场景一定要用“等于”而不是“包含”。5.3 中继器匹配账号时取不到数据的排查思路用了中继器账号库之后最常见的报错就是“我明明给中继器加了三行数据为什么登录时匹配不上”我的排查顺序是有固定套路的先看中继器是否设置了初始化排序或筛选。如果中继器本身带了永久筛选条件比如status 1而你新加的账号status列没有写1那就会被过滤掉永远匹配不上。再看筛选条件的列名。检查中继器的数据列名是不是username还是中间多了空格、大小写不同。列名引用错误是最容易发生的问题。然后检查取数据的表达式。在条件编辑器里选中“中继器”→“行”→“列值”时要确认选的是哪一列。有时候逻辑里取的是password列结果判断的时候引用成了role列自然就出错。还有一个实用技巧调试中继器匹配逻辑时可以先把中继器设置为可见在预览的时候观察筛选后还剩几行。看到行数变化就能判断筛选条件有没有生效。5.4 Axure RP版本差异与发布注意点现在很多人还在用Axure RP 9也有人用RP 10甚至RP 11。这几个版本在多角色登录的核心逻辑上基本是通用的动态面板、全局变量、中继器这些功能都有。不过RP 9和更高版本在面板布局、部分交互属性入口的位置上有区别。比如RP 9的中继器数据管理入口在双击中继器后弹出表格RP 10/11则可能改成了不同的编辑窗口动态面板的管理界面在RP 10里也重构过。如果你看RP 9的教程用RP 10/11操作时菜单入口找不到不要慌基本就在类似的位置多找一下就能发现。另外发布原型的时候Axure自带的在线分享服务通常需要注册登录账号很多团队内部网络环境不一定方便。我个人的习惯是本地预览为主CtrlB生成HTML文件发给同事直接双击打开就能演示。这样不依赖外部服务团队内部走查也足够用。最后再分享一点我的个人操作习惯多角色登录原型做了这么多次我最大的体会是动手前先不要把重心放在元件拖拽上而是先把逻辑分支理清楚。我会在纸上画一张很粗糙的分支表列出所有角色、账号、密码、跳转页面、页面上的权限差异然后再去Axure里落地。把这张表做好后面写条件判断基本就是照抄很少返工。还有一个小技巧登录页里最好设计一个“测试账号提示区”直接把几个角色的测试账号写在登录页底部。这样演示的时候不用临时翻笔记客户也知道该填什么。这个小细节在很多项目汇报时都帮我省了不少尴尬时间。多角色登录原型看起来只是一个登录页加几个首页但它是整个后台系统原型里交互逻辑最集中、最能体现原型“高保真”价值的部分。掌握了变量传递、条件判断、中继器账号库这几个核心能力之后你会发现不光是多角色登录像权限审批流、多租户数据隔离、工单状态流转这些需求做起来都能顺很多。希望这篇教程对你有用也欢迎在实践中遇到具体问题时再回来对照着排查。