typographyApril 27, 202616 min read

模块化字体比例:如何构建一致的字体系统

逐步构建模块化类型比例尺,并将其转化为设计令牌、Figma 变量和 Tailwind CSS。包含实际比例、实际实现,以及确保比例尺在团队开始发布后不会崩溃的规则。

By Boone
XLinkedIn
modular type scale guide

模块化字体缩放是指将一个比例应用于一个基础字号,从而生成产品中的所有字体大小。这就是它的精髓所在。你选择比例,锁定基础字号,生成缩放步长,将它们作为令牌发布,并在所有地方使用这些令牌,而不是使用一次性的像素值。如果做得好,产品中的每个字号都会与其他字号相互关联,因为它们在数学上确实如此。

如果做得不好,最终你会得到十七种无人能辩解的字体大小,标题与正文争夺层级,以及每季度一次的重新设计会议,会上总有人提议“我们干脆把字号标准化吧”,但没人知道应该标准化到什么程度。缩放本身就是你需要标准化的对象。本文将介绍如何构建一个适用于实际产品的缩放系统,它拥有真实的比例、真实的令牌结构,以及使之可执行的 Figma 和 Tailwind 转换功能。

什么是模块化字体比例尺

模块化字体比例尺是指将一个基本尺寸与一个比例尺结合,生成产品中所有字体大小,而这个比例尺正是其核心所在。

选择一个基本尺寸,例如 16 像素,以及一个比例尺,例如 1.25。将 16 乘以 1.25 得到 20。将 20 乘以 1.25 得到 25。以此类推,得到 31、39、49、61。将 16 除以 1.25 得到 12.8。再将 12.8 除以 1.25 得到 10.24。这就是比例尺。八种尺寸,一个基本尺寸,一个比例尺,完全符合数学规律。

这种方法之所以有效,是基于心理物理学原理。人类的视觉感知对比例而非绝对差异更为敏感。从 12 跳到 14 与从 24 跳到 28 的感觉大致相同,因为两者都是大致相同的乘法步长。线性刻度(12、14、16、18、20、22)顶部感觉拥挤,底部感觉空旷。模数刻度感觉均匀,因为相对而言,它的确如此。

同样的逻辑也适用于音乐音程(八度是 2 倍,五度是 1.5 倍,四度是 1.333 倍)、摄影光圈以及大多数建筑比例理论。字体设计只是借用了这一原理。本文中提到的各种比例(小二度、纯四度、黄金分割)之所以源自音乐,是因为它们描述的是同一种感知关系。

涵盖实际产品的五种比例

大多数产品的数值范围在 1.125 到 1.618 之间,每种比例都代表着特定的密度信号。

几乎涵盖所有实际界面的五种比例:

| 比例 | 名称 | 密度信号 | 实际应用 |

|------:|------|----------------|---------------------|

| 1.125 | 小二度 | 紧凑、密集、数据密集 | Vercel、Geist、大多数管理后台 |

| 1.2 | 小三度 | 紧凑、平衡 | Tailwind 默认比例 |

| 1.25 | 大三度 | 标准编辑风格 | Stripe、Material 3 主体角色 |

| 1.333 | 纯四度 | 宽广、杂志风格 | 编辑网站、长篇博客 |

| 1.618 | 黄金比例 | 戏剧性、以展示为主 | 营销页面、英雄式网站 |

有时还会出现另外两种比例。 1.414(增四度,即2的平方根,也是A4纸的比例)介于纯四度和纯五度之间,对于想要比1.333更具视觉冲击力的杂志风格产品来说,是一个合理的选择。1.5(纯五度)比1.333更醒目,比1.618更柔和,是许多营销页面生成器的默认比例。

您可以使用超出此范围的比例,但通常不建议这样做。低于1.1时,各级尺寸之间的差异非常小,以至于您无法一眼区分标题3和标题4。高于1.7时,尺寸增长过快,导致可用的中间尺寸不足。如果设计师想要比1.618更宽的比例范围,通常是因为他们解决了错误的问题,他们需要的是两个比例,而不是一个更大的比例。

体素图显示了水平排列的五个小型巨石,从左到右高度逐渐增加,底部刻有比例 1.125、1.25、1.333、1.414 和 1.618。
体素图显示了水平排列的五个小型巨石,从左到右高度逐渐增加,底部刻有比例 1.125、1.25、1.333、1.414 和 1.618。

选择合适的比例

数据密集型应用需要紧凑的宽高比,编辑网站则需要宽广的宽高比,而错误的宽高比会在后续所有环节都造成影响。

