Appearance
模块 3：设计系统构建
A design system is not a collection of components — it is the institutionalized taste of an organization, expressed in tokens, patterns, and governance.
学习目标
完成本模块后，你将：
- 理解设计系统作为"品味的制度化形式"的本质——它不只是效率工具，更是品味传递工具
- 掌握设计系统的核心架构：token → 组件 → 模式 → 页面，及每层的品味编码功能
- 比较五个真实设计系统（Material Design、Apple HIG、Carbon、Primer、Ant Design）的品味立场和编码策略
- 理解设计系统的治理问题——谁有权修改系统？品味标准如何在系统中演化？
- 评估"构建 vs 采用"的决策框架——什么时候应该建自己的设计系统，什么时候应该采用现有的
一、设计系统的本质：品味的制度化
从组件库到品味系统
设计系统（Design Systems）在 2010 年代后期成为产品设计的标准实践。但大多数关于设计系统的讨论聚焦在效率层面——"减少重复工作"、"保持一致性"、"加速开发"。这些都是真实的价值，但它们遮蔽了设计系统更深层的本质：
设计系统是组织品味的制度化形式。
当你创建一个 Button 组件并规定它的圆角是 8px、内边距是 12px 16px、默认字号是 14px 加粗、主色调是 #2563EB 时，你在做的不是"提升效率"——你在做一个品味决策并将它固化。此后每个使用这个组件的人都不需要（也不能）重新做这个品味决策。
这既是设计系统的力量，也是它的风险。力量在于：它让品味决策被做一次、执行无数次。风险在于：如果这个品味决策不够好，它也会被执行无数次。
Nathan Curtis 在 Modular Web Design（2009）和后续的博客系列中反复强调：设计系统的核心不是技术（token 如何存储、组件如何封装），而是决策——哪些品味决策值得固化，哪些应该留给使用者自行判断。
Brad Frost 的 Atomic Design
Brad Frost 在 2013 年提出、2016 年出版的 Atomic Design 为设计系统提供了最广泛使用的架构框架。他借用化学的隐喻，将设计系统分为五层：
| 层次 | 化学隐喻 | 设计系统实体 | 品味编码功能 |
|---|---|---|---|
| Atoms | 原子 | 颜色、字体、间距、图标等最基本元素 | 品味的"基因"——最底层的品味决策 |
| Molecules | 分子 | 由原子组合成的简单组件（搜索框、表单字段） | 品味的"词汇"——基本的品味表达单元 |
| Organisms | 有机体 | 由分子组合成的复杂区块（导航栏、卡片列表） | 品味的"句子"——有上下文的品味组合 |
| Templates | 模板 | 页面布局结构 | 品味的"段落"——内容组织的品味框架 |
| Pages | 页面 | 填充了真实内容的完整页面 | 品味的"文章"——品味在具体语境中的最终表达 |
Frost 的框架之所以重要，不是因为它的分层本身——任何有经验的设计师都直觉地在这些层次上工作。它的价值在于给品味编码提供了一个从微观到宏观的系统化路径。
但 Frost 自己也承认这个框架的局限：层级之间的边界是模糊的——什么算"分子"什么算"有机体"常常是主观判断。更重要的是，这个框架只描述了品味的结构，没有描述品味的内容——它告诉你品味应该被编码在哪些层次上，但不告诉你品味应该是什么。
Design Tokens：品味的最小单元
Design Tokens（设计令牌）是 Salesforce 设计团队在 2014 年提出的概念，现在已成为设计系统的基础设施。Token 是品味的最小编码单元——一个命名的值（named value），它代表了一个品味决策。
Token 的层次结构体现了品味决策的抽象程度：
全局 Token（Global Tokens）
--blue-500: #3B82F6;
--spacing-4: 16px;
--radius-md: 8px;这些是原始值——它们不携带语义信息，不告诉你这些值应该用在哪里。
语义 Token（Semantic Tokens）
--color-primary: var(--blue-500);
--color-danger: var(--red-500);
--spacing-section: var(--spacing-4);语义 Token 给原始值赋予了品味含义——"primary"意味着"最重要的行动"，"danger"意味着"需要警惕的操作"。这一层编码了品味的意图。
组件 Token（Component Tokens）
--button-bg-primary: var(--color-primary);
--button-radius: var(--radius-md);
--button-padding: var(--spacing-3) var(--spacing-4);组件 Token 将语义含义绑定到具体组件上。这一层编码了品味的执行。
品味含义： Token 的三层结构对应了模块 2 中讨论的编码层次。全局 Token 是"规则层"——精确的数值。语义 Token 是"指南层"——有意义但留有诠释空间。组件 Token 是"自动化层"——直接绑定到代码中自动执行。
一个设计系统的品味品质很大程度上取决于它的 Token 设计是否精细。一个只有全局 Token（直接使用 #3B82F6）的系统意味着品味决策和具体数值绑死了——每次修改品味都需要在所有使用处逐一更改。一个有完整三层 Token 的系统意味着你可以通过修改一个语义 Token 的值来全局调整品味方向——比如将 --color-primary 从蓝色改为紫色，所有使用 primary 语义的地方都会一起更新。
二、五个设计系统的品味比较
比较框架
要比较不同设计系统的"品味"，需要一个分析框架。以下五个维度可以帮助你识别一个设计系统的品味立场：
| 维度 | 说明 |
|---|---|
| 视觉密度 | 信息密集 vs 留白充裕 |
| 装饰程度 | 极简克制 vs 丰富表达 |
| 控制程度 | 严格规范 vs 灵活框架 |
| 情感调性 | 中性专业 vs 有温度有个性 |
| 目标受众 | 面向专业设计师 vs 面向开发者 |
Material Design（Google, 2014-）
品味立场： "有序的活力"——通过物理隐喻（材质、光影、运动）在数字界面中创造有层次感和动感的体验。
核心品味决策：
- 海拔系统（Elevation）：用阴影深度表达层级关系——这是 Material Design 最核心的品味概念
- 8dp 基准网格：所有间距和尺寸以 8dp 为基本单位
- 动效为品味的核心表达——Material 的运动设计（duration、easing）比视觉设计更能体现其品味
品味演化： Material Design 经历了三个品味时代。MD 1.0（2014）偏向严格和统一——大面积纯色、固定的 FAB 按钮、明确的卡片系统。MD 2.0（2018，Material Theming）开始允许品牌定制——颜色、字体、形状可以被自定义。MD 3.0（2021，Material You）走向了动态化和个性化——基于壁纸自动生成的动态配色（Dynamic Color）彻底改变了 Material 的品味哲学。
品味评价： Material Design 的品味贡献在于它让"有品味的默认"成为可能——在 MD 之前，大量 Android App 的视觉品质很低。它的局限在于过度规则化（尤其是 MD 1.0）导致了同质化——所有 Material App 看起来都像 Google 做的。
Apple Human Interface Guidelines（Apple, 1987-）
品味立场： "精致的克制"——追求视觉上的精确和优雅，强调与硬件体验的一致性。
核心品味决策：
- 模糊和半透明（Vibrancy）：从 iOS 7（2013）开始，层叠半透明材质成为 Apple 的品味标志
- SF 字体系统：从 SF Pro 到 SF Rounded 到 SF Mono，完整的字体家族为不同场景提供品味一致的排版选择
- 系统级动效：spring animations 和 interruptible transitions 创造了 iOS 特有的"弹性"品味
品味评价： Apple HIG 的品味核心在于"人造物的自然感"——界面应该像物理物体一样有重量、有惯性、有弹性。这种品味在 iOS 7 的扁平化转型和 iOS 15+ 的"材质回归"中保持了一致的精神：无论视觉风格如何变化，"自然"和"精确"始终是核心。
Carbon Design System（IBM, 2017-）
品味立场： "理性的严肃"——为企业级产品设计的系统，强调信息密度、可及性和专业感。
核心品味决策：
- IBM Plex 字体：专门为 IBM 设计的开源字体家族，品味兼具技术感和人文感——这本身就是一个重大的品味声明
- 高密度布局：Carbon 的默认间距比 Material 更紧凑，因为企业用户需要在一屏内看到更多信息
- 无障碍作为品味的核心——Carbon 将 WCAG AAA 标准作为默认而非选项
品味评价： Carbon 代表了"品味不等于美学"的立场——在企业软件中，品味更多体现在信息架构的清晰度、操作效率和可及性上，而非视觉表现力。它的设计风格可能在消费者产品中显得"沉闷"，但在企业环境中恰恰是对的。
Primer（GitHub, 2016-）
品味立场： "工具的诚实"——为开发者设计的系统，强调功能透明、认知负担最小化、内容优先。
核心品味决策：
- 极度克制的装饰——Primer 几乎不使用装饰性元素（无渐变、无复杂阴影、极少的动效）
- 以 Markdown 为核心的内容假设——系统围绕文本内容优先的使用场景设计
- 暗色模式作为一等公民——开发者群体对暗色模式的偏好使得 Primer 在暗色模式的品味投入上超过大多数设计系统
品味评价： Primer 的品味是"不要让界面碍事"——它的设计品质不在于视觉表现力，而在于不可见性。当你使用 GitHub 时，你几乎不会"注意到"设计——你的注意力全在代码和讨论上。这种品味需要极高的克制：不是因为缺乏设计能力，而是有意识地选择不表达。
Ant Design（蚂蚁集团, 2015-）
品味立场： "效率的秩序"——为中后台企业应用设计的系统，强调操作效率、信息密度、一致性。
核心品味决策：
- 高信息密度：Ant Design 的默认表格、表单、列表密度明显高于西方设计系统
- 实用主义的装饰：少量但有效的视觉反馈（hover 状态、选中状态），不追求视觉表现力
- 完整的中文排版考量——间距和行高针对中文字符优化
品味评价： Ant Design 是最成功的非西方设计系统，它的品味立场反映了中国企业软件市场的需求——高效率、高密度、功能完整。它在美学维度上的相对"保守"不是品味缺失，而是品味优先级的选择：在中后台场景中，效率品味高于美学品味。但在 C 端产品中直接使用 Ant Design 的结果通常缺乏品味感——因为它的品味设计不是为消费者体验优化的。
三、设计系统的治理
核心治理问题：谁有权修改品味？
设计系统的治理（Governance）是一个被严重低估的问题。技术上，建立一个设计系统不难——有大量的工具和框架可以使用。但决定谁有权修改设计系统中的品味决策，是一个组织政治问题，而非技术问题。
三种治理模式：
中央集权模式（Centralized）
一个核心设计系统团队拥有系统的完全控制权。所有修改必须经过这个团队的评审和批准。
| 优势 | 局限 |
|---|---|
| 品味一致性最高 | 更新速度慢——所有需求都要排队 |
| 品味标准清晰 | 与产品团队的实际需求可能脱节 |
| 单一品味权威 | 设计系统团队可能成为瓶颈 |
典型案例： Salesforce Lightning Design System 由一个独立的设计系统团队维护，产品团队只能"使用"而不能"修改"。
联邦制模式（Federated）
一个核心团队维护基础 Token 和核心组件，但各产品团队可以在基础之上创建自己的扩展组件。
| 优势 | 局限 |
|---|---|
| 平衡了一致性和灵活性 | 治理复杂——哪些是"基础"哪些是"扩展"需要不断协商 |
| 产品团队有创造空间 | 扩展组件可能偏离品味标准 |
| 创新可以自下而上涌现 | 成功的扩展需要晋升为核心组件的机制 |
典型案例： Spotify 的 GLUE 设计系统采用联邦制——核心 Token 和组件由中央团队维护，各产品团队可以创建和提交新组件，经评审后可能被纳入核心系统。
分布式模式（Distributed）
没有核心团队——设计系统由所有使用它的团队共同维护，类似开源项目的贡献模式。
| 优势 | 局限 |
|---|---|
| 最大的社区参与度 | 品味一致性最低 |
| 更新速度最快 | 品味权威模糊 |
| 最贴近实际使用场景 | 容易陷入"设计委员会"效应 |
典型案例： GitHub 的 Primer 在一定程度上采用分布式模式——GitHub 的不同产品团队可以提交 PR 修改设计系统。
品味守门人的角色
无论哪种治理模式，成功的设计系统都需要一个角色：品味守门人（Taste Gatekeeper）。这个人（或小组）的职责不是做所有品味决策，而是确保所有品味决策符合系统的品味标准。
品味守门人需要具备：
- 深刻理解系统的品味哲学——不只是知道规则，而是理解规则背后的品味逻辑
- 说"不"的勇气和权威——当一个修改提议在技术上可行但品味上不达标时，品味守门人需要有权拒绝
- 解释品味判断的能力——拒绝不够——必须解释为什么拒绝，以及什么样的修改是可接受的
- 品味的演化意识——知道何时品味标准本身需要更新
这个角色本质上就是模块 1 讨论的"品味领导者"在设计系统语境中的体现。
四、构建 vs 采用：品味决策框架
什么时候应该构建自己的设计系统？
这是产品团队面临的最常见决策之一。答案取决于几个维度的评估：
构建自己系统的理由：
- 产品品味有明确且独特的方向——不是"跟别人一样好"而是"和别人不一样"
- 团队规模足够大（通常 >30 人），一致性问题已经显现
- 有能力投入长期维护——设计系统不是一次性项目，而是持续投入
- 产品域有特殊需求——现有设计系统无法满足的交互模式或视觉需求
采用现有系统的理由：
- 产品品味方向与某个现有系统高度吻合
- 团队规模小（<30 人），一致性可以通过沟通解决
- 需要快速上线——构建设计系统需要 6-12 个月才能达到可用状态
- 技术栈与某个现有系统高度匹配
品味定制的三个层次
如果选择采用现有设计系统，可以在三个层次上进行品味定制：
层次一：Token 定制（最低成本）
只修改全局和语义 Token——颜色、字体、间距、圆角。组件结构和交互行为保持不变。这是 Material Theme 和 Ant Design 的 ConfigProvider 所支持的定制层次。
品味效果：产品获得了"品牌色"的差异化，但交互品味完全是所采用系统的品味。
层次二：组件定制（中等成本）
在 Token 定制的基础上，修改或替换部分组件——比如自定义导航栏、自定义卡片样式、自定义表单交互。核心组件库仍来自所采用系统。
品味效果：产品在关键触点上有自己的品味表达，但"底色"仍是所采用系统的品味。
层次三：理念借鉴（最高成本）
只借鉴所采用系统的架构思想（token 结构、组件分层、命名约定），但所有具体的品味决策都是自己做的。这实际上已经接近"构建自己的系统"。
品味效果：产品有完全独立的品味表达，但获得了成熟架构的思想支持。
五、设计系统的品味陷阱
陷阱一：一致性崇拜
最常见的设计系统陷阱是将一致性本身当作目标。一致性是手段，不是目的——品味的目的是创造好的体验，不是创造统一的体验。
"Consistency is the last refuge of the unimaginative." — Oscar Wilde
当一致性与好体验冲突时（比如某个特殊场景需要打破常规的交互模式），好的品味判断应该选择好体验，而不是一致性。设计系统应该有明确的"逃生舱"机制——允许在有充分理由时偏离系统规范。
Spotify 的设计系统有一个明确的"一致性光谱"概念：核心交互模式（登录、支付）必须严格一致；品牌表达（播放列表封面、年度回顾）允许高度自由。这种分层的一致性策略比全面一致性更有品味。
陷阱二：中间地带的丧失
设计系统在 Atoms 和 Pages 这两端通常做得很好——Token 有精确定义，完整页面有设计稿参考。但中间地带——Molecules 和 Organisms 的组合方式、组件之间的间距关系、布局在不同内容量下的适应——往往缺乏编码。
这个中间地带恰恰是品味判断最密集的区域。一个搜索框的内部间距是 Token 定义的；一个搜索结果页面的整体布局有设计稿参考。但搜索框和搜索结果之间的间距、搜索结果为空时的提示文案、搜索加载中的状态表现——这些组合层面的品味判断通常落在设计系统的编码盲区。
陷阱三：设计系统作为品味替代
最深层的陷阱：使用设计系统不等于有品味。
你可以完全遵循 Material Design 的每一条规范，做出一个技术上"合规"但品味上平庸的产品。设计系统编码了品味的底线（不会太差），但不能保证上限（真正好）。
真正有品味的产品——Notion、Linear、Figma、Arc Browser——都在使用设计系统的同时做出了大量超越系统规范的品味判断。设计系统是品味的地基，不是品味的天花板。
设计系统/组织设计
Figma 的设计系统困境
问题：Figma 是帮助其他公司构建设计系统的工具，但 Figma 自身的产品设计长期没有正式的公开设计系统。2024 年 Figma 进行了品牌重塑并开始建立自己的设计语言。这种'鞋匠没有鞋'的现象说明了什么？建立设计系统对 Figma 意味着什么样的品味决策？
分析：Figma 的情况说明了一个重要的品味编码原则：不是所有组织都需要在同一时间正式化他们的设计系统。在 Figma 早期（2015-2022），团队规模小、产品迭代快、品味方向还在演化——这种状态下，非正式的品味对齐（小团队的直觉+原则层编码）比正式的设计系统更有效率。强行在品味方向未稳定时建立设计系统，会固化错误的品味判断。2024 年的品牌重塑标志着 Figma 的品味方向成熟到可以被编码了：多色系统、圆润的几何形状、动态的品牌表达。对 Figma 来说，建立设计系统不只是内部效率问题——它还是品味声明：作为设计工具公司，你自己的设计系统本身就是品味能力的展示。
设计系统品味判断
以下描述了不同的设计系统实践。判断每个实践的品味水平，然后查看分析。
样本 A
样本 B
样本 C
样本 D
五大设计系统品味比较
Material Design (Google)
品味关键词：有序、动感、科学化。优势：最完整的规范文档和最大的社区。品味立场：通过物理隐喻（材质、光影、运动）让数字界面有质感。局限：过度规则化导致同质化，MD 1.0 时代尤甚。
Apple HIG
品味关键词：精致、克制、自然。优势：与硬件深度整合，品味一致性跨设备。品味立场：界面应该像物理世界一样有重量和惯性，但比物理世界更精确。局限：对非 Apple 生态的适用性低，品味假设了高端硬件。
Carbon (IBM)
品味关键词：理性、严肃、可及。优势：企业级品味的最佳参考，无障碍标准极高。品味立场：信息密度和操作效率是企业环境中的品味核心。局限：在消费者产品语境中显得沉闷。
Primer (GitHub)
品味关键词：透明、克制、内容优先。优势：为开发者场景做了深度优化。品味立场：最好的设计是你不注意到的设计。局限：品味表达力弱，不适合需要强品牌存在感的产品。
Ant Design (蚂蚁集团)
品味关键词：高效、密集、实用。优势：中文场景的最佳设计系统，组件极其丰富。品味立场：企业效率优先，功能完整性优先于美学表现力。局限：直接用于 C 端产品通常缺乏品味差异化。
思考：如果你要为以下三种产品选择或构建设计系统，你会怎么选择？(1) 一个面向消费者的金融 App；(2) 一个企业级数据分析平台；(3) 一个面向设计师的创作工具。你的选择如何反映了不同产品的品味需求？
设计系统品味审计
25-35 minutes选择一个你日常使用的产品（App 或网站），分析它背后的设计系统（很多产品会公开自己的设计系统文档）。评估这个设计系统的品味立场——它编码了什么品味决策？这些品味决策是否与产品的用户体验一致？你能识别出设计系统的编码盲区吗？
建议结构：
产品与设计系统识别~15%
命名产品，找到它使用的设计系统（如果公开的话）。如果没有公开的设计系统文档，从产品界面推断其设计系统的特征。
品味立场分析~25%
这个设计系统的品味关键词是什么？它在视觉密度、装饰程度、控制程度、情感调性上处于什么位置？
Token 和组件层品味~25%
观察产品的颜色、间距、圆角、字体——这些底层品味决策传达了什么？组件的交互行为反映了什么品味假设？
编码盲区~20%
在哪些地方你感到产品的品味不一致或品味缺失？这些地方可能是设计系统的编码盲区——存在品味判断但没有被编码的区域。
改进建议~15%
如果你是这个设计系统的品味守门人，你会做什么改变来提升品味品质？
- 很多设计系统有公开文档——搜索[产品名] design system，你可能会找到 Storybook、Figma 文件或设计原则页面
- 如果找不到文档，从界面推断：截图几个页面，对比它们的颜色、间距、字体、组件样式是否一致
- 品味盲区通常出现在组件组合的层面——不是单个按钮或卡片的品味，而是它们在一起时的品味
- 思考一下产品的品味是否与它的定位匹配——一个面向创意专业人士的工具应该有什么样的设计系统品味？
目标：500 字
延伸阅读
必读
Brad Frost, Atomic Design (2016)
- 可在线免费阅读：atomicdesign.bradfrost.com
- 核心价值在于分层思维——不只是"怎么建设计系统"，而是"品味如何在不同层次上被组织"
Alla Kholmatova, Design Systems: A Practical Guide to Creating Design Languages (2017)
- Smashing Magazine 出版。比 Frost 更关注"品味决策"层面——如何定义设计原则、如何命名模式、如何建立共享语言
推荐
Nathan Curtis, Modular Web Design (2009)
- 设计系统概念的早期先驱之一——在"设计系统"一词流行之前就讨论了模块化设计的品味编码
Ethan Marcotte, Responsive Web Design (2011)
- A List Apart 文章到同名书。Marcotte 的响应式设计框架是设计系统必须处理的品味维度之一——品味如何在不同屏幕尺寸上保持一致？
Design Systems Repo — designsystemsrepo.com
- 收集了数百个公开的设计系统——是比较不同设计系统品味立场的最佳起点
在线资源
- Figma Design Systems — Figma Community 中的开源设计系统文件，可以直接在 Figma 中检查组件和 Token 结构
- Storybook — 很多设计系统使用 Storybook 作为组件文档工具，可以交互式浏览组件的品味细节
本模块要点
- 设计系统是组织品味的制度化形式——它不只是效率工具，更是品味传递的媒介
- Atomic Design 提供了从微观到宏观的品味编码路径——Atom → Molecule → Organism → Template → Page
- Design Token 是品味的最小编码单元——全局 Token → 语义 Token → 组件 Token 的三层结构对应了不同抽象程度的品味决策
- 不同设计系统有不同的品味立场——Material 追求有序的活力、HIG 追求精致的克制、Carbon 追求理性的严肃、Primer 追求透明的克制、Ant Design 追求效率的秩序
- 治理是设计系统最被低估的问题——谁有权修改品味？中央集权、联邦制、分布式各有权衡
- 品味守门人是必要角色——无论治理模式如何，都需要有人确保品味决策的质量和一致性
- 构建 vs 采用取决于品味独特性需求——品味方向越独特，越需要构建自己的系统
- 一致性崇拜是最常见的品味陷阱——一致性是手段不是目的，好体验可以优先于一致性
- 设计系统的中间地带常常是品味盲区——组件组合层面的品味判断最容易被编码遗漏
- 使用设计系统不等于有品味——设计系统是品味的地基而非天花板，真正的品味在系统之上
下一步
设计系统编码了品味的"what"——什么是好的。但品味传递需要更多：它需要教会团队"why"——为什么这是好的。下一模块深入探讨品味如何在人与人之间传递——从 Pixar 的 Braintrust 到 IDEO 的设计文化，从设计评审的方法论到招聘中的品味评估，从导师制到"showing not telling"的品味教学法。如果设计系统是品味的"硬件"，品味传递就是品味的"软件"。
模块 3 自评
基于你在本模块中的学习和设计系统品味审计练习，对自己做一次诚实的评估。
设计系统架构理解对 Token/组件/模式/页面层级及其品味编码功能的理解
品味立场识别识别和比较不同设计系统品味立场的能力
治理意识对设计系统治理问题的理解
品味陷阱识别识别设计系统品味陷阱的能力