★ FEATURED ARTICLE 1. 为什么“从白稿开始”是改版效率的最大陷阱做过中后台系统改版的人大概都有这种经历产品经理丢过来一句“这个页面太旧了重新设计一版”然后设计师打开 Figma新建一个 1440 宽的 Frame从零开始摆导航、摆表格、摆按钮。三天后交稿开发一看说“这个布局跟我们现在的组件库对不上”于是又改两天。最后上线时发现真正被用户感知到的变化可能只有配色和圆角。问题出在哪出在起点选错了。“白稿”指的是完全空白的画布没有任何现有界面的约束。从白稿开始做改版本质上是在做一次“重新发明”而不是“重新设计”。重新发明的问题在于你会不自觉地按照理想状态去画而不是按照系统实际运行的状态去画。理想状态下的表格列宽是均匀的实际运行中某一列因为数据太长被撑开了理想状态下的弹窗是居中的实际运行中因为父容器 overflow 设置不对弹窗被裁掉了一半。这些差异白稿里全都看不见。所以我的做法是反过来的改版的第一步不是打开 Figma而是把当前正在运行的界面“带回去”。带回去的方式有很多种截图是最基础的但截图是静态的、扁平的丢失了层级关系和交互状态。更好的方式是用工具把运行界面的 DOM 结构、样式、甚至组件树抓下来转成 Figma 可以识别的图层。这就是标题里说的“先把运行界面带回去”的真正含义。它不是让你把截图贴进 Figma 当参考图而是让运行界面成为设计稿的基底。你在真实结构上做修改而不是在空白画布上做想象。这个思路的转变带来的效率差异是数量级的。我做过一个对比同一个列表页改版从白稿开始平均需要 2.5 天出第一版可评审稿从运行界面导入开始只需要 0.5 天。省下来的时间不是偷懒省出来的是因为你不需要再画一遍已经存在的东西。注意这里说的“带回去”不是让你照抄现有界面。现有界面是起点不是终点。你要做的是在真实结构上做减法、做重组、做视觉升级而不是从零搭建一个看起来很像但结构完全不同的东西。2. 把运行界面搬进 Figma 的三种路径与选型逻辑“把运行界面带回去”这句话说起来简单但具体怎么带有不同的技术路径。我实际用过的主要有三种各有各的适用场景和坑。2.1 截图 手动描摹最笨但最可控这是最原始的方式截一张运行界面的图拖进 Figma降低透明度然后在上面手动描图层。听起来很蠢但它在某些场景下反而是最优解。什么时候用当运行界面的结构极其复杂但你需要改动的部分很局部的时候。比如一个数据看板上面有十几个图表组件你只想改顶部的筛选栏。这时候用工具把整个页面导入 Figma反而会带来大量无用的图层拖慢文件性能。截图描摹只针对你要改的区域干净利落。手动描摹的关键技巧是不要描得太细。你是在做设计稿不是在复刻像素。把主要的容器边界、间距关系、层级关系描出来就够了。文字内容可以直接用截图上的不需要重新打字。这种方式的问题也很明显不可复用。下次改另一个页面你得重新描一遍。所以它只适合一次性、局部性的改版任务。2.2 浏览器插件导出速度最快但结构会失真市面上有一些浏览器插件可以把当前页面的 DOM 结构导出成 Figma 文件。原理大概是遍历 DOM 节点读取计算样式然后生成对应的 Figma 图层。我用过几个导出速度确实快点一下按钮几秒钟就能在 Figma 里看到页面结构。但问题在于“结构会失真”。DOM 是嵌套的Figma 的图层也是嵌套的理论上可以一一对应。但实际上CSS 的布局模型flex、grid、absolute和 Figma 的自动布局Auto Layout并不是完美映射的。一个用 flex 实现的水平排列导出后可能变成一堆绝对定位的图层你一动就全乱了。还有一个更隐蔽的问题伪元素和背景图。很多界面的装饰性元素是用::before、::after或者background-image实现的这些在 DOM 遍历中往往会被忽略或者处理不当。导出后的 Figma 文件看起来“少了点什么”但你一时半会儿说不清楚少了什么。所以这类工具适合什么场景适合结构简单、以文本和基础容器为主的页面。比如一个设置表单页全是 label input 的垂直排列导出效果就很好。但如果是复杂的仪表盘或者带有大量自定义绘制的页面导出结果基本没法直接用。2.3 设计系统反向映射最理想但前提是你有设计系统这是最理想的方式如果你的项目已经有一套完整的设计系统组件库 设计令牌那么运行界面上的每一个元素都可以反向映射到设计系统里的组件。你不需要导出图层你只需要知道“这个页面用了哪些组件、哪些变体、哪些令牌”然后在 Figma 里用对应的组件重新拼装一遍。这种方式的好处是产出的设计稿天然与代码实现对齐。开发看到设计稿直接就能对应到组件库里的组件不需要再做“翻译”。而且因为用的是组件实例改起来也快改一个主组件所有实例同步更新。但它的前提条件很苛刻你得有设计系统而且设计系统和代码实现得是同步的。很多团队号称有设计系统但实际上 Figma 里的组件库和代码里的组件库是两套东西各走各的。这种情况下反向映射就无从谈起。我的建议是如果你所在团队有维护良好的设计系统优先用这种方式。如果没有先用第二种方式快速导入然后在 Figma 里手动把关键组件替换成设计系统里的组件。这个过程虽然麻烦但一次投入后续所有页面改版都能受益。路径适用场景速度结构保真度可复用性截图描摹局部改版、复杂页面慢高人工控制低插件导出简单页面、快速原型快中低中设计系统映射有成熟设计系统的团队中高高3. 运行界面导入后的图层清理与结构重建不管你用哪种方式把运行界面带进 Figma导入后的第一件事都不是开始设计而是清理图层。这一步很多人会跳过觉得“反正能看就行”但后面会吃大亏。3.1 为什么导入后的图层必须清理插件导出的图层结构反映的是 DOM 的嵌套关系而不是设计的逻辑关系。DOM 里为了布局方便会加很多无意义的包裹层。比如一个按钮DOM 结构可能是div div button span导出到 Figma 就变成四个嵌套的 Frame但实际上你在设计时只需要一个按钮组件。这些多余的嵌套层会带来三个问题第一文件体积膨胀打开和操作变卡第二自动布局难以应用因为层级太深第三开发看设计稿时会被误导以为需要那么多层嵌套。清理的原则很简单合并视觉上无差别的图层删除纯布局用的空容器把语义相关的元素归组。具体操作上我会按这个顺序走先看最外层把页面级的容器保留删除多余的 wrapper。再看每个区块把区块内的元素按功能分组比如“搜索区”“表格区”“分页区”。最后看单个组件把组件的内部结构简化到最小必要层级。这个过程大概会花掉 10 到 15 分钟但后续所有操作都会因此顺畅很多。3.2 用命名规范把“运行结构”翻译成“设计结构”清理完图层之后下一步是重命名。导入的图层名字通常是Frame 123、Group 456这种完全不可读。你需要把它们改成有语义的名字。命名规范我建议直接用设计系统里的组件名。比如Button/Primary/Default、Input/Text/Default、Table/Header/Cell。这样做的好处是当开发拿到设计稿时看到图层名就知道对应哪个组件减少沟通成本。如果团队没有设计系统命名规范那就用最直白的业务命名搜索栏、数据表格、操作按钮组。关键是一致同一个东西在所有页面里叫同一个名字。提示Figma 的“重命名图层”功能支持批量操作。选中多个图层按CmdRMac或CtrlRWindows可以用正则表达式批量替换名字。比如把所有Frame前缀去掉或者把Group统一改成Section。3.3 把静态图层转成自动布局的时机判断自动布局是 Figma 里最核心的功能之一但并不是所有图层都适合立刻转成自动布局。我的经验是先清理和命名再考虑自动布局。因为自动布局会改变图层的父子关系和排列方式如果在图层还很乱的时候强行转只会更乱。判断一个区块是否适合转自动布局看两个条件第一这个区块内的元素是否有明确的排列方向水平或垂直第二这个区块是否需要响应式伸缩。如果两个条件都满足那就转。如果只是固定尺寸的装饰性元素保持绝对定位反而更简单。转自动布局的时候注意间距的设置。导入的图层间距往往是靠 margin 或 padding 实现的转成自动布局后要用 Auto Layout 的 gap 和 padding 来还原。这里有个小技巧先用截图量一下实际间距然后在 Figma 里设置对应的数值。不要凭感觉设凭感觉设出来的间距开发实现时会对不上。4. 在真实结构上做改版的实操节奏把运行界面带回来、清理好、命名好之后才真正进入“改版”环节。这时候你的画布上是一个结构清晰、命名规范、与线上实现对齐的基底。在这个基底上做修改和从白稿开始做修改体验完全不同。4.1 先做减法删掉不需要的元素改版最容易犯的错误是“只加不减”。看到旧界面觉得这个也要保留那个也要保留最后改出来的东西比原来还臃肿。正确的做法是先做减法。具体怎么减我会问三个问题这个元素用户真的需要吗这个元素的信息能否合并到其他地方这个元素删掉后用户完成任务会不会受阻如果三个问题的答案分别是“不确定”“能”“不会”那就删。比如一个后台列表页顶部有六个筛选条件。实际上根据数据80% 的用户只用其中两个。那改版时就可以把另外四个收进“高级筛选”里默认只展示两个。这就是减法。减法的好处是页面变清爽了剩下的元素有更多呼吸空间视觉升级也更容易做出效果。而且删元素比加元素的风险低因为删掉的东西如果用户真的需要反馈会很快上来加回去也容易。4.2 再做重组调整信息层级和操作路径减法做完之后剩下的元素需要重新组织。重组的目标是让信息层级更清晰操作路径更短。信息层级方面我会用“三秒测试”把设计稿给一个没用过这个系统的人看三秒然后问他“这个页面是干什么的”“最重要的信息是什么”“下一步该点哪里”。如果答不上来说明层级有问题。操作路径方面核心原则是“高频操作前置低频操作后置”。比如一个订单管理页面最常用的操作是“查看详情”和“发货”那这两个按钮就应该放在列表项最显眼的位置而不是藏在“更多”菜单里。重组的时候可以借助 Figma 的“内容比例”功能来测试不同屏幕宽度下的表现。把 Frame 拉宽拉窄看布局是否还能保持合理。这一步能提前发现很多响应式问题避免开发阶段再返工。4.3 最后做视觉配色、间距、圆角的统一升级视觉升级是改版里最直观的部分但也是最容易做过头的地方。我的建议是视觉改动要有节制一次只改一个维度。比如这次改版只调间距体系把所有间距统一到 4 的倍数4、8、12、16、24、32。下次改版只调圆角把按钮、卡片、输入框的圆角统一到一套值。再下次调配色把主色、辅助色、语义色重新定义。为什么不要一次全改因为一次全改你无法判断哪个改动带来了正面效果哪个改动带来了负面反馈。而且全改的工作量巨大评审时也很难聚焦。如果非要一次全改那就用设计令牌Design Token来管理。在 Figma 里用 Variables 定义好颜色、间距、圆角的令牌然后批量应用到所有图层。这样改一个令牌值所有引用它的地方同步更新。这是目前效率最高的视觉升级方式。5. 从 Figma 到代码让改版稿真正可落地设计稿做得再漂亮如果开发实现不出来或者实现出来走样那改版就是失败的。所以从 Figma 到代码的衔接必须在设计阶段就考虑进去。5.1 标注不是万能药结构对齐才是关键很多设计师习惯在交付时写一大堆标注这里间距 16px那里字号 14px这个按钮圆角 8px。但开发真正需要的不是这些数值而是结构对应关系。什么意思开发看到设计稿第一反应是“这个页面由哪些组件组成”。如果设计稿里的组件和代码里的组件能一一对应开发实现起来就很快。如果设计稿里是一个自定义的复杂布局代码里没有对应的组件开发就得从头写这时候标注再详细也没用。所以我在做改版稿的时候会尽量使用设计系统里的组件实例。如果某个地方必须自定义我会在设计稿里明确标注“此区域为自定义布局建议实现方式为……”。这个建议不是命令而是给开发一个参考减少他们的决策成本。5.2 用 Figma 的 Dev Mode 减少沟通损耗Figma 的 Dev Mode 是近几年对开发最友好的功能之一。它可以把设计稿里的图层直接映射到代码片段显示间距、颜色、字体等属性的具体值还支持导出资源。但 Dev Mode 的效果取决于设计稿的规范程度。如果图层命名混乱、结构嵌套过深、用了大量自定义样式Dev Mode 给出的代码片段也是混乱的。反过来如果设计稿结构清晰、命名规范、使用了设计令牌Dev Mode 就能给出接近可直接使用的代码。我实测下来的经验是在设计阶段就把 Dev Mode 的预览打开一边设计一边看它给出的代码提示。如果发现某个地方的代码提示很离谱说明设计稿的结构有问题当场调整。这样交付时开发拿到的就是一份“代码友好”的设计稿。5.3 改版上线后的验证用真实数据反哺下一轮设计改版上线不是终点。上线后一周我会做一次数据验证对比改版前后的关键指标比如任务完成率、平均操作时长、错误率、用户反馈。这些数据会直接反哺下一轮设计。比如发现某个按钮的点击率远低于预期可能是位置不对或者文案不清晰发现某个页面的跳出率很高可能是信息层级有问题。更重要的是这些数据会告诉你“哪些改动是有效的”。有效的改动可以沉淀到设计系统里成为后续改版的默认选项。无效的改动则记录下来避免下次再犯。这个闭环一旦建立起来改版就不再是“拍脑袋想出来的”而是“有数据支撑的迭代”。从运行界面带回来在真实结构上改用真实数据验证这才是一个完整的改版循环。6. 几个容易踩的坑和我的处理方式最后分享几个我在实际项目中踩过的坑以及后来怎么处理的。第一个坑导入的图层太多Figma 文件卡到无法操作。处理方式是分批次导入不要一次性把整个页面导进来。先导你要改的区域改完再导下一块。另外导入后立刻把不需要的图层删掉不要留着“以后可能用得上”。Figma 文件超过 5000 个图层就会明显变卡控制图层数量是保持流畅的关键。第二个坑设计稿和线上实现不一致开发说“这个效果实现不了”。处理方式是在设计阶段就用真实数据填充。Figma 支持通过插件填充真实数据比如用真实的用户名、订单号、金额来替换占位符。这样你能提前看到极端情况下的表现比如超长文本会不会撑破布局大数字会不会换行。提前发现提前调整。第三个坑改版后用户不买账说“还是旧版好用”。处理方式是保留旧版入口给用户一个过渡期。同时在改版上线时用引导提示告诉用户“哪些地方变了为什么变”。用户抵触往往不是因为新版不好而是因为不习惯。给一点适应时间配合清晰的引导抵触会小很多。第四个坑设计系统组件和实际需求不匹配强行用组件导致设计受限。处理方式是允许“合理的例外”。设计系统是工具不是枷锁。如果某个场景确实需要自定义组件那就自定义但要在设计稿里标注清楚并考虑是否值得把这个自定义组件沉淀到设计系统里。设计系统本身也需要迭代。这些坑的共同点是它们都不是技术问题而是流程和协作问题。把运行界面带回来本质上也是在解决流程问题——让设计从真实出发而不是从想象出发。这个思路一旦建立起来改版的效率和质量都会有明显的提升。
阅读完成 · 觉得有帮助？
