B端设计师警惕！Figma这4个进阶功能用错反而有害

B 端设计发展有个非常重要的节点，那就是 Figma 的问世，它的团队协作、自动布局等功能以及优秀的硬件性能管理大大释放了 B 端设计师的生产力，把 Sketch 甩在身后。

所以对于 B 端设计而言，只要没有网络要求的限制，那么就不存在 Sketch 和 Figma 只是工具选哪个都可以的说法，而是只能选 Figma（包括国产类 Figma 软件）。

Figma 虽然有很多优秀的功能和特性，但要用好它们也是要关注技巧和场景的。所以今天就要分享，Figma 最核心的几个功能如何在 B 端设计中正确运用。

往期教程：

解释的功能点包含下面这些内容：

1. 自动布局 Auto Layout
2. 约束响应式 Constraints
3. 组件和变体 Component
4. 色彩变量 Variable

一、自动布局功能

自动布局功能是 Figma 最重要的设计功能，但这个功能解释起来比复杂，它是建立图层之间的一种特殊的联系，并调节这种联系之间的参数，来实现图层自动缩放、位移、排版的功能。

自动布局在 B 端设计中非常的重要，其中最重要的应用场景就是表格，它可以帮助我们非常快的完成对整行数据项的设计，以及在完成设计后调整单元格，不管是新增、删除、缩放，都能很便捷的实现目标布局。而不用像 Sketch 调整一个单元格就要手动调整其它所有单元格，非常的费力。

除此之外还有表单和导航列表等场景，使用自动布局都可以极大地提高组件的设计效率，缩短项目的完成时间。

虽然自动布局很有用，但并不代表它是万能的或是必须的。自动布局也存在自己的缺陷，包括：

1. 自动布局和 Frame 编组相似，如果设置过背景填充，那么解组后背景填充就会消失，下级的排版也可能会混乱。
2. 自动布局只影响下级图层，所以为了满足布局需要下级图层需要进行严格的编组，而有些编组是多余的，会让图层结构层级变深，更难管理。
3. 使用自动布局设计好的复杂组件，如果要做设计调整是很困难的，而解组往往又会直接打乱图层。所以往往重画一遍会比修改的速度还快。

除此之外还有各种细节上的小问题就不做展开，我们要知道的是，不是所有组件都必须要添加自动布局，有的是本身结构就很简单添加自动布局是画蛇添足，有的是过于复杂添加自动布局只会抱薪救火，下面对它适用的场景做个总结。

自动布局的适用场景：

有相对简单且列表型展示的下级内容，比如界面的侧边导航栏罗列向下排列的菜单选项，单个表格行中包含水平排列的若干单元格，表单中排列相同格式的表单输入选项等。

不适合使用自动布局的场景：

组件内部包含的元素没有显著的重复性，且图层较多，元素排列的依据各不相同。主要集中在复杂的卡片类组件或数据看板等。

二、响应式约束功能

第二个功能是实现响应式适配的约束 Constraints，这个功能是 UI 设计工具最早推出用来实现“自动布局”效果的功能，是自动布局的前身。之所以还保留着，是因为它的实现逻辑和自动布局还有一定的差异。

自动布局需要多个图层进行编组才能实现，而约束功能是设置 Frame 下级元素对 Frame 的适配逻辑，必须要元素置入到 Frame 后才能设置。简单来说，它实现的效果就是我们变更画布的大小以后，那么下级元素会根据约束的设置进行排版或缩放。

可能很多同学会理解成这是响应式功能，要实现B端网页响应式的设计就要设置好它，这样才能实现完整的响应式布局效果进行交付。这里存在的问题主要有两点：

1. 响应式规则中最重要的“断点 Breakpoint” 只在 FigmaSite 中提供， FigmaDesign 里是没有且实现不了的。
2. B 端项目的复杂性决定简单的约束设置（即使加自动布局）也无法完全满足，而且使用它所投入的时间还不如创建多个尺寸的画布。

约束功能在目前使用的场景其实已经不太多了，所以我们再简单总结一下它适用的场景有哪些。

约束功能适用的场景

约束适合用在画布可能会进行拉伸的场景，比如有些页面高度超过一屏，我们要向下放大，那么有底部对齐的栏、元素，就可以使用约束的底对齐。如果有些页面要表现超出一屏宽的组件，那么右侧的悬浮框、抽屉等同理可以使用右对齐。

除此之外，还有一些特殊的组件在不同页面它们可能会有尺寸上的轻微变化，那么我们可以选择将它创建成 Frame 而不是自动布局，用约束来实现下级图层的排版。比如页面顶部的工具栏，会受到侧边栏展开关闭后的影响，就有两种尺寸，那么使用约束的做法会比自动布局更精简耐用。