如果产品是仪表盘、管理面板、CRM、分析工具,或者任何用户需要长时间阅读大量信息的界面,则默认设置为 1.125 或 1.2。紧凑的宽高比意味着标题大小不会分散用户对数据的注意力。层级结构依然有效,因为在这个尺度下,层级主要取决于标题的粗细、颜色和间距,而不是大小。

如果产品是 SaaS 营销页面、内容网站、产品页面或文档页面,则默认设置为 1.25 或 1.333。中间的宽高比既能赋予标题足够的视觉冲击力,使各个部分区分开来,又不会让正文显得过小。大多数 B2B 产品都属于此类,Tailwind、Material 和 Stripe 等工具也都采用了这种宽高比。

如果产品是编辑类、杂志风格或以展示为主的页面,例如长篇出版物、时尚网站或活动微网站,则默认使用 1.414 或 1.618 的宽高比。宽高比意味着标题看起来更像标题,足以占据整个主标题区域。正文内容可以保持合理,因为主标题和正文之间的留白已经起到了作用。

错误在于仅仅因为某个比例听起来很厉害(黄金比例就是一个著名的例子)就选择它,然后强行应用到不需要这种效果的产品上。在 CRM 系统中使用 1.618 的宽高比会显得难以阅读。在编辑类网站上使用 1.125 的宽高比则会显得内容单薄。选择产品真正需要的宽高比,然后坚持使用。

缩放前锁定基础字体大小

基础字体大小是所有缩放步骤的基准,如果基础字体大小错误,则所有步骤都会出错。

网页上正文的默认字体大小为 16 像素。浏览器默认字体大小为 16,用户代理样式表字体大小为 16,成人首选阅读字体大小中位数为 16,WCAG 和 Apple 人机界面指南均将 16 作为正文字体大小的最低标准。如果目标受众年龄偏大或产品阅读量较大,您可以将字体大小提高到 17 或 18,但正文字体大小绝不能低于 16。

这个基准值是倍增点。高于基准值的每一步都是基准值乘以比例的幂次方。低于基准值的每一步都是基准值除以比例的幂次方。如果您更改基准值,则每一步都会相应调整。这很正常,这是系统运行的正常现象。但这意味著更改基准值是结构性更改,而不是针对单个屏幕的微调,并且应该在正式发布之前一次性完成。

对于移动设备,您可以缩小基准值(15 或 16),并使用相对单位。对于印刷品,基准字号通常为 11 或 12 磅,比例保持不变。对于包含代码块的文档,将正文字号设置为 16 磅,代码等宽字体设置为 14 磅,代码缩放比例也相同。基准字号针对每种媒介,比例针对每个产品,两者都只需设置一次。

还有一条规则:在网页上,基准字号应以 rem 为单位,而不是 px。整个缩放比例应以 rem 为单位,以便用户字体大小偏好和辅助功能工具(缩放、阅读模式、浏览器缩放)能够正确生效。Tailwind 和 Material 都已采用这种设计。Apple 的 iOS 动态类型也采用了类似的设计。如果您的缩放比例以像素为单位硬编码,则与平台不兼容。

生成缩放步骤,并按角色命名

七到九个缩放步骤可以涵盖产品所需的所有尺寸,请按角色而非尺寸命名。

例如,基准字号为 16 像素,比例为 1.25。步骤如下:

  • 10(超小标题,脚注)

  • 13(小标题,辅助文本)

  • 16(正文,基础标题)

  • 20(导语,大标题)

  • 25(h4,小标题)

  • 31(h3,中标题)

  • 39(h2,大标题)

  • 49(h1,页面标题)

  • 61(展示标题,主标题)

九个步骤。这就是整个产品。有些产品使用七八个步骤,有些产品使用十个步骤,但超过十个步骤后,比例尺就开始变细,出现一些没人用的尺寸。

现在给它们命名。不要用“text-31”或“39px”。按角色命名:标题、小标题、正文、导语、h4、h3、h2、h1、展示标题。角色名称是与工程部门的约定,而不是像素值。如果基础标题或宽高比发生变化,像素值可能会改变,但角色保持不变。h1 始终是最大的标题。正文始终是基础文本。标题始终是最小的清晰文本。

这使得比例尺成为一个系统,而不是一个电子表格。设计师说“这是正文”,工程师发布文本正文。如果比例尺在下个季度发生变化,正文仍然指正文,每个组件都会自动获取新值。没有人需要查找代码库中所有 16 并将其更改为 17。

