【设计系统】完全指南：从规范到组件库，5步搭建+3个误区

设计系统，简单来说，就是一套帮助团队统一设计语言、复用设计资产，并让产品长期保持一致性的完整体系。

它不只是几个按钮和输入框组成的组件库，也不只是颜色、字体、间距这些设计规范，而是把设计原则、基础规范、组件、变量、交互规则、页面模板和使用文档等内容组织起来，让产品、设计、开发都能按照同一套规则工作。

当一个产品只有三五个页面时，设计系统的重要性可能还不明显。但随着页面越来越多、设计师越来越多、版本持续迭代，问题很快就会出现：同样的按钮有三种高度，同样的弹窗有四种样式，一个品牌色调整后几十个页面都要手动修改，新设计师加入团队后还不知道该参考哪一版。

设计系统，就是为了解决这些问题。

设计系统（Design System）可以理解为一套围绕产品设计建立起来的“统一语言”。

它规定了产品应该使用什么颜色、字体、间距和组件，也规定这些元素在什么场景下使用、不同状态应该如何表现，以及设计和开发如何共同维护这些规则。

比如，一个产品规定主按钮统一使用品牌蓝色、高度40px、圆角8px。当用户鼠标悬停时颜色变深，禁用状态使用灰色，加载时显示Loading图标。

如果这些规则只写在一份文档里，它更接近设计规范；如果把按钮真正制作成可以重复使用的组件，就形成了组件库；而当颜色、组件、交互规则、设计原则、开发规范、使用文档等全部连接起来，才真正构成一套设计系统。

设计规范更像一本“说明书”。

它会告诉设计师，品牌主色是什么，正文应该使用多大字号，不同页面的间距是多少，按钮应该如何设计。

设计系统的范围则更大。

它不仅告诉你“应该怎么设计”，还提供可以直接使用的设计资产，并建立一整套维护和协作机制。

比如设计规范可能规定：“主按钮高度40px，圆角8px。”

设计系统不仅会写下这条规则，还会把主按钮制作成标准组件，并定义默认、悬停、点击、加载、禁用等不同状态。设计师可以直接拖入页面使用，开发也能找到对应的代码组件。

所以，设计规范是设计系统的重要组成部分，但设计系统不等于设计规范。

组件库是设计系统中最容易被看见的一部分，因此很多团队会误以为“做了一套组件，就是建立了设计系统”。

实际上，组件库解决的主要是“重复使用”问题。

按钮、输入框、下拉菜单、表格、卡片、导航、弹窗等元素都可以制作成组件。设计师下一次做新页面时，不需要从零开始画，直接调用已有组件即可。

但组件库并不会自动告诉你，这个组件为什么这样设计、应该在什么场景使用、不同组件之间如何组合、什么时候应该使用弹窗而不是抽屉。

这些都需要设计原则、交互规范和使用文档来补充。

因此，可以简单理解为：组件库解决“有什么可以用”，设计规范解决“应该怎么设计”，而设计系统解决的是“整个团队如何用同一套规则持续设计和开发产品”。

不同团队的设计系统规模差异很大，但一套相对完整的设计系统，通常会包含以下几个核心部分。

设计原则决定的是整个产品设计的大方向。

比如一个企业级产品可能强调“清晰、高效、稳定”，一个面向年轻用户的消费类App可能更强调“轻松、有趣、个性化”。

这些原则看起来比较抽象，却会影响很多具体设计决策。

当设计师面对两个方案不知道该选哪个时，设计原则就是判断标准。如果产品强调效率，那么界面设计就应该减少装饰，让高频操作更直接；如果产品强调易用，就不能为了视觉效果隐藏重要功能。

设计原则相当于整个设计系统的“底层方向”。

这是设计系统最基础的一层，包括颜色、字体、字号、间距、圆角、阴影、图标、栅格等。

这些内容看起来很细，却直接决定了产品的一致性。

如果没有统一规范，一个设计师可能使用12px圆角，另一个使用8px；一个页面标题是24px，另一个页面变成22px。单独看都不一定有问题，但放在一起，就会让整个产品显得杂乱。

基础规范的价值，就是把这些高频、重复的设计决策提前统一下来。

设计师不需要每次重新思考“这里到底用什么灰色”“这个间距应该16px还是20px”，而是直接按照系统规则执行。

随着设计系统越来越成熟，很多团队都会进一步引入设计变量和Design Token。

你可以把它理解成给设计属性“起名字”。

比如不直接使用某一个具体的蓝色色值，而是定义一个“品牌主色”；不直接规定某个按钮间距是16px，而是调用一套统一的间距变量。

这样做最大的好处是方便统一修改。

