越高的密度越能提高效率。常用的界面通过使用多种交互方式让界面可以显示更多的内容，而无需滚动页面。另一方，具有深度营销信息的冗长网页，以低密度主导号召性（ call-to-action）内容。很明显，以上两种情况是一个完全不对等的比较。但是，在相同的产品、页面甚至组件中，密度一样会有所不同。

但是，密度越高，就越有可能隐藏关键细节，增加交互难度，甚至会让用户对太多需要处理的信息不知所措。因此，密度需要进行权衡和判断。

随着企业跨团队扩展使用设计系统，摩擦在所难免。这种对立的根源往往可以追溯到密度上：字体过大、空间过大、元素过大。设计数据驱动的分析应用程序的团队对使用以营销内容为主的组件会感到恼火。当组件不合适时，他们想要退出系统，甚至不想从系统开始。

本文先介绍了如何使用组件大小和高度来考虑密度。然后将分步讲解如何跨组件统一尺寸。最后，通过实例来讲述如何为系统添加尺寸。

使用统一高度的大小实现密度

界面密度是由一系列的字体排版和空间选择（例如padding, margin, column, gutter等）组成的，适用于从外部布局容器到原始元素（包括设计系统提供的组件）的所有内容。

UI组件本身可以控制其边界内的内容，除非它还添加了margin 属性避免与相邻元素发生冲突。有许多属性会起作用，包括font-size, font-weight, line-height, padding 以及（如果有的话）border。 这些属性融合在一起，影响密度，并最终影响到元素尺寸。

Padding 和 Typography 会影响尺寸大小

别弄错：密度 ≠ 大小。但是大小会影响密度，而不同的密度又和调整大小有关。如上图所示，增大或减小font-size 和 padding，按钮将分别变大或变小。

但是，许多组件库中的组件大小并不一致。有小号的字段输入，也有小号和大号的按钮，甚至还有超大号按钮以及看上去相当浮肿的按钮。通过观察，小号输入字段和小号按钮也不尽相同。

不一致的组件高度

为了系统化地针对不同密度进行统一高效的制作，创作者需要在整个设计系统中执行一致的组件大小模型。宽度通常取决于上下文和内容。而一致的高度是实现水平和垂直布局组件时的预期目标。

为此，我们开始逐步采用统一的组件尺寸，包括从内到外的字体排版、空间和高度。

分步设置组件大小

让设计系统中的组件获得一致的尺寸大小需要分几个步骤：建立比例、定义原子组件、确定目标高度以及调整每个组件的属性以实现该高度。

1. 定义所需尺寸的大小

对于一些团队来说，一个尺寸就足够了。但是如果我们需要很多尺寸呢？

image

一种常见的用法是使用Default 和 **High **。前者为大多数采用者提供了明智的初始值。后者为设计密度更高的界面提供适合其客户需求的压缩。

但是两种选择可能还不够。在更多的情况下，我们会看到 Small，Medium（默认）和 Large 三个变量，如下：

image

• Small：高密度显示，用于频繁使用的界面，可集成大量数据并支持多种任务。
• Medium：许多主题的默认设置，长期阅读体验，适用于各种消费者、企业、内部应用程序和内容。
• Large：内容丰富的营销网站、促销以及用于载入、设置和其他简单流程的一次性数据输入。

人们可能会沿着XS，XL，XXL这样的规律创建更多的停止点。甚至可能从基线16开始，然后调高至19.4或调低至14.263975。但是，你有没有想过，这么多的停止点真的就和谐、一致，并且易于维护吗？

小提示：组件库可能需要两个或（最多）三个尺寸大小。避免过多的复杂性，以便所提供的选择可以平衡整个设计系统的灵活性和连续性。

2. 定义需要实现所有尺寸统一高度的组件

跨组件设计尺寸要从一组原子元素开始。并非每个组件都需要实现所有尺寸（稍后会详细介绍），而且许多组件根本没有尺寸。比如pagination、footnote 或 truncate。

高度统一的通用组件

小提示：从一开始就应避免诱惑让所有组件实现所有尺寸。取而代之的是，从核心组件开始，建立密度基准，然后从再从基准开始进行设计。

3. 从 Button 或 Input 开始

一旦确定了组件并开始工作，就会在组件大小之间形成约定。可以从input 或button开始。

不同尺寸的Button