Material Design 3 以角色命名其比例尺:display、headline、title、label、body,每个角色内部都有尺寸变体(大号、中号、小号)。Apple 的 HIG 包含 Large Title、Title 1、Title 2、Title 3、Headline、Body、Callout、Subhead、Footnote、Caption 1、Caption 2。Tailwind 提供 text-xs 到 text-9xl,这是 T 恤尺码,而不是角色命名,这也是 Tailwind 的默认值可能不如 Material Design 的地方。大多数采用 Tailwind 的团队最终都会在 T 恤类之上添加角色命名的别名。

将比例尺转换为设计令牌

令牌将设计师电子表格中的比例尺转换为团队的契约。

设计代币 是代表设计决策的命名值。对于字体比例尺,你需要三个层级:

  1. 原始令牌。实际的尺寸值。例如 font-size-100font-size-200 等,或者像 font-size-bodyfont-size-h1 这样命名。这些是真实数据的来源。

  2. 语义令牌。表达意图的别名。例如 text-heading-pagetext-body-defaulttext-caption。语义令牌指向原始令牌。组件使用语义令牌,而不是直接使用原始令牌。

  3. 组件令牌。 特定组件内部的绑定。card-title-size 指向 text-heading-cardtext-heading-card 又指向 font-size-200。组件令牌允许您对每个组件进行覆盖,而不会破坏系统。

一个最小的 JSON 令牌文件,适用于 16 基数、1.25 比例的刻度:

{
  "font-size": {
    "raw": {
      "100": { "value": "0.625rem" },
      "200": { "value": "0.8125rem" },
      "300": { "value": "1rem" },
      "400": { "value": "1.25rem" },
      "500": { "value": "1.5625rem" },
      "600": { "value": "1.9375rem" },
      "700": { "value": "2.4375rem" },
      "800": { "value": "3.0625rem" },
      "900": { "value": "3.8125rem" }
    },
    "semantic": {
      "caption":  { "value": "{font-size.raw.100}" },
      "small":    { "value": "{font-size.raw.200}" },
      "body":     { "value": "{font-size.raw.300}" },
      "lead":     { "value": "{font-size.raw.400}" },
      "h4":       { "value": "{font-size.raw.500}" },
      "h3":       { "value": "{font-size.raw.600}" },
      "h2":       { "value": "{font-size.raw.700}" },
      "h1":       { "value": "{font-size.raw.800}" },
      "display":  { "value": "{font-size.raw.900}" }
    }
  }
}

这种结构具有可移植性。Style Dictionary、Tokens Studio、Specify、Supernova 等工具都能读取此格式并生成 Figma 变量、CSS 变量、Tailwind 配置、iOS Swift 常量、Android XML 等,满足平台的各种需求。令牌是源数据,其他所有内容均由系统自动生成。

体素示意图,由三个堆叠的水平板组成,分别标记为 RAW、SEMANTIC 和 COMPONENT,它们通过从上到下的细珊瑚线连接。
体素示意图,由三个堆叠的水平板组成,分别标记为 RAW、SEMANTIC 和 COMPONENT,它们通过从上到下的细珊瑚线连接。

将刻度放入 Figma 变量中

Figma 变量是设计团队存放刻度的地方,它被组织成一个带有语义别名的单一字体集合。

创建一个名为“Typography”(字体排印)的变量集合。在该集合中,为每个原始尺寸添加一个数字变量:size/100size/900,其对应的像素值为 rem 值(10、13、16、20、25、31、39、49、61)。然后添加第二层别名:text/captiontext/smalltext/bodytext/leadtext/h4text/h3text/h2text/h1text/display。每个别名都指向一个原始尺寸变量。

然后,为每个角色创建一种文本样式。 Heading/H1 使用 text/h1 来设置大小,标题字体使用标题字体系列,标题字重使用标题字重,标题行高比使用标题行高比来设置行距。Body/Default 使用 text/body,正文字体使用常规字重。每个角色重复此操作。

设计规范要求设计师使用文本样式来构建界面,而不是在检查器中输入字体大小。一旦团队遵循此规范,缩放比例就会自动生效。任何设置自定义大小的人都必须明显地打破此模式,而这种可见性就是规范的体现。

如果您支持多种密度模式,请将其与模式设置结合使用。“紧凑”模式可以覆盖原始大小变量,使用 1.125 的比例以获得更紧凑的体验。“舒适”模式可以使用 1.25。别名保持不变。组件不会改变。缩放比例只是在它们下方进行调整。这就是系统为您带来的效果。

将缩放比例绑定到 Tailwind CSS

Tailwind 配置是工程团队管理缩放比例的地方,它应该与 Figma 的变量结构完全一致。

tailwind.config.js 中,将 Tailwind 的默认 fontSize 替换为您的缩放比例:

module.exports = {
  theme: {
    fontSize: {
      'caption':  ['0.625rem',  { lineHeight: '1rem' }],
      'small':    ['0.8125rem', { lineHeight: '1.25rem' }],
      'body':     ['1rem',      { lineHeight: '1.5rem' }],
      'lead':     ['1.25rem',   { lineHeight: '1.75rem' }],
      'h4':       ['1.5625rem', { lineHeight: '2rem' }],
      'h3':       ['1.9375rem', { lineHeight: '2.375rem' }],
      'h2':       ['2.4375rem', { lineHeight: '2.875rem' }],
      'h1':       ['3.0625rem', { lineHeight: '3.5rem' }],
      'display':  ['3.8125rem', { lineHeight: '4.25rem' }],
    },
  },
}

现在,标记中的 text-h1 与 Figma 中的 Heading/H1 含义相同。类名是约定。工程师不选择尺寸,而是选择角色,角色会在构建时解析为正确的像素值。

这里的行高并非随意设置。其模式是:小尺寸的正文行高要窄一些,正文和导言的行距要宽一些,标题的行距又要窄一些。常见的规则是正文行高 1.5,标题行高 1.1 到 1.2,并在行距和 h4 字号附近过渡到 1.3 到 1.4。你可以将其表示为另一个标度(行距标度),也可以表示为逐级数值,但字号和行距之间的关系应该是经过精心设计的,而不是凭感觉。

如果你想在标度之外保留 Tailwind 的默认类(用于旧代码或第三方组件),请使用 extend 而不是直接替换 fontSize。但长远目标是只使用一个标度,而不是两个。在同一个产品中使用两个标度实际上只有一个标度,但会造成很多问题。

将标度与用于字体选择的 字体搭配指南 以及用于将标度置于上下文中的 设计系统 框架结合使用。标度是排版系统的一部分,字体选择和角色映射是其他部分。需要一个可用的字形系统、真实的令牌,以及从一开始就正确配置的 Figma + Tailwind?聘请 Brainy。我们通过 BrandBrainy 和 UXBrainy 交付完整的字形系统,令牌、Figma 变量和 Tailwind 配置已整合在一起,作为一个整体交付。

保持字形系统运行的治理规则

每个失效的字形系统都是因为例外情况而失效的。

以下三条规则比任何工具都能让字形系统运行得更久:

规则一:每个新组件都选择角色,而不是尺寸。 设计师在构建卡片时,会为正文选择 Body,为标题选择 H3,为时间戳选择 Caption。他们不会在检查器中输入 font-size: 18px。如果角色不存在,他们会通过系统提交一个新角色,而不是进行一次性覆盖。

规则二:例外情况需命名并注明日期。 如果市场团队需要在活动页面上使用 72px 的标题作为主图,而显示尺寸为 61px,则该例外情况需命名(例如 hero-marketing-q3-launch)并注明日期。活动上线后,该例外情况要么被纳入标准字体大小规范(如果可复用),要么被删除(如果是一次性使用)。禁止匿名覆盖。

规则三:字体大小规范按季度审核,而非年度审核。 每季度审核周期短,便于及时发现偏差。而每年审核周期长,会导致每个团队都围绕这些漏洞进行开发,回滚将耗费大量时间。季度审核只需十五分钟,而年度审核则需要重新设计。

那些丢失字体大小规范的团队事后总是会讲述同样的故事:有人需要为某个按钮设置 17px 的字体大小,有人需要为某个横幅设置 21px 的字体大小,六个月后,代码库中出现了 47 种字体大小,却无人知晓哪些才是真正需要的。字体比例尺已不复存在。剩下的只是一堆乱七八糟的字体大小。

避免这种情况的方法是,将字体比例尺视为一份合同,而不是一张电子表格。这份合同由工具(Figma 样式、Tailwind 类、lint 规则)和审核机制来执行。合同会在季度审核时重新协商。任何超出合同范围的内容都被视为错误。

由两个并排的厚重立方体组成的体素图像,立方体之间用一条纤细的发光珊瑚线连接,左侧立方体上刻有“DESIGN”,右侧立方体上刻有“CODE”。
由两个并排的厚重立方体组成的体素图像,立方体之间用一条纤细的发光珊瑚线连接,左侧立方体上刻有“DESIGN”,右侧立方体上刻有“CODE”。

常见问题解答

什么是模块化字体比例尺?

模块化字体比例尺是一种系统,其中产品中的每个字体大小都是通过将一个固定比例应用于一个基本尺寸而生成的。选择一个基本尺寸(通常网页上为 16 像素),选择一个比例(通常介于 1.125 和 1.618 之间),然后反复将基本尺寸乘以或除以该比例来生成各个尺寸。最终得到的是一个所有尺寸都与其他尺寸存在数学关系的比例尺,这使得排版具有一种任意像素选择所无法实现的内部一致性。