约束功能不适用的场景

除了少数场景外，多数场景其实都不需要再使用约束功能了，尤其是想要体现页面响应式效果上，建议先真正了解响应式的逻辑和开发诉求后再考虑交付形式，而不是把它当成作为实现的途径看待。

约束还有个比较耐人寻味的特性，就是可以和页面栅格捆绑进行缩放，如果用的好确实可以在一些非常无法定稿的复杂组件中起到积极的作用，但这对设计师经验的要求过高，并不建议新手去关注。

三、组件和变体功能

创建 B 端设计规范中最复杂的东西自然就是整理组件库，而组件库的创建就要用到 Figma 的组件 Component 管理功能，以及它的附属功能变体  Variant。

组件功能的重要性不用赘述，想要提高项目设计效率以及视觉统一性，就肯定要大量使用组件来实现界面的组装。但这里要提个很重要的知识，那就是组件如果创建成以后，那么这个原始组件是无法解组的。如果想要移除组件状态，就要复制一个新的子组件解组，然后再删除原组件。

组件中我们主要关注的对象其实是变体，这个功能从理论上来说对 B 端组件创建非常有用，能将组件众多的效果全部聚合起来进行快捷变更。

但是，这个功能的实用价值非常弱，主要存在的问题有下面这些：

1. 部分组件的状态根本不会在界面展示中出现，也就是变体做了，但基本不会有启用的时候，比如按钮的悬浮 Hover 状态。
2. 变体属性过多，设置起来会非常复杂，组件数量会大幅度膨胀，很多组件状态没有做出来的必要，没做又会导致变体设置有 BUG。
3. 变体设置完后组件将更难以做调整，尤其是组件内还加了自动布局，改起来不如直接重做来的快。

所以变体的使用要非常注意场景和使用效果，不是为了加变体而加变体。以大厂框架的组件库为例，如果你们要去引用这些组件实现项目的设计，会发现根本做不下去。因为组件做的实在太复杂太混乱了，导致任何轻微的变动都难以实现。

组件变体的适用的场景

组件变体只适合应用在界面中需要经常触发不同状态、样式展示的组件中，比如需要展示选中状态的标签、要变更所在位置的导航栏、需要变更登录状态的顶部栏等。

组件变体的不适用的场景

一些包含了数十种变化的复杂组件，比如复杂的信息卡、表格的数据行、复杂表单型组件等。它们的样式和状态要通过其它组件说明文档展示，而不是做进变体中。

四、色彩变量功能

变量 Variable 是相对比较靠后才出的功能，包含了色彩、数字、文本、布尔四个功能点。数字、文本、布尔就不多说了，属于完全不建议使用也很难会涉及到的部分，我们能接触和使用的基本只有色彩变量。

色彩变量 Variable Color 从使用体感上和样式中的色彩 Style Color 是高度重叠的，所以记录色彩样式时会很容易创建错误。

色彩变量在网上曝光最多的场景，就是对做深色和浅色模式的切换……这其实是个非常荒谬的需求，即辛辛苦苦定制了两套颜色，然后为了在演示环境下点击切换色彩模式。

这个付出和回报是不成正比的，因为如果新做一套颜色，那么在设计稿交付中肯定要看到最终的色彩效果，如果第二套颜色做在变量里，就只能在演示环境下还有手动操作才能显示出来。而且，真实项目下的模式切换，肯定还有一些图片的变更，光靠色彩变量控制是肯定不够的。

还有个常见的问题，就是变量结合 DesignToken 的命名，这个只要能搞明白 DesignToken 是什么，用不用变量其实不重要。

变量的使用鸡肋大于实用性，尤其对整体样式的管理上，其它字体、效果、描边等都用 Style 而色彩填充用 Variable，会导致样式库维护的混乱。

色彩变量上，我没有建议的使用场景，直接忽略不用这个功能才是最好的做法……

结尾

Figma 众多功能的开发都有面向的应用场景，作为设计师我们要先理解自己工作要实现的结果，再考虑如何结合功能去实现，而不是把完成工作目标等同于对软件功能的使用，这样它们就无法变成优势，只能变成拖累。

对于新手而言，搞不清楚软件一些复杂功能的优缺点很正常，我们要遵循的最简单的原则就是 —— 如无必要勿增实体。也就是你想不出来为什么要用这个功能，它能带来哪些收益，那你就别用即可，不会对项目产生什么实质上的影响。

我们下篇再贱~

欢迎关注作者的微信公众号：「超人的电话亭」