设计系统
1. 导读
很多团队第一次建设设计系统，是从"按钮不统一"开始的。
同一个产品里，有的按钮叫"确定"，有的叫"提交"，有的叫"保存"；有的弹窗可以关闭，有的不能；有的表单错误提示写在输入框下方，有的只在页面顶部显示；有的列表筛选器在左侧，有的在顶部；同一个品牌蓝在不同页面里有好几种色值。团队内部也开始出现奇怪的日常：设计师在 Figma 里翻十分钟才敢选按钮，前端工程师问"这次又是哪套表格"，产品经理每次评审都要重新解释"导出"和"下载"的区别。用户不会说"你们缺设计系统"，但他会发现客户管理叫"下载"，财务报表叫"导出报表"，权限审计又叫"生成文件"。1
于是团队做了一个组件库。
组件库很有用，但它还不是完整的设计系统。一个只有按钮、输入框、弹窗和表格的库，解决的是"有可复用零件"的问题。真正的设计系统还要回答：这些零件什么时候用，为什么这样用，文案怎么写，状态怎么覆盖，错误怎么恢复。再往后，还要说明移动端怎么适配，可访问性怎么保证，谁来维护，谁能贡献，版本如何升级，业务特殊场景如何处理。
组件库只是可复用的素材，但仅有组件库还不够。设计系统还要回答：每个组件在什么场景下使用，临时改版谁审批，旧版本什么时候下线，跨团队协作如何保持一致。只有素材没有使用规则，团队会越做越散；只有规则没有可用组件，团队又会慢到无法交付。
设计系统的价值，也不能简单写成"用了组件库就能提升体验"。组件复用可以提高一致性和效率，但如果组件本身质量差、场景不适配、贡献流程混乱、版本长期不更新，复用只会把问题放大。一个难用的表格组件，被全公司复用之后，难用也会规模化。
体验治理已经讨论了制度层面的问题；这里更具体地进入设计系统这项资产本身：它沉淀什么、怎样进入设计和代码、谁负责维护、如何观察价值。还要看一个更实际的问题：如何避免团队打开文档找不到"批量导入失败"这种真实状态，最后只好继续复制旧页面。
2. 核心问题
核心问题是：如何用系统化资产提升体验一致性和交付效率？
这里的关键词是"系统化资产"。设计系统不是一次性设计稿，也不是某个项目的 UI Kit。它是一套可复用、可维护、可演进的资产，服务于多个页面、多个产品、多个团队，甚至多个平台。
设计系统至少要解决四件事。
第一，减少重复劳动。每个项目都重新设计按钮、表单、筛选器、弹窗和空状态，会浪费大量时间。NN/g 对设计系统的定义强调，它是一套用于规模化管理设计的标准，通过可复用组件和模式减少冗余并建立共享语言。2
第二，提高体验一致性。用户在同一个产品或品牌中，不应每进入一个模块就重新学习一套规则。设计系统通过组件、模式、术语、内容规范和交互规则，降低学习成本。
第三，提升质量下限。设计系统可以把可访问性、状态覆盖、错误反馈、内容规则和响应式规则内建到组件和模式中，让项目团队不必每次从零检查。
第四，改善跨职能协作。设计师、前端工程师、产品经理、内容设计师和测试人员如果共享同一套组件命名、属性、状态和使用规则，就能减少误解。一个"Select"到底是下拉选择、组合框，还是搜索选择器？如果设计系统有清晰定义，就不必在每个项目里重新解释。
设计系统不只是"做组件"，还包括模式、令牌、文档、贡献、版本和治理。判断一个设计系统是否真的能提升质量和效率，不能只看它是否有一套看起来专业的文件。
3. 关键概念与定义
设计系统，是一套让团队在规模化产品中复用体验决策的工作系统。它既包含原则、组件、模式、设计令牌、内容规则、可访问性要求、代码实现和文档，也包含谁能贡献、谁来维护、旧版本如何下线、业务例外如何回收这些日常机制。
组件，是可复用的界面基本单元，例如按钮、输入框、复选框、标签、弹窗、表格、导航、日期选择器。组件像积木，解决的是局部界面元素的复用和一致。
模式，是针对常见任务或场景的组合方案，例如登录注册、搜索筛选、表单提交、错误恢复、批量操作、权限配置、空状态、数据导入、结账流程。模式比组件更接近用户任务。一个企业后台的"批量导入员工"模式，可能包含上传、模板下载、字段校验、错误列表、批量修复、重新提交和结果反馈。
设计令牌，是把颜色、字号、间距、圆角、阴影、动效时长等设计决策命名并结构化管理的变量。它让团队少问"这个蓝色到底复制哪一个色值"，多讨论"这里是品牌文字、成功图标，还是警告状态"。例如 color.text.brand、color.icon.success 这样的语义名称，会比散落在页面里的十几个十六进制色值更容易维护。W3C Design Tokens Community Group 的目标，是为设计工具和产品之间共享设计系统样式决策提供标准化基础。
设计原则，是设计系统背后的判断规则。它回答"为什么这样设计"。比如"关键操作优先清晰而非炫目""高风险操作必须可确认、可恢复""内容先解释后行动"。原则没有组件具体，但能指导新场景。
组件文档，是组件的说明书。它应包含用途、结构、状态、属性、内容规则、可访问性要求、使用示例、禁用场景、代码实现和常见错误。没有文档的组件，很容易被误用。
贡献机制，是团队向设计系统提交新增、修改、反馈和修复的流程。它决定设计系统能否随业务发展，而不是停留在第一版。
采用率，是设计系统在产品中被实际使用的程度。它可以通过设计稿、代码、组件引用或界面审计观察。但采用率不是最终目标，高采用率只说明系统被用起来，不自动说明体验变好。3
4. 概念边界与相近概念区别
组件库只是设计系统的起点。
组件库只是设计系统的一部分。按钮、输入框和表格能解决局部复用，但不能回答"什么时候用表格，什么时候用卡片""错误提示应该写什么""支付失败后如何恢复""复杂权限如何解释"。如果设计系统只有组件，没有原则、模式、内容、可访问性和治理，它很难支撑真实体验。
设计系统不等于品牌手册。
品牌手册关注品牌视觉、语气、标志、色彩和传播一致性。设计系统会继承品牌，但还要处理交互、任务、状态、代码、可访问性和产品使用。一个品牌蓝色很统一的产品，如果表单难填、错误难懂、状态缺失，体验仍然不好。
设计系统不等于前端框架。
前端框架关注技术实现和开发效率，设计系统关注设计决策、用户任务和跨团队一致。两者需要紧密配合，但不能互相替代。一个组件在代码里可复用，不代表它在体验上适合所有场景。
设计系统不等于设计规范文档。
文档是载体，不是系统。很多团队把规范写得很厚，但项目仍然不用。真正的设计系统要能进入设计工具、代码组件、评审流程、贡献机制和产品交付。它必须被用起来，而不是被存起来。
设计系统也不等于"所有产品必须一样"。
一致性不是统一到没有差异。不同产品、不同平台、不同场景可以有差异，但差异要有理由。比如移动端和桌面端的导航可以不同，高风险金融场景和普通内容浏览场景的确认强度也可以不同。设计系统要提供共同基础和例外机制，而不是消灭场景差异。
5. 方法、流程或框架
建设设计系统，可以从"审计、抽象、建立、试点、治理、度量"六步开始。
第一步，审计现有界面。
不要一开始就画全新组件。先收集现有产品里的按钮、表单、弹窗、表格、导航、空状态、错误提示、筛选器、图标、颜色、字体和间距。很多团队在审计时会惊讶地发现，同一个"主按钮"可能有十几种样式，同一个"错误提示"有五六种写法。审计的价值，是让混乱可见。4
第二步，抽象组件和模式。
组件解决局部元素，模式解决任务结构。比如表单字段、按钮、提示是组件；"提交申请并处理错误"是模式。对于企业后台来说，批量操作、数据导入、审批流、权限配置、复杂筛选往往比单个按钮更重要。如果只抽象组件，不抽象模式，团队仍会在复杂任务上各做各的。
第三步，建立设计令牌和基础规范。
颜色、字号、间距、圆角、阴影、层级、动效等基础样式应尽量令牌化。令牌不是为了让文件显得更专业，而是为了减少"设计稿一套、代码一套、移动端又一套"的漂移。比如品牌主色调整时，如果所有产品都使用语义令牌，团队可以先判断哪些地方是品牌强调、哪些地方是状态反馈、哪些地方是链接文字，再决定如何同步；如果每个页面都写死色值，调整会变成漫长搜索、替换和复查。
第四步，建设文档和代码实现。
设计系统必须同时服务设计和开发。设计稿里的组件、代码里的组件、文档里的规则要尽量同步。一个设计师使用的卡片组件，如果前端没有对应实现，交付时仍会返工；一个前端组件如果没有内容和状态规则，也容易被误用。
第五步，选择试点产品。
不要试图一次覆盖全公司。更现实的做法是选一个高频、高痛点、跨团队受益明显的场景试点，比如表单、数据表格、导航、筛选器或空状态。试点能暴露组件质量、文档可用性、贡献流程和团队协作问题。
第六步，建立贡献、版本和治理。
设计系统会持续演化。业务团队会遇到新场景，前端会发现技术问题，内容团队会补充文案规则，可访问性检查会提出修复需求。没有贡献机制，团队会绕过系统；没有版本机制，更新会造成混乱；没有治理机制，系统会膨胀成重复组件集合。
设计系统不是一次交付完就封存的规范，而是一项长期运营的内部服务。它有使用者：设计师、工程师、产品经理、内容设计师、测试人员和业务团队。既然是服务，就需要路线图、反馈、维护、指标和支持机制。5
6. 实际工作场景
在多产品企业中，设计系统常常从一致性问题开始。比如一家企业软件公司有客户管理、订单管理、财务、权限、报表多个模块。用户在客户管理里用顶部筛选器，在报表里用左侧筛选器，在财务里筛选条件又藏在弹窗里。同样是"导出"，有的页面叫"下载"，有的叫"导出报表"，有的叫"生成文件"。用户学会一个模块，并不能迁移到另一个模块。设计系统在这里要解决的不是"统一好看"，而是让相同任务有相同语言和相似路径。
在快速增长的创业公司中，设计系统常常从效率问题开始。产品线扩张很快，每个版本都要新页面，设计师和前端总在重复做类似东西。此时设计系统可以先从高频组件和模式开始：按钮、输入、表单、反馈、导航、空状态、列表、详情页、筛选器。不要一开始追求"大而全"，而要先让团队在真实项目里节省时间。
在公共服务和政务场景中，设计系统还承担可访问性和服务一致性任务。GOV.UK Design System 和 USWDS 都展示了公共部门如何通过共享组件、模式和指南支持多团队服务建设。 启发是：设计系统不是为了让设计团队省事，而是让不同服务团队能以更一致、更可访问的方式服务公众。
在企业后台中，设计系统不能只关注视觉组件。最有价值的往往是复杂模式：表格密度、批量操作、权限提示、审批状态、数据导入、异常恢复、审计记录、帮助提示。一个后台系统如果每个团队都重新设计"批量导入"，用户就会反复学习；如果设计系统沉淀了导入模式，用户、设计师和工程师都会受益。
在 AI 产品中，设计系统会开始承载新的内容：提示词模式、置信度表达、引用来源、人工接管、错误恢复、用户反馈、模型限制说明。Atlassian 近年公开讨论设计系统在 AI 语境中的演化，把设计系统从组件资产推进到设计意图和上下文能力。 这类资料是企业博客，不能作为普适趋势唯一证据，但它提醒我们：AI 时代的设计系统可能不只是 UI 复用，还会影响 AI 生成界面、代码和内容时的上下文质量。
7. 案例
GOV.UK Design System 是一个高可信案例。它为英国公共服务团队提供样式、组件和模式，支持服务团队复用 GOV.UK 的设计基础。 从治理角度看，它是公共服务共享标准；从设计系统角度看，它展示了设计系统如何把组件、模式、内容和服务实践结合起来。6
U.S. Web Design System 是另一个公共部门案例。它提供美国联邦数字服务所需的组件、模板、设计原则和可访问性相关资料。 这里用它说明可访问性和跨机构复用如何进入设计系统，而不是用它证明商业收益。
IBM Carbon Design System 和 Salesforce Lightning Design System 是企业级设计系统的代表。Google Material Design 和 Microsoft Fluent 则展示了平台级设计系统如何组织组件和规范。
阅读这些资料时，可以把注意力放在复杂场景如何被系统化：表格如何处理密度和批量操作，表单如何处理错误，组件如何定义可访问性，设计令牌如何让多端保持一致。这些资料多数是官方规范，不是商业成效研究。它们能证明这些组织这样建设系统，不能证明采用后必然获得某项收益。
GitLab 关于衡量设计系统价值的资料可用于价值度量讨论。GitLab 曾公开讨论如何从一致性、效率、质量、SUS、JTBD、UX Scorecards 等角度衡量设计系统价值。 这个案例的价值在于展示设计系统可以被度量，从一致性、效率、质量和 SUS 等角度建立追踪。
Shopify Polaris 可作为电商平台生态中的设计系统案例，其中的组件、模式和内容规范说明了平台一致性的价值。
8. 数据、指标或衡量方式
设计系统的价值通常不宜直接写成"上线后产生多少 ROI"。更稳妥的做法，是观察它是否减少了重复定义、减少了返工、降低了缺陷复发，让相同任务在不同模块里变得更稳定，并让团队愿意持续贡献和修复。
效率可以从返工和交接中观察。比如企业后台里的报销列表、客户列表、审批列表和审计日志，都要排序、批量选择、固定表头、空状态、导出状态和部分失败提示。过去每个团队都重新做一套，设计评审反复讨论列宽、筛选器和批量操作；设计系统上线后，如果这些列表页开始使用同一套表格模式，交接会更快，遗漏状态也会减少。但这只能说明效率改善的可能证据，还需要记录时间窗口、项目类型和其他变量。7
质量可以从缺陷和状态覆盖中观察。一个上传组件如果内建了文件格式说明、上传中、上传失败、部分成功、重新上传、键盘焦点和屏幕阅读器标签，项目团队就不必每次临时补这些状态。可访问性通过率、错误状态覆盖率和问题复发率都能提供线索，但它们仍不是完整用户体验结论；检查通过不等于所有用户都体验良好，仍需要真实用户测试。
一致性可以从组件、令牌和术语中观察。组件采用率、设计令牌覆盖率、术语一致性、跨产品模式一致性都能说明系统是否进入真实产品。它们也有局限：高采用率不代表好体验。如果一个不适合后台批量操作的轻量表格被大量使用，问题也会被大量复制。
采用和贡献可以看系统是否还"活着"：哪些团队在用，哪些组件没人用，哪些组件经常被改，外部团队提交的问题多久被处理，废弃组件是否真的从产品中退出。一个长期无人贡献、无人反馈、无人维护的系统，很快会和真实产品脱节。
业务间接指标包括客服咨询、培训成本、任务成功率、完成时间、错误率、用户满意度、SUS 等。但这些指标离设计系统更远，不能单独归因。比如任务成功率上升，可能和流程改造、文案优化、培训变化、产品策略有关，不能只归因于组件库。
因此，设计系统度量最稳妥的方式，是建立证据链：设计系统做了什么，哪些团队采用了，哪些重复工作减少了，哪些质量问题下降了，哪些用户任务可能因此改善。证据链越完整，管理者越容易理解价值；边界越清楚，结论越可信。
9. 常见误区
第一个误区，是把设计系统做成组件数量竞赛。
组件越多，维护成本越高。一个没人用、重复、质量不稳定的组件库，只会制造更多选择困难。设计系统应优先解决高频和高价值问题。
第二个误区，是只做视觉，不做状态和行为。
按钮正常状态很好看，但禁用、加载、错误、悬停、焦点、键盘操作、屏幕阅读器语义都没定义，真实产品中仍会出问题。组件必须覆盖状态和行为。
第三个误区，是忽略内容规范。
很多体验不一致来自文案，而不是视觉。按钮叫"确定"还是"提交申请"，错误提示写"失败"还是"身份证号格式不正确，请输入 18 位号码"，会直接影响用户理解。
第四个误区，是设计和代码不同步。
设计组件改了，代码没改；代码组件新增了，设计不知道。时间久了，团队会失去信任，设计系统变成两套系统。
第五个误区，是没有贡献机制。
业务场景变了，团队找不到贡献入口，只好自己改。等到多个团队都自己改，系统就被架空。
第六个误区，是把采用率当成体验质量。
采用率高只能说明被使用。它不说明组件是否适合任务，也不说明用户是否更容易完成目标。设计系统仍需要可用性、可访问性和真实任务验证。
第七个误区，是从第一天就做"大而全"。
完整系统需要时间。更好的策略通常是先从高频、高痛点、高复用场景开始，在真实项目中验证，再逐步扩展。
10. 小结
组件库是一盒零件，设计系统还要说明零件何时可用、坏了谁修、例外怎么回收、设计工具和代码如何同步。它把设计原则、组件、模式、设计令牌、内容规范、可访问性、代码实现、文档、贡献和治理连接成一项长期资产。8
它的价值主要体现在一致性、效率、质量和组织协作上。对多产品、多团队、长期迭代的组织来说，设计系统可以减少重复劳动，提高体验下限，让团队把精力从重复画按钮转向更复杂的用户问题。
但设计系统不是万能解药。组件复用不必然等于好体验，采用率也不必然等于用户价值。设计系统必须被维护、被度量、被治理，并且持续贴近真实业务场景。
体验治理提供了制度层面的基础，设计系统是治理最重要的工具之一。设计系统能否成功，最终仍取决于人、团队和组织机制。
11. 延伸阅读
NN/g 的 Design Systems 101 是理解设计系统定义和边界的入口，可用来核对规模化复用、维护投入和短期 ROI 限制等基础判断。它不能替任何企业证明"只要建系统就会产生固定收益"。
GOV.UK Design System 和 U.S. Web Design System 展示了公共服务中的设计系统如何服务一致性、复用和可访问性。
Google Material Design、Microsoft Fluent 和 IBM Carbon 可作为平台级、企业级设计系统参考。Atlassian Design System 和 Salesforce Lightning Design System 展示了复杂产品生态中的组件、模式和规范实践。
W3C Design Tokens Community Group 适合理解设计令牌标准化方向。正式出版前需复核其规范状态和最新资料。
GitLab 的 Measuring the value of our design system 适合理解设计系统价值度量的企业实践。阅读时要注意，它是企业官方资料，不应外推为普适收益。
案例：一家金融科技公司的设计系统"冷启动"
一家做企业支付的中型金融科技公司——三百人，两条产品线——开始建设计系统。和大多数团队一样，他们的起点是"按钮不统一"。设计师林薇花了两个月画了一套完整的组件库：按钮、表单、弹窗、表格、导航，全部配上文档和代码示例。
发到前端团队的三天后，她在 Git 仓库里看到了一个让她沉默的数字：零引用。
前端负责人杨哥在午饭时跟她说了一句实话："画得好。但我这边线上有六十三处按钮——你让我怎么改？一个一个替换？项目排期里根本没有这个时间。"
林薇没有催。她做了一件事：她找到过去三个月里产生过"按钮样式 bug"的工单——颜色不一致、大小不对、状态缺失——总共十四张。她把十四张工单打印出来，贴在杨哥旁边的白板上。每张工单旁边标了一条：解决这个需要几分钟。平均耗时四十五分钟。
"你这些 bug 下一次还会再出，"林薇说，"你十四张工单花掉的时间，够你换掉至少一半的按钮了。"
杨哥看了三十秒。第二天，他在迭代计划里加了一条"组件替换：按钮"。没有要求全换——先换支付流程里的按钮，六个页面，一百二十分钟的工作量。两个迭代后，支付流程里没有再出现过按钮样式 bug。
林薇的数据追踪到了第六个月：按钮组件的采用率从零涨到了百分之七十一。在那之后，表单、弹窗、表格的替换速度全部加快——不是因为按钮成功，而是因为前端的同事们发现：用组件库写了三个月代码之后，他们不再需要在排期会上讨论"这个按钮的 hover 态是什么颜色了"。
注释 1 NN/g, Design Systems 101。方法资料，不支撑具体商业成效。 🔗 https://www.nngroup.com/articles/design-systems-101/
2 W3C Design Tokens Community Group。社区组资料，正式规范状态需复核。 🔗 https://www.w3.org/community/design-tokens/
3 GOV.UK Design System / U.S. Web Design System。🔗 https://design-system.service.gov.uk/
4 Atlassian Design System。设计系统在 AI 语境中从组件到设计意图和上下文能力的演化。 🔗 https://atlassian.design/
5 Google Material Design / Microsoft Fluent / IBM Carbon / Salesforce Lightning。 🔗 https://m3.material.io/
6 GitLab, Measuring the value of our design system。🔗 https://handbook.gitlab.com/handbook/product/ux/how-we-work/measuring-the-value-of-our-design-system/
7 WCAG 2.2。详见第 19 章。 🔗 https://www.w3.org/TR/WCAG22/
8 Shopify Polaris。电商平台生态设计系统参考。 🔗 https://polaris.shopify.com/