我应该使用什么比例的字体缩放比例?

根据产品所需的密度选择合适的比例。对于数据密集型产品,例如仪表盘和管理工具,标题不应分散用户对数据的注意力,建议使用 1.125 或 1.2 的比例。对于标准的 SaaS 营销页面、内容网站和产品页面(大多数 B2B 产品都位于这些页面),建议使用 1.25 或 1.333 的比例。对于编辑类、杂志类或展示类产品,建议使用 1.414 或 1.618 的比例,确保标题具有标题的视觉冲击力。最常见的错误是仅仅因为某个比例听起来很厉害就选择它,而不是因为它适合产品本身。

字体缩放比例应该包含多少种字号?

大多数可用于生产环境的缩放比例包含七到九种字号。标题、小号、正文、导字、h4、h3、h2、h1 和标题几乎涵盖了所有实际产品表面。如果字号少于七种,就会留下空白,设计师需要通过一次性的覆盖来填补这些空白。超过十个尺寸会使缩放比例过于稀疏,以至于某些尺寸永远不会被使用,并且系统维护起来也会更加困难。七到九个尺寸是最佳选择,角色名称应该描述每个尺寸的用途,而不是它的像素值。

字体缩放值应该使用 rem 还是 px?

对于网页,请使用 rem。浏览器默认的根字体大小为 16 像素,但用户可以通过辅助功能设置和浏览器偏好设置进行更改,基于 rem 的缩放会自动遵循这些偏好设置。基于像素的缩放则会忽略这些偏好设置。Tailwind、Material Design 和大多数现代设计系统都出于这个原因使用 rem。对于移动平台,请遵循平台的规范:iOS 使用点 (point) 并支持动态字体,Android 使用与缩放无关的像素 (sp)。原则相同,使用平台的相对单位,而不是绝对单位。

模块化字体缩放和设计令牌之间有什么区别?

模块化字体缩放是计算公式,设计令牌是实现这些计算公式的方式。比例尺定义了数值(10、13、16、20、25、31、39、49、61)。令牌(Tokens)是命名层,它允许设计系统的其他部分引用这些数值,而无需硬编码。你可以拥有一个没有令牌的比例尺,但这样的比例尺无法在实际代码库中存活。你也可以拥有令牌而没有比例尺,但这些值将是任意的。完整的系统是用令牌表示的比例尺,包含原始层、语义层和组件层,并通过同一源代码交付给 Figma 和代码。

大多数字体比例尺都忽略的模式

字体比例尺不是字体大小的列表,而是关于文本如何在产品中获得层级关系的契约。

真正做好这一点的团队不会选择一个比例就止步不前。他们选择一个比例,构建规模,将其以代币的形式交付,并将其集成到 Figma 和 Tailwind 中,然后通过季度审核和严格的无例外规则来强制执行。规模本身并非最终交付物,而这种规范才是。最终交付物是规范得以实现的基础。

那些在这方面犯错的团队把规模当作灵感板。他们在 Pinterest 的模型图上挑选漂亮的比例,发布一份静态的规范文档,六个月后才发现工程团队从未采用过它,因为规范文档无法执行。或者,他们将规模部署到 Figma 中,却从未部署到 Tailwind 中,导致设计文件和生产应用渐行渐远,最终变成两个字体不同的产品。又或者,他们将规模部署到两者中,却从未进行任何管理,结果一年之内例外情况的数量就超过了规则的数量。

捷径是从一开始就将规模视为一份契约。数学模型设定了步骤,而代币则使这些步骤得以交付。 Figma 变量和 Tailwind 配置使得设计工程师和工程师双方都能使用这些步骤。治理机制确保这些步骤在发布后仍然有效。系统的每个部分都只负责一项任务,如果其中任何一个部分缺失,系统都会失效。

如果您想要一个可用的模块化类型量表、真正的令牌、真正的 Figma 变量、真正的 Tailwind 配置,以及一个能够在发布后维持量表运行的治理方案,聘请 Brainy。我们通过 BrandBrainy 和 UXBrainy 交付完整的系统设计,其中类型量表从一开始就被设计成令牌,排版系统品牌配色方案 连接,并且有相应的规则确保团队发布后系统仍然有效运行。

Need a type scale that holds up across Figma, Tailwind, and a six-product surface? Brainy ships full design systems through BrandBrainy and UXBrainy, with type scales designed as tokens from day one.

Get Started