由于按钮尺寸比较固定，其他元素会随之变化，包括search field, select, combo box, list group的条目以及表格的cell 。

4. 统一字体排版

字体排版从font-size开始，字体大小的变化会触发font-weight, line-height以及其它属性的变化。接着模型会出现并嵌入到不同的组件中，这些组件会根据size属性的变化而改变样式。

Button 和 Input 中针对字体设置的 mixin

5. 统一空白区域

类似地，空间模型可以控制如何在组件中插入元素。Small、Medium 和 Large 三种尺寸的组件通常通过 Design Tokens 进行比例上的控制。

使用 space tokens 的 Button 和 Input

在某些情况，增大尺寸还会导致其它一些变化，比如加重 border，改变border-radius或改变图标重量。

按尺寸大小划分的组件

小提示：在跨组件中规格化尺寸可以使用 mixin 和 design tokens 工具。在这些工具中设定规则，并在下一步中对组件进行微调。

6. 按需对每个组件进行模型的扩展和覆盖

要统一高度，可以指定 height，然后覆盖所包含元素的字体和空间。另一种做法是，组件高度根据精心建模的字体和空间属性以及其他内容（尤其是图像）组成的混合布局进行自动调整。建议选择后者。因为这种方法会覆盖每个组件以达到一致的高度。

覆盖默认间距模型以考虑边界和相邻元素

特定于组件的扩展和覆盖包括：

• 由于按钮标签或列表项的左侧或右侧存在图标，因此可以调整嵌入元素的padding-left或padding-right 。
• 将外部数据表格单元的padding-left和padding-right设置为0。
• 为表单控件添加border或为列表项添加border-top，以减少或扩展嵌入元素的padding-top和/或padding-bottom。

小提示：对齐大小需要在各个组件之间共享约定，而且还需要对每个组件进行微调。先共享规则，再单独设定，贯穿整个设计系统。

案例分析

案例1：逐个组件实施导致不一致

逐步构建组件的团队通常会边制作组件边调整属性。许多团队缺乏调整大小的全局策略，遇到组件需要调整的时候便随手去进行调整，而后又会意识到这些尺寸名称和视觉属性根本不统一。下面介绍了三种常见的错误。

名称相同的两个组件（Medium 和 Medium）却具有不同的字体排版和间距值，因此大小也完全不同。

相同的尺寸名称，不同的大小

名称不同的两个组件（Medium 和 Small）却具有相同的字体排版和间距值，因此大小也完全一样。

相同视觉尺寸的组件拥有不同的尺寸名称

应该以相同的尺寸提供两个组件，但只有一个尺寸可用。

组件可用性不可预测或不完整

小提示：通过建立概念，构建工具（例如 mixin 和 tokens ）及预期使用的工具来预见并减少错误的发生。

案例2：一次即可整体统一尺寸

许多设计系统团队会在创建设计系统一年后发现自己已经建立的库缺少一致的大小调整模型。这不是什么大惊喜，他们见证了时间的流逝！

Morningstar 在进行设计系统改造时，优先考虑对所有组件进行尺寸统一。团队先进行了审计工作，确定了每个尺寸级别的目标组件高度，然后由团队的高级设计师逐一过目。

小提示：如果设计系统缺乏尺寸的连续性，则需将遍历整个目录视为目标，该目标的时长应大于Epic/季度/半年度。全面应对挑战，并将其视为重大更新或换代更新，以便采用者同样能够应对视觉突破性的变化。

案例3：并非每个组件都需要每种尺寸

某些UI组件的模式化使用与某些停止点在大小调整上的意图背道而驰。警示、通知和其他提示必须能引起你的注意，要么通过模式化组件控制屏幕，要么以醒目的方式呈现，以免错过。而小尺寸会与该任务背道而驰。

Medium 和 Large 尺寸的警告，Small 尺寸没有必要。

另一方面，表示属性值的标签组件在紧凑的视觉效果下会更好表现。无论以何种方式显示，它都能在小尺寸或中型尺寸下工作良好。提供大尺寸就没有意义。

Small 尺寸 和 Medium 尺寸的 Tag 组件，Large尺寸没必要。

尽管库可能会发生变化，但设计系统通常会按照如下所示提供组件大小：

