★ FEATURED ARTICLE 做了好几年B端产品我最大的感受是原型图画得像草稿开发就敢给你还一个草稿出来。所谓Axure高保真Web开发常用组件说白了就是把导航、表格、弹窗这些天天要用的界面元素提前做成一套规范、可复用、带交互状态的元件库。我自己是从一个个页面复制粘贴开始后来踩坑踩多了才慢慢攒出一套组件体系。这篇文章不聊虚的把我在Axure里搭Web组件库的思路、命名规范、常用组件拆解、组件通信和交付开发的经验一次说清楚。1. 高保真三个字难住的是产品还是开发1.1 高保真不等于截图级还原而是状态完整很多团队一提高保真第一反应就是像素级对齐设计稿。但放到Axure原型这个场景里高保真的核心其实不是画得像而是状态完整。开发拿到一套原型最怕的不是颜色差两个色号而是不知道按钮按下去长什么样、输入框填错怎么提示、列表没数据的时候页面空着还是给个占位。这些交互状态不画清楚开发就只能靠猜猜对了是运气猜错了就是返工。我举个例子。一个最普通的登录表单看起来就两个输入框加一个按钮但如果要认真做高保真至少要覆盖这些状态输入框默认态、聚焦态、输入内容后的状态、校验错误的红框、禁用状态、按钮正常态、鼠标悬停态、按下态、加载中状态、登录失败后的全局提示。这还没算密码可见切换、记住我勾选、忘记密码入口。你把这一套状态在Axure里完整表达出来开发照着写逻辑基本不用动脑测试也能直接用这套状态列表整理用例。那这和组件化有什么关系关系太大了。如果你每个页面都临时画一遍这些状态一个项目三五十个页面光画表单就能把人画吐。更麻烦的是画完A页面后想改一下按钮的圆角B、C、D页面里的旧按钮不会自动跟着变你只能全站搜索手动改改漏了就成了线上事故。组件化就是把状态完整性这个要求和复用绑在一起一次性把状态做全之后每个页面拖出来就能用改一处全局生效。1.2 组件化解决的不只是画得快还有改得动我在早期带项目的时候吃过几次亏。有一次原型里导航菜单从5个变成7个我熬夜翻了几十个页面逐一手动加菜单项第二天还被开发吐槽导航样式不一致。那次之后我彻底想明白一件事Axure里画页面只是表象真正值钱的是可维护性。而可维护性的地基就是组件化。组件化的本质是什么是把你常用的Web界面元素抽象成可复用的零件然后给这些零件定好规则。比如导航栏做成母版所有页面拖同一个母版以后加菜单项、改Logo、调整栏高都只需要动母版一个地方。再比如表格做成中继器组件数据源统一维护排序、分页、选中这些交互都封装在组件内部普通页面只是喂数据和接事件。这样一来你画原型的重心就从一笔一笔画界面变成了组装界面就像前端工程师用组件库写页面一样。而且组件化这件事天然和前端组件库是同构的。你在Axure里定义的按钮、表单、弹窗、分页器如果命名和交互逻辑直接对标Element UI、Ant Design这类前端组件库开发拿到原型后几乎可以一一映射着写代码。这也是我后来坚持在原型里给组件写前端对应关系的原因——原型不只是给老板看的演示稿它其实是开发规范的一个可视化入口。2. 搭组件库前的底层准备命名规范、样式底座和母版思维2.1 给每一个元件起名没有命名规范组件库就是天坑在Axure里做组件库第一个要过的坎不是画功是命名。很多人画原型时元件名全是矩形1文本2动态面板3开始做单页演示没什么感觉等做组件库时就会发现问题一个弹窗里有遮罩、标题、关闭按钮、内容区、确认按钮、取消按钮你在交互面板里想精准选中关闭按钮时满屏的矩形7矩形8会让人崩溃。我的命名规则很简单就三部分模块_用途_状态全部小写加下划线。比如nav_menu_item_active导航菜单选中项form_input_error表单输入框错误态table_row_selected表格选中行dialog_btn_confirm弹窗确认按钮cart_badge_count购物车角标数字这套命名的好处有几个。第一Axure的交互用例和事件表里元件名会被大量引用名字有业务含义后期维护的时候不用一层层点进去猜。第二交付给开发时前端在写class名或变量名时可以拿你的命名当参考沟通成本直接降一截。第三如果你用Axure的元件库功能做成.rplib文件命名规范的元件在库里扫一眼就知道是干什么的团队的其他人拖起来也顺手。这里多提醒一句命名最好在画组件之前就定下来不要画完之后再批量改名。Axure虽然支持批量重命名但改完名之后已经写好的交互用例里的引用关系很容易断掉尤其是那些用文本逻辑匹配的地方断掉之后排查起来相当费时间。2.2 样式底座先定义颜色、字号、间距、圆角很多人搭组件库上来就画按钮画输入框画到一半发现每个页面的主题色都不一样左边用了#1890FF右边用了#0EA5E9最后还得回头统一。我的做法是先把样式底座作为一个专门的页面放在组件库里所有组件都从这个底座上取值不改底座的色值就不许给元件换颜色。这个底座页长什么样简单说就是一张样式规范表按模块列出所有视觉token。不需要像设计系统那么复杂但至少要包含主色、辅助色、成功色、警告色、错误色、信息灰主文字色、次要文字色、禁用文字色、边框色、分割线色字体族、正文尺寸、辅助文字尺寸、标题尺寸、行高圆角半径小圆角2px、中圆角4px、大圆角8px、全圆角999px间距以8px为基准网格8/16/24/32/48为什么强调8px网格因为现在主流前端组件库基本都遵循8px的设计规范你按照这个网格去定义组件高度和间距比如按钮标准高度32px或40px表单间距16px或24px开发拿过去几乎不需要换算。我自己做的时候甚至会把Element UI的官方尺寸直接抄进规范页毕竟前端已经帮我们验证过这套间距在真实界面上的可读性和可点性。样式底座的另一个作用是让组件库的一致性变得可检查。你不再需要靠眼睛去判断两个弹窗的圆角是不是一致直接拿规范页对照就行。这个页面对设计还原度提升的帮助比你在组件库里多画十个组件都大。2.3 母版和动态面板组件复用的两个核心容器Axure里复用一个组件主要就两个容器母版和动态面板。很多人分不清什么场景用哪个我的经验是母版管整站的静态框架动态面板管局部的交互状态。母版适合放那些在多个页面中固定出现、几乎不随页面变化的模块。最典型的就是全局顶部导航、侧边栏、页脚、Cookie弹窗。你在母版里画一次全站页面拖进同一个母版以后要调整导航菜单的文案只需要改母版本身所有引用母版的页面自动更新。这一点在Web项目里尤其好用因为B端系统的框架层几乎每个页面都一样用母版能省掉大量重复工作。动态面板则适合放同一组件在不同状态下的切换。比如轮播图的多帧切换、Tab标签的内容切换、下拉菜单的展开收起、弹窗的显示隐藏。动态面板允许你定义多个State每个State是一套完整的界面然后通过交互事件在这些State之间跳转。如果你做的是高保真原型动态面板基本就是承载交互状态的核心容器。那母版和动态面板能不能结合当然可以。最常用的做法是对外暴露的是一个母版母版内部塞动态面板。比如我做的全局弹窗母版里面放了一个动态面板动态面板的State1是空态State2是普通提示弹窗State3是带表单的弹窗。页面引用这个母版后通过事件可以动态切换母版内部的面板状态外面看起来就是同一个弹窗组件撑起了多种业务场景。这套母版动态面板的组合拳也是我做高保真Web组件库的底层地基。3. 高频Web组件的制作拆解导航、轮播、表格、弹窗3.1 顶部导航与Tab切换用动态面板管理选中态导航是Web项目的脸面但也是最容易被原型忽略交互细节的地方。很多原型里的导航就是几行文字点一下没反应、选中态也没有开发拿到手只能自己脑补高亮逻辑。我的做法是做一个导航母版把菜单项和选中态都装进去。具体拆解一下导航栏分两层上面是Logo区和全局操作区下面是菜单区。每个菜单项我建议用一个动态面板来实现动态面板里定义两个StateState1是非选中状态文字色为次要色State2是选中状态文字色为主色下面加一条2px的指示条。然后在每个菜单项上添加交互事件鼠标单击时先把所有菜单项切换到State1再把当前点击项切换到State2。这样菜单的选中态就完全可控了而且用动态面板切换状态比写一堆设置文字颜色的用例要快得多也不会出现漏改某个样式的问题。Tab切换和导航是同一个套路唯一的区别是Tab还经常带着内容面板联动。比如页面上有一个Tab选项卡和一个内容区域Tab切成方案一时内容动态面板切到第1帧切成方案二时内容切到第2帧。这时候我的习惯是把Tab的选中态和内容面板的当前帧放在同一个动态面板里管理外层动态面板有3个State每个State里同时包含Tab选中样式对应的内容区切换时整体切换。这样两个地方的联动就天然一致了不需要写同时改Tab样式和改内容帧这种容易出错的用例。3.2 轮播图自动播放和手动切换的组件逻辑轮播图几乎是Web产品首页逃不掉的组件在Axure里做轮播图其实不难但很多新手会卡在自动播放和手动切换这两个逻辑上。我的标准做法是这样的轮播图外层是一个动态面板假设有3张图就让动态面板有3个State每个State是一整张Slide包含图片、标题、描述和对应的跳转热区。然后在动态面板上设置载入时事件等待3000毫秒然后执行切换到下一帧同时勾选循环切换。这里的关键是循环选项Axure的动态面板切换状态时如果勾选了循环最后一帧之后会自动回到第一帧这样自动播放就转起来了。手动切换做起来要稍微注意一点。左右箭头各是一个按钮点击箭头时切换到上一帧或下一帧同样勾选循环。由于自动播放也在同一个动态面板上手动切换之后要防止自动播放逻辑继续跑否则会出现手动点了一下轮播图马上又被自动切走的尴尬。我的解决办法是给动态面板加一个状态变化时事件只要用户点击过箭头就重新计时。具体实现方式是在点击箭头时先停止当前自动播放的用例再切换帧然后再重新发起一个新的3秒循环。这一点虽然啰嗦但对高保真演示体验非常重要。至于轮播图下面的小圆点指示器我一般也是用动态面板做。3个圆点组成一个动态面板每个State对应当前激活的圆点位置。轮播图切换帧时顺带把指示器也切到对应的State。这样演示起来完全像真实站点开发看到原型时也能清楚地知道指示器要和当前帧联动。3.3 表格与分页用中继器承载动态数据表格是B端Web项目里最高频的组件没有之一。如果只是画一个静态表格列表页演示起来其实也还行但一旦涉及排序、分页、选中、筛选静态表格就完全撑不住了。这也是我在Axure组件库里坚持用中继器做表格的原因。中继器在Axure里的地位有点像前端里的数据数组。你可以把表数据放在中继器的数据集里每一行就是一条记录然后在每项加载事件里把数据集里的值填充到列表格的对应文本中。比如数据集里有name、owner、progress三个字段中继器模板里放三个文本框每项加载时分别Set Text到这三个文本框。这样中继器里有多少行表格就渲染多少行你再配合中继器的排序、过滤、分页功能就能够实现非常接近真实系统的表格交互。分页器我自己是做成一个单独组件和中继器配合使用。分页器里放上一页、页码按钮、下一页中间页码按钮用动态面板做当前页高亮。点击页码时先把中继器翻到对应页再把页码按钮的高亮状态切过去顺便更新共x条/第x-x条的统计文本。这套逻辑说起来复杂但只要做一次组件封装之后每个列表页都是拖分页器、填数据、绑事件三步走效率提升非常明显。还有一个容易被忽略的状态是表格空态。真实业务里列表查询结果为空是常态原型里如果不画空态开发不知道是要给个空白表格还是放一个暂无数据插画。我的习惯是给中继器加一个No Data判断如果数据集的行数为0显示一个空态面板否则显示表格主体。这个逻辑可以用中继器的添加排序或交互条件来做虽然稍微有点绕但对高保真完整度来说很值。3.4 弹窗与抽屉遮罩、层级和关闭策略弹窗和抽屉这种浮层组件看起来只是显示/隐藏两个动作但真做起来细节不少。第一个细节是遮罩。弹窗出现时通常页面背后要盖一层半透明遮罩用来阻隔点击和集中注意力。在Axure里我会先把遮罩做成一个动态面板背景色用黑色透明度40%然后把它和弹窗内容区一起放进一个浮层容器动态面板里。浮层容器初始状态设为隐藏需要弹窗时显示出来。第二个细节是关闭策略。很多原型里弹窗只有一个关闭按钮但实际Web产品往往还有点击遮罩关闭按ESC关闭。如果要高保真我是建议把点击遮罩关闭也做进去在遮罩上添加鼠标单击时→隐藏浮层容器的事件这和真实前端的maskClosable属性是对应的。有些业务弹窗不允许点击遮罩关闭比如支付确认弹窗那你在原型里就不给遮罩加关闭事件同时还要在说明里标注此处遮罩不可关闭开发就能精确对齐。第三个细节是层级。多个弹窗叠加时后弹出的弹窗应该盖在前一个上面。Axure里的实现方式是利用动态面板的排列顺序或者通过置顶操作来调整浮层的显示顺序。我一般会在组件说明里写清楚每个浮层容器需要放在页面所有内容的最上层如果弹窗A打开后再打开弹窗B需要把B容器置于A容器之上。这个细节虽然小但是多人协作时经常被忽略导致演示时弹窗被页面内容盖住。抽屉的逻辑和弹窗类似只是出现方式多了一个滑入滑出动画。Axure动态面板在切换状态时支持各种方向滑动动画比如抽屉从右侧滑入就在显示动态面板时选择进入动画-向右滑动之类的选项。这里的关键是动画的方向要和抽屉的实际位置一致否则会出现抽屉从天上掉下来的诡异效果。演示给业务方看时这种动画细节对高保真感的贡献非常大。4. 把交互做扎实状态切换与组件通信4.1 每个组件都要备好一套状态集高保真和低保真最本质的差别就是高保真把组件的状态集画全了。我在做组件库时会强制自己为每个交互组件列一张状态清单清单上不列满就不允许收工。拿最基础的按钮来举例状态集至少是状态触发条件视觉表现默认页面加载后主色填充、常规阴影悬停鼠标移入亮度加深、阴影加强按下鼠标按下亮度再加深、内阴影禁用业务条件不可用灰色填充、禁止点击加载中提交后等待响应文案变为提交中…、按钮置灰这五个状态里前三个我建议直接用Axure的交互样式来做就是给元件添加鼠标悬停样式、鼠标按下样式。这样做成本最低而且切换很自然。但禁用和加载中这种业务状态单纯用交互样式做不了需要用动态面板来承载。所以我一般把按钮做成动态面板State1是默认/悬停/按下State2是禁用State3是加载中然后通过事件在状态间切换。表单输入框也是一样默认态、聚焦态、错误态、禁用态至少四个状态要完整。很多刚接触高保真的人会觉得这样工作量翻倍了但实际上一次的投入可以在几十个页面里反复使用。而且我自己的体会是当你把状态集列出来之后很多业务上的边界问题在原型阶段就暴露了。比如登录按钮点击后到底要不要进入加载中失败之后按钮恢复成什么状态这些问题开发也会问你现在回答总比开发写了一半再问要好得多。4.2 组件通信购物车数量如何跨页面联动Axure里经常遇到一种需求A页面里操作一个组件B页面的另一个组件要跟着变化。这其实就是原型层面的组件通信跟前端里的父子组件传值、全局状态管理是一个道理。Axure虽然没有真正的组件实例和事件总线但用全局变量加上页面载入事件基本能覆盖大多数场景。我拿一个最常见的购物车角标来拆解。需求是每个商品卡片上有个加入购物车按钮点击后页面顶部的购物车图标角标数字要加1切到购物车页面后列表里要能看到刚才加的商品。实现方式是这样的先在项目全局变量里定义一个变量cartCount初始值为0。然后给商品卡片上的加入购物车按钮添加事件鼠标单击时设置全局变量cartCount [[cartCount 1]]同时把顶部导航母版里的角标文本Set Text为[[cartCount]]。因为顶部导航是母版所有页面共用所以这个角标在操作发生的当前页面会立即更新。切到购物车页时需要让购物车列表也显示新加的商品。我的做法是在购物车页面的载入时事件里用中继器的Add Rows往购物车数据集中插入一行数据来源可以是全局变量存下来的商品ID和名称。这里有一点要特别注意全局变量在Axure里是跨页面持久化的所以只要你不刷新浏览器切页之后变量值不会丢。这就实现了跨页面的数据联动。如果组件之间的通信是同一个页面里的那就更简单了。比如列表页选中多行后底部的批量删除按钮变成可点状态并且按钮旁边的文本显示已选x项。这些都可以用点击行切换选中样式 更新全局变量 Set Text来实现。核心思路就是任何组件之间的状态同步都靠全局变量做中间人再用文本或动态面板状态把变量的变化渲染到界面上。这个思路想通之后Axure里的组件通信基本就是套公式。4.3 用例逻辑让组件从会动变成懂业务高保真组件能切换状态只是第一步真正让原型看起来懂业务的是组件上叠加的条件逻辑。Axure里用用例(Case)和条件判断来承载这种逻辑一个事件下可以挂多个CaseAxure会从上到下依次判断条件命中哪个就执行哪个。举一个登录表单的例子。点击登录按钮时真实业务的判断顺序是这样的先看用户名是否为空为空就显示请输入用户名的错误提示中止流程再看密码是否为空为空就显示请输入密码的错误提示再看密码格式是否符合要求最后才调用登录接口期间按钮进入加载中如果登录失败显示服务端返回的错误信息。这套逻辑在Axure里完全可以复现。我给登录按钮添加鼠标单击时事件加三个用例Case1如果用户名文本框的内容为空则显示用户名错误提示Case2否则如果密码为空则显示密码错误提示Case3否则执行登录成功的跳转。实际项目里还可以加加载中状态和失败分支无非是Case多几个罢了。这样做的价值很多人低估了。你把这个逻辑在原型里完整跑通开发拿到的就不再是一张静态图而是一个可视化的业务规则说明书。我在一些项目里甚至让开发和测试直接照着原型的用例写测试用例因为异常分支都已经在原型里跑过一遍了漏掉的边界情况反而更容易被发现。当然也不是所有组件都要写这么深的逻辑我的原则是核心业务流程、涉及校验和状态流转的组件一定要有逻辑纯展示类的组件保持轻量就好。5. 组件库如何反哺前端交付物与命名映射5.1 把Axure组件和前端组件库一一对应做组件库最大的隐形收益是对齐前端。现在稍微成熟一点的Web团队基本都会用Element UI、Ant Design、Vant这类现成的前端组件库。你在Axure里画组件的时候如果能主动朝前端组件库的规格靠后面开发和设计之间的翻译成本会低很多。我的习惯是在组件库里专门建一个Mappings页面把Axure组件和前端组件放成一张对照表。比如Axure里的dialog_btn_primary对应Element UI的el-button typeprimaryAxure里的table_pagination对应前端组件库的el-paginationAxure里的级联选择器对应Vant的级联选择组件。每一条映射里除了名字对应还要写清楚差异点比如Axure里弹窗宽度定的是480px前端组件库默认宽度可能不同需要以原型标注为准。为什么要做这件事因为原型最终是要被开发还原成代码的。如果原型里的组件结构和前端组件库完全脱节开发就得从零复刻一套样式既慢又容易跑偏。反过来如果原型组件在尺寸、状态、交互细节上本来就参考了前端组件库开发在写代码时几乎可以照抄组件库的API保持一致性的成本大大降低。我在项目里发现这种映射表做得越细还原度越高开发跟产品之间的争议也越少。这里还要提一个热词里反复出现的组件通信。很多前端组件库的组件之间存在事件交互比如父组件向子组件传值、子组件向父组件发消息。你在Axure里设计组件时也最好把这种数据流在命名和注释里体现出来。比如一个表单组件我会注明提交按钮点击后需要把表单数据传给全局变量formData再由详情页读取展示。这样开发在接前端组件通信时思路会非常清楚。5.2 标注、说明和切图开发最需要的三件套很多产品经理觉得Axure原型的注释标注是多余的反正开发能看懂页面。我一开始也这么想直到有开发因为间距差2px来来回回问我三次之后我彻底改了这个习惯。现在我交付原型时除了页面本身一定会附上三样东西标注说明、交互说明表、关键切图资源。标注说明我通常放在每个页面的右侧空白区用编号和引线指到对应的组件位置。标注里只写开发真正需要的东西宽度高度、内边距、圆角、字号、色值、间距。如果组件是从样式底座取的值我会直接写颜色取自主色见样式规范页#1而不是每个地方都复制一遍色号这样也方便后续统一改色。交互说明表是另一个好用的工具。我常用的格式是序号 | 触发元素 | 触发方式 | 交互反馈 | 跳转目标 | 异常分支。拿弹窗举例序号触发元素触发方式交互反馈跳转目标异常分支1删除按钮单击弹出确认弹窗显示确定删除该条数据无无2弹窗确定按钮单击关闭弹窗表格移除对应行顶部提示删除成功当前页无3遮罩单击关闭弹窗无支付类弹窗禁止遮罩关闭这张表比原型页面本身更值钱因为它是交互逻辑的结构化表达测试可以直接拿它转测试用例开发可以直接拿它写分支逻辑。切图资源这块Axure原生的导出能力没那么强但组件库里的通用图标、Logo、插画我一般会让设计师从设计稿里导出SVG放到原型对应的文件夹里开发需要的时候直接取用不用再从原型里截图抠图。图标在原型里能用SVG就尽量别用位图放大缩小不变形演示效果也更好。5.3 用版本记录沉淀决策而不是靠口口相传组件库不是做完一次就结束的东西它会随着业务迭代不断变化。今天改导航的间距明天给表格加一个行内操作按钮后天又调整按钮圆角。这些改动如果不做版本记录一个月后你很难说清楚当前组件库到底哪一版是权威版本前端更不知道应该对齐哪个版本。我自己的做法是在组件库里放一个Change Log页面每一行记录一条变更字段包括版本号、日期、变更内容、影响范围、前端是否已完成同步。版本号我习惯用V1.0、V1.1这种大版本跳号时意味着有破坏性改动比如整体换了主题色这种改动不仅要记录还要提前一周告诉前端和所有用组件库的人。小版本改动就只是细微调整记录一下即可前端同步后打个勾避免后面扯皮。另外有一点很重要组件库文件的命名也要带版本号。不要出现最终版终极版打死不改版这种文件命名团队协作里这就是灾难。我一般是web_components_v1.2.rp这种命名每次改动另存为新版本文件旧的留档万一新版本改崩了还能回退。这个方法我在多个项目里都验证过成本极低但带来的安全感很高。6. 踩坑记录与提效技巧版本、性能和多人协作6.1 性能问题动态面板不是越多越好高保真组件做多了Axure文件会越来越卡这个坑我踩得特别深。有一年我做一个大型B端项目原型里到处是动态面板轮播图、下拉菜单、弹窗、Tab切换全用动态面板结果预览页面要等好几秒才能打开演示现场特别尴尬。后来我总结出一个规律动态面板虽然能做状态切换但它不是不用成本的。每个动态面板在预览时都要额外计算当前显示哪个State页面里动态面板数量多了性能自然下降。所以我现在的组件库里有一个明确的分层简单的视觉状态变化尽量用Axure的交互样式也就是悬停、按下、选中等样式切换不用单独占用动态面板。复杂的业务状态比如表单的加载中、表格的空态、弹窗的显示隐藏才用动态面板承载。能不用动态面板的地方坚决不用。中继器也是一样的道理。中继器能模拟动态数据但它本质上是一个循环渲染列表数据量越大预览越卡。我在原型里一般把中继器的演示数据控制在50行以内超过50行就用查看更多的分页逻辑来模拟而不是真的放几百行数据进去。图片资源方面原型里的位图尽量压缩后再导入能用SVG的图标优先用SVG这些习惯都能让原型保持流畅。6.2 多人协作的组件库维护权限、更新通知与回归组件库发展到一定规模往往是产品团队、交互团队、UI团队一起维护。这时候最大的风险不是没人做组件而是每个人都改了一版组件库最后不知道以谁为准。我在实践里吃过亏所以现在会明确几条协作规则。规则一是一个Owner。组件库必须有一个明确的负责人其他人可以提交建议、可以答疑但一切组件库元素的增删改都得经过这个Owner。Owner的职责是保证命名一致、状态完整、风格统一同时负责对外发布更新通知。这个角色不一定是很资深的人但一定要有维护组件的责任心。规则二是改动必通知。每次更新组件库都要在那个Change Log页面里写清楚并且在项目群发一条简短通知列出版本号、改动点、是否需要页面重新引用。为什么一定要通知因为Axure的母版在页面里默认是跟随母版更新的但你如果改的是动态面板内部的结构已经放置的实例不一定能自动更新干净需要手工重新拖入或者重置母版实例所以必须让大家知道这里需要动一下。规则三是大改必回归。如果组件库做了大版本改动比如换了全套间距规范那就需要抽查核心页面包括首页、列表页、详情页、表单页确认这些页面的视觉和交互没有因为组件更新而出问题。这个回归不一定要很重但必须做一遍否则很有可能出现C页面按钮正常D页面按钮错位这种问题。6.3 提高效率的小习惯模板页、自定义元件库和克制的高保真最后分享几个我这些年攒下的关于Axure效率的小习惯每一个都算不上复杂但加起来能省很多事。第一个习惯是创建模板页。组件库之外我会再维护一套完整的模板页面比如带侧边栏的标准后台布局、带顶部导航的营销页布局、移动端列表页布局。新项目启动时直接复制这套模板页作为画布把Logo、菜单、模块换成新业务的半天就能跑出一个高保真的雏形。比从空白页面开始画不知道快了多少倍。第二个习惯是用Axure的自定义元件库。把做好的组件拖进一个.rplib文件然后在元件库面板里加载它。这样你在任何新项目里都能像用Axure自带元件一样从库里把组件拖到画布上。而且元件库支持团队共享大家用同一个元件库才能保证所有原型的风格基本一致。第三个习惯是克制高保真的范围。不是所有页面都值得做到同样的高保真度。我的取舍标准是核心业务链路、需要用户评审的页面、开发容易理解错的复杂交互一定要高保真而像隐私协议、数据公告、纯文本展示这类页面用线框图或者占位说明就可以了。这样既保证了关键体验的原汁原味又不会让组件库的维护成本把自己拖垮。最后还想提一点组件库是需要养长期主义的它不是一次画完就束之高阁的模板而是每做一个新项目、每经历一次真实反馈都值得回过来补一补、改一改的活资产。我每次做完项目复盘都会把交互说明表里那些当时没想到的异常分支补到组件库里下次再做类似需求时组件库就比上一次更厚实一点。这大概也是Axure高保真Web开发常用组件这件事最让我觉得值得持续做下去的原因。
阅读完成 · 觉得有帮助？