比如产品准备更换品牌色，如果几十个页面里的颜色都是设计师手动填写的，就需要一个个修改。如果全部绑定到同一个颜色变量，只需要修改变量值，相关设计就能统一更新。

深色模式、多品牌产品、多语言产品和多端设计，也非常依赖这类变量体系。

组件是设计系统真正进入日常工作流的重要部分。

按钮、输入框、下拉菜单、复选框、标签、卡片、表格、导航、弹窗，都可以制作成统一组件。

组件最大的价值不是“少画几次”，而是让产品在持续迭代中保持统一。

比如一个产品已经有100个页面，如果每个页面里的按钮都是独立绘制的，后面想调整按钮样式会非常痛苦。

而使用统一组件后，设计师只需要维护核心组件，新页面继续复用即可。

对于B端系统和后台管理系统来说，组件化尤其重要。因为这些产品往往页面多、表单多、表格多，重复结构非常明显。如果没有组件体系，设计成本会随着页面增加不断上涨。

一个完整组件不能只有“静态长什么样”，还要考虑用户使用时会发生什么。

比如一个输入框，至少可能出现默认、聚焦、已填写、禁用、错误等状态；一个按钮也可能有默认、悬停、点击、加载和禁用状态。

如果这些状态没有提前定义，不同设计师就可能各自发挥。

更麻烦的是，开发在实现时也不知道到底应该按照哪一种逻辑处理。

因此，成熟的设计系统会把视觉状态和交互行为一起定义清楚。

这样设计师知道怎么画，开发知道怎么实现，用户在不同页面里也能形成稳定预期。

当组件体系越来越成熟后，还可以进一步沉淀页面模板和设计模式。

比如后台系统里常见的列表页，往往由页面标题、筛选区、操作区、表格和分页组成；详情页可能由基础信息、状态、操作入口和业务模块组成。

这些结构如果每次都重新设计，效率并不高。

所以团队可以把成熟的页面结构进一步沉淀为模板。

再比如“删除数据应该如何确认”“长表单应该如何拆分”“新用户第一次进入空页面应该显示什么”，这些高频问题也可以沉淀成固定的设计模式。

设计系统做到这一步后，解决的就已经不只是“页面长得一样”，而是让团队对常见设计问题形成统一解决方式。

组件做得再漂亮，如果没有人知道怎么用，设计系统依然很难真正落地。

所以成熟的设计系统还需要文档。

比如一个弹窗组件，除了展示样式，还应该说明什么情况下适合使用、标题应该怎么写、按钮数量最多几个、危险操作如何处理。

这些说明能帮助设计师减少错误使用，也能帮助新成员更快理解团队规则。

设计系统真正有价值的地方，不是里面有多少组件，而是团队遇到重复问题时，可以从系统里快速找到统一答案。

很多团队一听要做设计系统，就想一次性把所有组件、规范和文档全部整理出来。其实没有必要，设计系统更适合边用边建，从最常用的内容开始，再随着产品持续完善。

第一步不是马上画一套全新的按钮，而是先看看现在已经有什么。

可以把现有产品里的页面、颜色、字体、按钮、输入框、弹窗、表格等设计元素整理出来。

这个过程经常会发现很多问题。

比如同一个“确定”按钮竟然有四种高度，产品里出现了七种相近的灰色，三个设计师分别做了三套表格样式。

把这些问题找出来之后，再决定哪些应该保留、哪些应该统一、哪些应该删除。

设计系统不是凭空创造出来的，而应该从真实产品中逐步提炼。

盘点完成后，可以先从最基础的内容开始统一。

比如定义品牌主色、辅助色、文字颜色和状态颜色，再整理标题、正文、辅助文字等不同字体层级，同时确定常用间距、圆角和阴影规则。

这一阶段不用追求特别复杂，小团队完全可以先建立一套够用的基础规则，等产品规模扩大之后再继续完善。

这里推荐配合专业设计工具来管理。

比如摹客3支持设计系统、组件库、全局变量以及样式等能力，团队可以把颜色、文字、组件等设计资产统一沉淀下来，使这些设计资源与开发端保持一致，并在项目中持续复用。

使用地址：

以品牌色为例，如果产品已经有几十个页面，与其让设计师逐个修改，不如把颜色统一绑定为全局变量。后续品牌色调整时，只需要更新对应变量，就能大幅减少重复修改。

对于长期迭代的产品来说，这种方式比单纯“写一份设计规范文档”更实用，因为规范真正进入了设计过程。

基础规范确定后，再开始建立组件。

这里有一个原则：不要一次把所有能想到的组件都做出来。

先做使用频率最高的。

比如按钮、输入框、选择器、标签、弹窗、导航等。这些组件在不同页面重复出现，优先标准化能最快看到效果。

组件设计时还要考虑可扩展性。

