设计系统

本词条尚无可操作示例；插画为编辑示意，展示中心定义与多处引用的关系，不代表任何真实的设计系统。应用到组织之前仍须先确定维护者与组件的接受、淘汰流程。

{
  "values": [
    "共享的标准优于各自重做",
    "设计决定应当可被复用与追溯"
  ],
  "tension": "集中带来的一致性与各产品真实差异之间",
  "questions": [
    "这个组件由谁维护？停止维护后会怎样？",
    "改动它会影响到哪些使用方？",
    "反复出现的例外在告诉我们什么？"
  ]
}

{
  "id": "design-systems",
  "type": "philosophy",
  "name": {
    "zh": "设计系统",
    "en": "Design Systems"
  },
  "aliases": [
    "Design System",
    "Component Library",
    "组件体系",
    "设计体系"
  ],
  "granularity": "experience",
  "intents": [
    "organize-content",
    "reduce-complexity"
  ],
  "tags": [
    "组件",
    "设计令牌",
    "规范",
    "复用",
    "规模化"
  ],
  "definition": "把设计工作的单位从\"一个页面\"换成\"一套共享的标准\"：组件、令牌、模式与写作规则被集中定义与维护，各处使用它们而不是各自重做，从而在规模变大时仍保持一致。",
  "boundary": "设计系统不等于组件库：组件库是交付物，设计系统还包括决定这些组件为何存在、如何演进、由谁维护的一整套约定。有一个 Figma 文件或一个 npm 包，并不意味着有设计系统。它也不是一次性项目——它的价值全部来自持续维护，停止维护的设计系统会变成阻碍，因为各处仍在使用它，却不再能反映真实需要。本词条讨论的是这一工作方式本身；与之同名的另一类候选条目指的是关于设计系统的具体著作，那是参考文献而不是同一个概念。",
  "signature": [
    "组件与令牌有唯一的定义来源，各处引用而不是复制",
    "存在关于如何提议、评审与淘汰组件的明确流程",
    "有具名的维护者与可查的变更记录"
  ],
  "when": [
    "同一组界面要素在多个产品或多个团队中反复出现",
    "规模增长快到逐页维护一致性已经不现实",
    "组织愿意为持续维护投入固定的人力，而不只是做一次"
  ],
  "when_not": [
    "产品还在快速探索形态，过早固化组件会锁死方向",
    "只做了组件库却没有维护者、流程与淘汰机制",
    "系统停止维护后各处仍被要求使用，它变成了阻碍而非基础"
  ],
  "tradeoff": "集中定义把一致性与修改的传播变成一次性的工作，也把讨论从\"这个按钮什么样\"抬升到\"我们的按钮应该什么样\"；代价是它给每一次例外都加上了成本，而且它自身需要长期的维护投入——这份投入一旦停止，系统就从基础设施变成负担。",
  "comparison": {
    "focus": "把设计工作的单位从页面换成共享标准",
    "mechanism": "集中定义组件、令牌与模式，各处引用并持续维护",
    "cost": "例外变得昂贵，且依赖长期的维护投入"
  },
  "sources": [
    {
      "id": "designsystems-nng",
      "title": "NN/g · Design Systems 101",
      "url": "https://www.nngroup.com/articles/design-systems-101/",
      "claim": "该文把设计系统定义为一套用于在规模上管理设计的完整标准，借助可复用的组件与模式实现，目的是减少冗余、建立共同语言并在各渠道间保持视觉一致；文中还说明这一需求来自界面数量与生产速度的增长。本词条的定义与动机据此转述。",
      "checkedAt": "2026-09-16",
      "archive": {
        "lookupUrl": "https://web.archive.org/web/20260916*/https://www.nngroup.com/articles/design-systems-101/",
        "status": "pending",
        "checkedAt": "2026-09-16T17:41:09.727Z",
        "error": "status-request-failed",
        "jobId": "spn2-24ab2e786b40bfc8cd3d51c46cabc90c2a6c080a"
      }
    },
    {
      "id": "designsystems-govuk",
      "title": "GOV.UK Design System",
      "url": "https://design-system.service.gov.uk/",
      "claim": "该设计系统在首页说明其用途：用 GOV.UK 的样式、组件与模式来设计服务，使各政府服务与 GOV.UK 保持一致，并让团队\"借鉴其他服务团队的研究与经验，避免重复已经做过的工作\"；它同时公开组件的生命周期状态（例如 Trial 与 Stable）与版本发布记录。本词条关于\"共享标准\"与\"持续维护\"的说法据此转述。",
      "checkedAt": "2026-09-16",
      "archive": {
        "lookupUrl": "https://web.archive.org/web/20260916*/https://design-system.service.gov.uk/",
        "status": "pending",
        "checkedAt": "2026-09-16T17:41:31.878Z",
        "error": "status-request-failed",
        "jobId": "spn2-718c6450aa41af704ceccf7cb39be7ffff9e026c"
      }
    }
  ],
  "relations": [
    {
      "target": "consistency",
      "kind": "realized_by",
      "condition": "一致性需要在多个团队与产品之间被维持",
      "reason": "设计系统是把一致性从每次判断变成一次定义的具体机制。",
      "basis": "editorial"
    },
    {
      "target": "systems-thinking",
      "kind": "composes_with",
      "condition": "需要判断一处改动会波及哪些使用方",
      "reason": "集中定义让改动的传播范围变大，因此必须先看清依赖关系再动手。",
      "basis": "editorial"
    },
    {
      "target": "inclusive-design",
      "kind": "composes_with",
      "condition": "无障碍要求需要在所有使用方生效",
      "reason": "把无障碍做进组件本身，比要求每个团队各自实现更可靠，也更容易被验证。",
      "basis": "editorial"
    },
    {
      "target": "participatory-design",
      "kind": "composes_with",
      "condition": "系统的使用者同时也是它的贡献者",
      "reason": "组件的提议与淘汰若只由中心团队决定，系统会逐渐偏离各产品的真实需要。",
      "basis": "editorial"
    }
  ],
  "rules": [
    {
      "when": "组织决定建立设计系统",
      "instruction": "先确定谁长期维护它、按什么流程接受与淘汰组件；没有这两项时只交付组件库，不要宣称拥有设计系统。",
      "strength": "must",
      "basis": "editorial"
    },
    {
      "when": "某个产品确实需要偏离系统",
      "instruction": "提供一条记录在案的例外路径，并定期回看这些例外——反复出现的例外通常说明系统本身需要改。",
      "strength": "recommend",
      "basis": "editorial"
    }
  ],
  "philosophy": {
    "values": [
      "共享的标准优于各自重做",
      "设计决定应当可被复用与追溯"
    ],
    "tension": "集中带来的一致性与各产品真实差异之间",
    "questions": [
      "这个组件由谁维护？停止维护后会怎样？",
      "改动它会影响到哪些使用方？",
      "反复出现的例外在告诉我们什么？"
    ]
  },
  "demo": null,
  "version": "0.1.0",
  "editorialStatus": "drafted",
  "requirements": [],
  "demoCapabilities": [],
  "implementationNote": "本词条尚无可操作示例；插画为编辑示意，展示中心定义与多处引用的关系，不代表任何真实的设计系统。应用到组织之前仍须先确定维护者与组件的接受、淘汰流程。",
  "image": {
    "src": "/images/design-systems.webp",
    "alt": "一张示意图：画面中央是一组被定义好的虚构组件——按钮、输入框、卡片与几枚色块令牌；细线从它们分别连向四周三个不同的虚构产品界面，每个界面中都出现同样的组件。"
  },
  "searchTerms": [
    "components",
    "tokens",
    "standards",
    "reuse",
    "scale"
  ]
}