Design Systems

This entry has no runnable specimen; the illustration is an editorial sketch of how one central definition relates to many consumers, and represents no real design system. Before adopting it in an organisation, settle the maintainers and the process for accepting and retiring components.

{
  "values": [
    "A shared standard beats everyone remaking the same thing",
    "Design decisions should be reusable and traceable"
  ],
  "tension": "Between the consistency that central definition brings and the real differences between products",
  "questions": [
    "Who maintains this component, and what happens when maintenance stops?",
    "Which consumers does changing it reach?",
    "What are the recurring exceptions telling us?"
  ]
}

{
  "id": "design-systems",
  "type": "philosophy",
  "name": {
    "zh": "设计系统",
    "en": "Design Systems"
  },
  "aliases": [
    "Design System",
    "Component Library",
    "组件体系",
    "设计体系"
  ],
  "granularity": "experience",
  "intents": [
    "organize-content",
    "reduce-complexity"
  ],
  "tags": [
    "components",
    "tokens",
    "standards",
    "reuse",
    "scale"
  ],
  "definition": "Changing the unit of design work from one page to one shared set of standards: components, tokens, patterns, and writing rules are defined and maintained centrally and used everywhere instead of being remade, so that consistency survives growth.",
  "boundary": "A design system is not a component library: the library is the deliverable, while the system also includes the agreements that decide why those components exist, how they change, and who maintains them. Having a Figma file or an npm package does not mean having a design system. Nor is it a one-off project — its entire value comes from continuous maintenance, and one that stops being maintained becomes an obstacle, because it is still in use everywhere while no longer reflecting what is needed. This entry covers the way of working; a separate candidate row of the same name refers to a particular book about design systems, which is a reference rather than the same concept.",
  "signature": [
    "Components and tokens have one source of definition that is referenced rather than copied",
    "There is an explicit process for proposing, reviewing, and retiring components",
    "There are named maintainers and a change history that can be looked up"
  ],
  "when": [
    "The same interface elements recur across several products or teams",
    "Growth is fast enough that keeping consistency page by page is no longer realistic",
    "The organisation is willing to fund continuous maintenance rather than a single effort"
  ],
  "when_not": [
    "The product is still exploring its shape, where freezing components early locks the direction",
    "A component library exists with no maintainer, no process, and no way to retire anything",
    "Maintenance has stopped yet everyone is still required to use it, so it obstructs rather than supports"
  ],
  "tradeoff": "Central definition turns consistency and the propagation of change into one-time work and lifts the conversation from what this button looks like to what our buttons should look like; the cost is that every exception now has a price, and the system itself needs sustained maintenance — once that stops, it turns from infrastructure into a burden.",
  "comparison": {
    "focus": "Moving the unit of design work from the page to a shared standard",
    "mechanism": "Defining components, tokens, and patterns centrally, referenced everywhere and maintained continuously",
    "cost": "Exceptions become expensive and it depends on sustained maintenance"
  },
  "sources": [
    {
      "id": "designsystems-nng",
      "title": "NN/g · Design Systems 101",
      "url": "https://www.nngroup.com/articles/design-systems-101/",
      "claim": "The article defines a design system as a complete set of standards intended to manage design at scale using reusable components and patterns, reducing redundancy and creating a shared language and visual consistency across channels, and explains that the need arises from the growing number and speed of interfaces. This entry takes its definition and motivation from it.",
      "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": "The design system states on its home page that it is used to design services with GOV.UK styles, components, and patterns so that government services are consistent with GOV.UK, and so that teams can learn from the research and experience of other service teams and avoid repeating work that has already been done; it also publishes component lifecycle statuses such as Trial and Stable alongside release notes. This entry takes the shared-standard and continuous-maintenance points from it.",
      "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": "Consistency has to hold across several teams and products",
      "reason": "A design system is the concrete mechanism that turns consistency from a per-case judgement into a single definition.",
      "basis": "editorial"
    },
    {
      "target": "systems-thinking",
      "kind": "composes_with",
      "condition": "It has to be judged which consumers one change will reach",
      "reason": "Central definition widens the blast radius of a change, so the dependencies have to be seen before anything moves.",
      "basis": "editorial"
    },
    {
      "target": "inclusive-design",
      "kind": "composes_with",
      "condition": "Accessibility requirements need to take effect for every consumer",
      "reason": "Building accessibility into the component itself is more reliable and easier to verify than asking every team to implement it separately.",
      "basis": "editorial"
    },
    {
      "target": "participatory-design",
      "kind": "composes_with",
      "condition": "The system’s users are also its contributors",
      "reason": "If proposing and retiring components is decided by the central team alone, the system drifts away from what the products actually need.",
      "basis": "editorial"
    }
  ],
  "rules": [
    {
      "when": "An organisation decides to build a design system",
      "instruction": "Settle first who maintains it over time and by what process components are accepted and retired; without both, ship a component library and do not claim to have a design system.",
      "strength": "must",
      "basis": "editorial"
    },
    {
      "when": "A product genuinely needs to depart from the system",
      "instruction": "Provide a recorded path for exceptions and review them regularly; a recurring exception usually means the system itself needs to change.",
      "strength": "recommend",
      "basis": "editorial"
    }
  ],
  "philosophy": {
    "values": [
      "A shared standard beats everyone remaking the same thing",
      "Design decisions should be reusable and traceable"
    ],
    "tension": "Between the consistency that central definition brings and the real differences between products",
    "questions": [
      "Who maintains this component, and what happens when maintenance stops?",
      "Which consumers does changing it reach?",
      "What are the recurring exceptions telling us?"
    ]
  },
  "demo": null,
  "version": "0.1.0",
  "editorialStatus": "drafted",
  "requirements": [],
  "demoCapabilities": [],
  "implementationNote": "This entry has no runnable specimen; the illustration is an editorial sketch of how one central definition relates to many consumers, and represents no real design system. Before adopting it in an organisation, settle the maintainers and the process for accepting and retiring components.",
  "image": {
    "src": "/images/design-systems.webp",
    "alt": "A sketch: at the centre a defined set of fictional components — a button, an input, a card, and a few color tokens; thin lines run from them out to three different fictional product interfaces around the edge, each of which contains the same components."
  },
  "searchTerms": [
    "组件",
    "设计令牌",
    "规范",
    "复用",
    "规模化"
  ]
}