Design system operations — cross-system synthesis
Research snapshot: 2026-07-30. This comparison summarizes the factual system files in this folder. It does not prescribe a model or infer the contents of a future design system. The comparison is split into the initially requested systems and four added operational analogues for readability.
| Operating area | GitLab Pajamas (anchor) | Shopify Polaris | Atlassian Design System | IBM Carbon | Convergence and Pajamas difference |
|---|---|---|---|---|---|
| 1. Governance | Design System team owns Core; creating teams own Extended. The team classifies work, chooses support level, and must approve Core changes. | React-era Polaris team evaluated major proposals and reviewed a shared public PR process; React repo is now archived after the Web Components transition. | Central Design System team; contributions currently internal-only and mostly limited to fixes/small enhancements; fortnightly internal critique. | Core team/maintainers plus open community; steering oversight is publicly described; Figma Guild is a governance partner; CLA required. | All have a central team and review point. Pajamas is distinctive in publicly assigning ownership by Core vs Extended and explicitly scaling the team’s support level per contribution. |
| 2. Component lifecycle | Flexible Define → Design → Build → Document, plus separate integration. Readiness is tracked across design/code/docs/accessibility; Extended work can graduate to Core. | No public per-component maturity ladder in the React-era docs; minor/major contribution paths, beta package prereleases, deprecation warning in minor, removal in major. | Early Access → Beta → GA → Caution → Deprecated, with consumer guarantees. Public transition gates are limited. | Draft → Preview candidate → Preview → Stable, mapped to Discovery/Delivery/Launch and scale, with a detailed definition of done. | All distinguish emerging, supported, and deprecated work, but formalism varies. Pajamas differs by presenting lifecycle as synchronized work streams/layers rather than a public release-status ladder. Carbon has the most explicit stable gate; Atlassian has the clearest consumer status contract. |
| 3. Contribution | Issue/MR → Core/Extended classification → support level → Define/Design/Build/Document → approval/merge. External contributors can work in public code/docs but cannot directly edit internal Figma libraries. | React-era process: search issues, propose non-trivial work, PR with tests/lint/types/Storybook/Changeset/CLA, snapshot-test; major work uses a proposal. Now historical. | Internal-only; fixes and small enhancements accepted, major work coordinated with the team and may not be accepted. Icon workflow has specialized tools. | Open issue/template → triage → iterative guild/office-hours feedback → maintainer-reviewed PR/CLA; new components must follow PDLC and checklist. | All make work visible before substantial implementation and use review gates. Pajamas adds explicit classification and support negotiation; Carbon requires the broadest published new-component deliverables. |
| 4. Versioning and release | Unified repo; Changesets; semantic package releases and release notes; UI Kit review descriptions generate release notes. No fixed public cadence. | React-era SemVer + Changesets; automated Version Packages PR; next/beta prereleases; snapshot testing in Shopify; announcements. No fixed public cadence; repo archived. | Independent @atlaskit/* package versions and changelogs; phase guarantees constrain breaking changes; public announcements/migration guides. No single public cadence. | Semantic major lines plus frequent package/GitHub releases; release history, migration guides, deprecations, codemods. No universal cadence stated in cited pages. | All use package versions, changelogs, and migration communication; none of the cited systems promises one universal calendar cadence. Pajamas’ notable trait is unifying code/docs and using both code Changesets and generated Figma release notes. |
| 5. Documentation structure | Unified component page: definition, examples, anatomy, usage/variants/content, accessibility, related terms, code imports/props/defaults; linked component issues/MRs. | React page: purpose, live examples, typed props, deprecations, best practices, content, related components, accessibility, keyboard support. | Separate Usage, Examples, Code, and Changelog routes; release-phase warnings and page feedback. No public authoring template. | Formal Usage / Style / Code / Accessibility templates, with single/multi-variant versions; Storybook plus long-form site docs required. | All pair usage with implementation and accessibility. Pajamas emphasizes one unified page and contribution links; Carbon publishes the most explicit templates; Atlassian separates documentation by route. |
| 6. Naming and tokens | Constant/semantic/contextual token layers; DTCG JSON; detailed dot-path anatomy; generated --gl-, $gl-, and JS names; component: issue labels. | Semantic kebab-case CSS names with --p-; category/role/prominence/state ordering; legacy package generated format-specific variants. | Semantic dot names as foundation/property/modifier; token() maps to --ds-; lint rules enforce safe/current tokens; @atlaskit package scope. | Role-based Sass names with $; v11 color model [element]-[role]-[order]-[state]; component code must avoid un-tokenized magic values. | All use semantic, intent-based names and platform namespaces. Pajamas publishes the most granular general naming grammar and DTCG authoring model; the others emphasize shorter domain/role/state structures. |
| 7. Accessibility | WCAG AA target; MR review checklist; manual plus automated evaluation; component guidance; health status only after code readiness. | React-era WCAG 2.1 A/AA; Pa11y recommendation plus extensive manual checklist and component guidance; integration task-flow testing required. | API design and lint rules enforce semantics; component-specific guidance; feedback and legibility testing inform GA. Public universal test matrix is not exposed. | IBM checklist (WCAG AA, Section 508, European standards); AVT on every proposed code change; periodic manual tests; public matrix by state/keyboard/screen reader; required stable gate. | All embed accessibility in components, docs, and review rather than treating it as an end-only audit. Pajamas’ health model is explicit but Carbon publishes the strongest automated gate and test-status matrix. |
| 8. Audit/review cycle | Active Core component-health matrix audits design/code/docs/accessibility parity; findings create issues and deprecation work. No fixed public interval. | React-era continuous issues, PR gates, snapshot integration tests, accessibility backlog, deprecation-before-removal; no published periodic inventory. | Fortnightly internal critique, continuous lint drift detection, visible phase badges, migration campaigns/codemods, deprecation windows; no public periodic inventory. | Per-change AVT, per-latest-release accessibility status, periodic manual tests, definition-of-done gap assessment, post-launch success monitoring, central deprecations register. | All combine continuous controls with explicit deprecation. Pajamas differs by auditing cross-surface parity in one component-health matrix; Carbon has the clearest recurring accessibility/release checks; Atlassian relies heavily on tooling and migration campaigns. |
Additional operational analogues
| Operating area | GOV.UK Design System | GitHub Primer | Adobe Spectrum Web Components | Home Office Design System | Relationship to Pajamas |
|---|---|---|---|---|---|
| 1. Governance | GDS Design System team reviews proposals, agrees working arrangements, performs final review, and votes on publication; public roadmap and community principles distribute participation. | Design Infrastructure/Design Engineering maintain the system; feature teams incubate components with central, accessibility, and CODEOWNER review. | Adobe Design Engineering core team owns SWC; public planning uses objectives, workstreams, component plans, and milestones; outside contributions are accepted. | Cross-functional Working Group meets fortnightly, governs a Home Office extension of GOV.UK, and routes mature work upstream. | All retain a central approval point. Primer and Home Office most closely echo Pajamas’ distributed creation/central review, while Home Office makes the parent/extension relationship explicit. Pajamas alone publishes Core/Extended ownership plus four support levels. |
| 2. Component lifecycle | No universal named ladder: idea/discussion → useful-and-unique proposal → development/research → team vote → publication; experimental publication is still being explored. | Product labels Experimental/Ready/Deprecated; implementation maturity also uses Alpha/Beta/Stable. Feature-owned work must pass discoverability, design, docs, accessibility, and upstream-readiness stages. | Stable SemVer plus next-minor beta; deprecation uses identify → announce → yellow/red warnings → migration → major removal. No one per-component ladder. | No named ladder: discussion/evidence → Working Group review → issue/development → local publication/improvement → GOV.UK upstreaming when mature. Page-level research gaps show health. | Primer is closest to a formal graduation model; Home Office is closest to Pajamas’ Extended-to-Core path. Pajamas frames lifecycle as coordinated Define/Design/Build/Document work rather than consumer status alone. |
| 3. Contribution | Check existing work; propose with user need; central criteria review; kickoff defines scope/support; research and accessibility tests; final team vote. | Build first in a product context, collect evidence, then request upstreaming; design, accessibility, docs, tests, issue, PR, and CODEOWNER review. New components are mainly an internal GitHub path. | Issues and PRs use standard scaffold, Storybook, tests, README, accessibility, changelog, and maintainer review conventions. | Anyone opens a researched discussion, gathers community feedback, and takes it to the Working Group; ready work becomes an issue and can later go upstream to GOV.UK. | GOV.UK has the clearest public acceptance criteria; Primer and Home Office validate through real product use before central adoption. Pajamas makes central support negotiation more explicit than all four. |
| 4. Versioning and release | SemVer-major breaking GOV.UK Frontend releases; dated “What’s new,” GitHub notes, migrations, and roadmap; no promised fixed cadence. | Independently versioned implementations; Changesets and major/minor/patch release notes; major plus migration path for Ready-component breaks; no universal cadence. | SemVer from 1.0; regular patches; beta tag for next minor; advance notice and migration guide for majors; per-package changelogs. | No public unified SemVer policy or fixed cadence across GOV.UK, Home Office HTML/React, and NotGovUK layers; dated docs, GitHub, emails, and community updates communicate change. | Pajamas resembles Primer/SWC in package automation and GOV.UK in public change communication. Its unified repo plus generated Figma release notes remain distinctive. |
| 5. Documentation structure | Definition, guidance, examples/variants, HTML and Nunjucks, research context, and discussion links; publication reviews design/content/code/guidance together. | Overview/Guidelines/Accessibility with implementation readiness badges, Storybook/source/Figma links, examples, props, and related items; docs have an approval checklist. | Source README template: Overview/Usage/Anatomy/Options/States/Behaviors/Accessibility; examples must show accessible composition; rendered site plus Storybook/changelog. | Purpose, when/how to use, variants, writing, accessibility, research, HTML/React, and “Help us improve” evidence gaps. | All converge on usage + implementation + accessibility. Home Office’s visible evidence gaps resemble Pajamas’ health concerns; SWC publishes the strongest page template. Pajamas’ unified page and issue/MR linkage remain unusually integrated. |
| 6. Naming and tokens | BEM with reserved govuk-; local app- or departmental prefixes; Sass foundations but no cited DTCG token grammar. | Base/functional/component-pattern token tiers; compositional grammar rendered as CSS hyphens or JS dots; linted primitives and accessible theme modes. | Kebab-case packages, Spectrum-aligned names, sp- elements, --spectrum- global/semantic/component tokens; legacy Vars deprecated for Core tokens. | hods- BEM extension classes coexist with inherited govuk-; no published general token taxonomy. | Namespace boundaries converge. Primer is closest to Pajamas’ layered semantic token model, but Pajamas publishes a more granular DTCG anatomy and generated cross-platform prefixes. |
| 7. Accessibility | WCAG AA strategy; disabled-user research; deploy-time jest-axe/axe-core plus manual browser/AT tests; publication gate; statement reviewed every six months and external audits. | Explicit upstream gate: keyboard/screen-reader baseline, axe, internal checkpoints; component pages separate built-in behavior from consumer obligations. | Accessible-by-default claim; automated tests, snapshots, manual PR expectations, dev-mode diagnostics, and accessible example requirements. | Versioned WCAG 2.2 AA standard; accessibility member in Working Group; GOV.UK criteria; page-level guidance/research gaps. Public site audit evidence is historical. | All enforce accessibility before central adoption. GOV.UK has the clearest published recurring statement review; Primer mirrors Pajamas’ readiness-gate approach; Pajamas uniquely ties health status to cross-surface readiness. |
| 8. Audit/review cycle | Deploy-time automation, manual component testing, six-month accessibility-statement review, external audits, roadmap/release maintenance; no universal inventory interval. | Continuous product-use evidence, upstream review, CODEOWNERS/tests, status labels, deprecations, and migrations; no universal periodic inventory. | Continuous PR/test/dev-mode controls; internal/community deprecation discovery; public workstreams/component plans; no fixed library audit interval. | Fortnightly Working Group review; component research gaps and discussions remain visible; no fixed full-library audit/deprecation interval. | Mature systems favor continuous controls over annual inventories. Home Office’s fortnightly forum and GOV.UK’s six-month accessibility review are the clearest rhythms; Pajamas’ component-health matrix remains the clearest cross-surface drift audit. |
Where the systems converge
- A central design-system team or maintainer group retains approval authority for system-level changes even when contribution is distributed.
- Significant additions begin with a visible issue or proposal and are evaluated for reuse/system value before implementation.
- Several systems validate shared components in real product or service use before central adoption: Primer incubates with feature teams, Home Office matures work locally before GOV.UK upstreaming, and Pajamas allows Extended work to graduate to Core.
- Mature assets are expected to align design, code, documentation, and accessibility.
- Semantic tokens encode intended use rather than raw visual values and are distributed through platform-specific names.
- Accessibility is enforced through a combination of component defaults, contribution checks, documentation, automated testing/tooling, and manual evaluation.
- Deprecation is communicated before removal and is paired with a replacement or migration path.
- Releases are communicated through package versions and changelogs; larger changes add migration guides, announcements, codemods, or adoption support.
- None of the reviewed public operating material establishes one universal audit or release interval across every design-system asset.
- GOV.UK, Primer, Home Office, and Pajamas all distinguish central ownership from distributed contribution, but only Pajamas publishes both a formal Core/Extended ownership split and a graduated central-support model.
Where Pajamas differs
- Layered ownership is explicit. Core is Design System team-owned; Extended is creator/team-owned and can be a path toward Core.
- Support is negotiated explicitly. The Design System team records one of four contribution support levels rather than applying the same service model to every change.
- Lifecycle describes coordinated work, not only consumer maturity. Define, Design, Build, and Document can overlap, while product integration is tracked separately.
- Cross-surface parity is an audit object. The component-health work evaluates design, code, documentation, and accessibility together and records parity gaps.
- Contribution and adoption remain distinct. A component can exist in the system without being fully integrated throughout the GitLab product, and complex adoption requires a migration plan.