比如按钮不能只设计一个默认样式，还要考虑大小、类型、图标、禁用和加载等变化。

组件做得越合理，后面新页面越容易像“搭积木”一样快速完成。

组件越来越多后，就要进一步建立系统之间的关系。

比如哪些组件使用主色，哪些状态使用错误色，不同尺寸按钮对应什么场景，表格操作区最多放几个按钮。

同时，可以逐步使用颜色变量、文字变量、尺寸变量等方式，把基础规范和组件真正关联起来。

这一步会让设计系统从“素材库”变成真正有规则的体系。

否则，即使团队有几百个组件，设计师仍然不知道应该什么时候用哪个，组件越多反而越乱。

设计系统永远不是一个“完成后就结束”的项目。

产品会更新，品牌会调整，新业务会出现，组件也会不断增加。

因此，更现实的做法是把设计系统当作产品一样持续维护。

新需求出现时，如果是已有模式，就优先复用；如果确实出现新的通用场景，再考虑沉淀为新组件。

定期检查哪些组件已经不用、哪些规则互相冲突、哪些设计已经过时，也同样重要。

设计系统真正成熟的标志，不是组件数量越来越多，而是团队越来越少重复解决同一个问题。

很多团队设计系统做得很完整，最后却没人用，原因通常不是设计得不好，而是设计系统和真实工作流脱节了。

首先，设计系统必须进入日常设计过程。

如果设计师每次做新页面仍然习惯自己重画组件，那再完整的组件库也没有意义。团队需要形成共识：已有组件优先复用，确实无法满足需求时再扩展。

其次，设计系统不能只有设计师参与。

一个按钮在设计稿里是一套规范，到了开发那里却写成另一套组件，最终还是会产生差异。

所以真正成熟的设计系统，应该让设计规范和开发组件尽可能对应。设计师知道组件怎么设计，开发知道组件怎么实现，产品经理也知道哪些交互规则已经形成标准。

此外，还需要建立明确的更新机制。

谁负责维护组件？新组件什么时候可以加入正式组件库？已有组件修改后如何通知团队？旧版本什么时候废弃？

这些看似是管理问题，实际上决定了设计系统能不能长期运转。

设计系统不是某个设计师的个人资产，而应该成为团队共同使用的一套基础设施。

这是最常见的误区。

很多团队花几周时间把按钮、输入框、导航、表格全部画了一遍，然后宣布“设计系统完成了”。

但如果没有设计原则、使用规范、交互规则和维护机制，这更准确地说只是一套组件库。

组件只是设计系统的组成部分，而不是全部。

另一个问题，是还没真正使用，就先做几百个组件。

结果很多组件永远用不上，真正需要的组件反而不够灵活。

设计系统应该从实际业务出发。

小团队可以先把颜色、字体和十几个最常用组件统一起来，已经能解决大量问题。等产品变复杂，再逐渐扩展页面模板、变量体系和更多业务组件。

比起一次建立一个“看起来很完整”的系统，持续迭代更重要。

设计系统最终服务的是整个产品，而不是设计部门。

如果产品经理不了解设计规则，需求里就可能不断创造新的特殊场景；如果开发没有参与，设计组件和代码组件就可能长期不一致。

最理想的状态，是设计、产品和开发共同理解这套规则。

不一定每个人都参与维护，但至少大家使用的是同一套语言。

并不是所有项目一开始都必须建立非常完整的设计系统。

如果只是一个只有几页的临时活动页面，做一套庞大的设计系统意义不大。

但如果产品页面越来越多，而且需要长期迭代，设计系统的价值就会明显增加。

多设计师团队尤其需要。因为团队人数增加后，不同人的设计习惯很容易造成风格不一致。有了统一组件和规范，才能让不同设计师做出的页面仍然像同一个产品。

B端产品和后台管理系统同样非常适合设计系统。它们通常包含大量表格、表单、弹窗、导航和业务状态，页面复用程度高，建立组件体系能显著减少重复工作。

多端产品也很有必要。一个品牌可能同时有Web、iOS、Android甚至桌面客户端，需要在不同平台之间保持统一，同时允许适当差异。

如果产品还涉及深浅色主题、多品牌切换或国际化，设计变量和Token的重要性会更高。

简单来说，产品越复杂、迭代周期越长、参与人员越多，设计系统带来的价值就越明显。

设计系统并不神秘，它本质上是在解决一个问题：如何让一个不断变化的产品，依然保持统一、高效和可维护。

小团队不需要一开始就追求完整，可以先统一颜色、字体和高频组件，再逐步建立变量、模板和使用规范。

真正好的设计系统，也不是拥有几百个漂亮组件，而是团队在下一次遇到相同问题时，不需要再重新设计一遍。