• Small, Medium, 和 Large：Button, Button Group, Card, Checkbox, Combo Box, Data Table, Error Text, Label, List Group, Loaders, Microcopy, Radio Button, Required Field, Search Field, Select, Stepper, Switch, Text Box, Text Area, Tooltip
• Small, Medium： Alert, Notification, Tag, Top Hat
• 仅调整宽度： Dialog, Modal, Popover
• 替代尺寸模型： Headings (Levels 1+)
• 仅默认尺寸： Layout Grid, Link, Module Container, Masthead, Navigation Container, Page Shell, Pagination (Insufficient Demand), Range Slider (Insufficient Demand), Site Navigation

小提示：组件的用途可能与全局既定的大小设置背道而驰。在这种情况下，请避免不必要的尺寸，并提供适合组件目的的尺寸。

案例4：避免对宽度等一维选项使用尺寸模型

尽管大多数尺寸模型着重于高度，但宽度也可以随一组离散选项的不同而变化。例如，可以建议使用三个离散宽度的模式窗口：400px，600px或800px。

提供三种不同宽度的模式窗口

另一方面，对话框可能会提供300px和500px的变体，弹出框可以提供200px和300px的变体。

弹出窗口有两个不同的宽度

在这种情况下，你可能很想将 S / M / L 名称分别应用于模式窗口、对话框和弹出窗口的变体上。但是，至少对话框和弹出窗口也可能具有与上述类似的应用于字体排版和间距规则的变体。类似地，模式窗口之类的组件可能会添加1000px作为另一个变体。如果继续使用 S / M / L 为这些组件的变体进行命名，就会发生混乱。

避免将T恤尺寸模型（S / M / L）应用于例如宽度这样的单个数值上，因为这种命名方式对附加物没有弹性，并且组件的尺寸可能已经使用了T恤尺寸模型。相反，请考虑基于值来命名选项，例如modal-width-500和modal-width-700。

案例5：字体排版的层级结构 ≠ 尺寸，需要根据组建大小进行关联

标题，它们的比例以及它们在页面上创建的层次结构是具有挑战性的。当组件大小作为尺寸交汇到标题级别时，会让人非常恼火。怎么会这样？

设计系统通常提供多达 9 个级别的标题。由于字体排版贯穿于整个设计系统，这些标题将被应用于所有组件，包括Accordions, Tiles 以及 Alerts。由于每个组件都随大小而变化，因此团队发现标题级别也会随大小而变化。为此，系统可以采取以下两种方法之一。

如下图所示，一个系统可以提供较长的Heading尺寸列表（例如1-5），并在每个尺寸的组件之间统一应用级别：

一组标题应用于各个组件尺寸

或者，系统可以提供一组更有限的标题级别，并为每个大小级别指定font-size和其他属性，如下图所示：

针对每个组件大小设置标题级别

小提示：在组件集合实现大小调整时，不仅标准化标题样式在组件之间的应用方式至关重要，而且该模型如何根据提供的每个大小来调整元素的标题级别也至关重要。

案例6：合成组件期间混合和匹配大小

你拥有Small、Medium 和 Large 三种尺寸的元素。很自然，当你组合更复杂的组件时，它们将仅包含相同大小比例的组件，对吗？

当涉及合成时，这并非既定的，你可能会在第一个组件构成中找到合理性，比如将icon合成到button中。 Morningstar设计系统团队建议中小尺寸按钮应用小尺寸图标，而大尺寸按钮应用中尺寸图标。

将图标大小映射到按钮大小

令人惊讶的是，扁平按钮在某些情况下与小图标配合使用效果好，而在另外一些情况下与中号图标配合使用效果更好。因此，该系统提供了一个mds-button-flat-icon-m修饰符，使采用团队能够选择性使用。

尽管小号按钮和大号按钮都有固定的图标，但是中号按钮使用效果更好

以上说明什么问题呢？ 即使在大多数情况下，类似按钮大小和图标的混合和匹配也是有效的。因此，请为在任何 UI 组合级别上进行混合和匹配的合理情况做好准备，以便使用多个组件进行整页布局。团队会将各种情况汇聚到一起进行对比，以解决问题并优化体验。

总结

设计系统通过引导使用和提供工具在密度方面发挥作用。一致的尺寸是起点。升级字体排版和空间模型，并开始根据高度和更多尺寸统一目录。

---

英文原文：https://medium.com/eightshapes-llc/size-in-design-systems-64f234aec519
原文作者：Nathan Curtis
编译作者：@设计吐司

以上译文仅代表原作者观点。如需转载请遵循CC版权协议正确标明出处。