---
title: "DesignOps"
slug: designops
category: product
term_status: established
evidence_status: partially_verified
summary: "DesignOps (design operations) is the work of running a design organisation as a dependable system: the people, processes, tools and shared design system that let designers do their craft and ship consistent, accessible products at scale."
audience: [Beginners, DesignOps and design program managers, Design leaders, Design-system teams, Front-end engineers, Product and engineering leaders]
last_verified: 2026-10-23
key_takeaways:
  - "DesignOps has a widely cited definition (Nielsen Norman Group: people, processes and craft, orchestrated to amplify design's value at scale), but each organisation chooses a different scope; start from measured pain, not from a menu."
  - "Two halves need running: the design team (intake, capacity, critique, hiring, career paths) and the design system run as a product (tokens, components, releases, contribution, adoption)."
  - "Design tokens now have a stable vendor-neutral format (DTCG 2025.10), but it is a W3C Community Group report, not a W3C standard, and tool support is still catching up."
  - "Build accessibility into tokens and components with automated gates, then test with people: axe-based checks find many issues but cannot cover most of what WCAG asks."
  - "Measure adoption and health with formulas you can defend (coverage, detach rate, time to adopt a release, request cycle time), and treat a high detach rate as a question for teams, not a verdict."
  - "Do not create a DesignOps team or a custom design system before the need exists: a few designers on one product need habits and an off-the-shelf system, not a department."
related: [researchops, productops, contentops, agileops, webops, mobileops, devexops, releaseops]
---

## What DesignOps is

### In 30 seconds

**DesignOps (design operations) is the work of running a design organisation as a dependable system.** It looks after the people
who design (how they are organised, hired, reviewed and grown), the way design work flows (intake, prioritisation, critique,
handoff to engineering), and the shared craft infrastructure, above all the **design system**: tokens, components, guidance and
the process for changing them. The goal is that designers spend their time designing and that users get consistent, accessible
products, however many teams and products there are.

Nielsen Norman Group's definition is the one most practitioners quote: DesignOps is "the orchestration and optimization of people,
processes, and craft in order to amplify design's value and impact at scale".[^nng-101]

Written for beginners, DesignOps and design program managers, design leaders, design-system teams and the front-end engineers who
consume their work, and for product and engineering leaders deciding whether to invest. Sources were last verified on
**2026-10-23**.

::: note Scope of this page
This page covers **two halves**: running the design *team* and running the design *system* as a product. User-research logistics
(participants, consent, repositories) belong to [ResearchOps](../researchops/); the words inside components belong to
[ContentOps](../contentops/). The split is explained [below](#term-status-and-the-researchops-question).
:::

### At a glance

| Question | Short answer |
|---|---|
| Goal | Designers spend their time on design; products look and behave consistently and accessibly across teams |
| Primary users | Designers, design managers, design-system teams, front-end and mobile engineers, product managers |
| In scope | Team structure and roles, hiring and career frameworks, intake and capacity, critique and review rituals, design-to-engineering handoff, design tooling and libraries, design tokens and components, contribution and release governance, accessibility built into the system, measurement |
| Handed off | Research operations → [ResearchOps](../researchops/); product analytics and planning → [ProductOps](../productops/); words and content models → [ContentOps](../contentops/); release pipelines → [ReleaseOps](../releaseops/) and [DevOps](../devops/) |
| Prerequisites | None. Some front-end vocabulary (CSS variables, packages, pull requests) helps for the system half |
| Key outputs | Team charter, intake and capacity plan, critique cadence, career framework, design system (tokens, components, docs), release notes, contribution criteria, scorecard |
| Minimum vocabulary | **Design system**: shared standards, components and patterns. **Design token**: a named design decision stored as data (`color.text.primary`). **Component**: a reusable UI element with states. **Detach**: breaking an instance away from its library component. **Coverage**: the share of UI built from the system. More in the [glossary](#glossary-and-mental-model) |
| Term status | **Established** label with a stable working definition; scope varies by organisation and practice maturity was low in a 2020 survey (details below) |
| Evidence status | Partially verified: every footnoted source was opened, but some claims rest on secondary copies (Curtis and Schleifer as quoted by Frost; a retailer listing for *The Design Conductors*, whose publisher page could not be fetched), and the DesignOps Assembly's reports could not be opened. The ledger lists every gap |

### The problem it solves

Design teams tend to hit the same wall as they grow. NN/g notes that UX teams often grow faster than the rest of the company and
that designers end up doing strategic and logistical work on top of their core craft.[^nng-101] Without someone running the system,
the costs show up in predictable places. The "before" column is a composite of common failure patterns, not a report about one
company.

| Area | Without DesignOps | With it |
|---|---|---|
| Consistency | Five button styles, three date pickers, colours copied by hand | One maintained library; tokens drive colours, spacing and type everywhere |
| Accessibility | Contrast and focus problems found by an audit after launch | Contrast checked when tokens change; components ship with keyboard and screen-reader behaviour |
| Handoff | Engineers rebuild from screenshots; "which file is current?" | A ready-for-development state, linked components and an agreed definition of done |
| Capacity | Every request is urgent; designers are spread across too many squads | One intake, visible capacity, explicit trade-offs with product leaders |
| People | No career path except management; reviews depend on the manager | A documented career framework and calibrated reviews |
| Value | Leaders cannot see what design contributes | A small scorecard tied to product and business goals |

NN/g's 2020 survey of 557 UX and design professionals shows how common the "before" column was: on average, respondents reported
only 7.5 of 34 listed DesignOps activities or artefacts (22%), only 20% worked somewhere with at least one person dedicated to
DesignOps, 11% had a documented career ladder, and 80% said design's role and value were not understood across their
company.[^nng-maturity] These are self-reported figures from 2020; NN/g itself cautions that having an item does not prove it
helps.

### What DesignOps is not

- **Not only the design system.** NN/g lists design systems as one item among nine areas (under "Harmonize").[^nng-faq] A
  design-system team with no attention to intake, people or measurement is doing part of DesignOps.
- **Not project management with a new name.** Scheduling is a piece of it; the craft infrastructure and the people practices are
  what make it DesignOps. Programme mechanics in general belong to [ProjectOps](../projectops/).
- **Not a gate.** A DesignOps function that makes teams wait for approval has become the bottleneck it was meant to remove.
- **Not the design leader's job description.** Leaders set direction and quality bars; DesignOps builds the system that lets the
  organisation meet them.

### Term status and the ResearchOps question

The label is **established**: there is a widely quoted working definition,[^nng-101] research on how practitioners define it,[^nng-defs]
dedicated books (the *DesignOps Handbook*, released free by InVision's DesignBetter in 2018 and described at the time as "the first
of its kind on the subject of DesignOps",[^dribbble-handbook] and Rosenfeld Media's *The Design Conductors: Your Essential Guide to
Design Operations*, 2024[^conductors]), named roles such as design program manager and design producer,[^nng-faq] and paid
training.[^hsc-course]

Two caveats keep the label honest:

1. **The definition is stable; the scope is not.** When NN/g analysed 310 usable definitions out of 341 collected in 2019, practitioners
   described DesignOps mostly by its purpose: standardise (27%), enable and support designers (22%), scale design's reach and impact
   (12%), increase productivity (8%), enable alignment and collaboration (6%), produce better-quality work (5%). The author concluded
   that "it's risky to narrow the value of DesignOps to one single mental model" and, in 2020, still called it an emerging
   field.[^nng-defs]
2. **Practice maturity lags the label.** The 2020 NN/g survey above is the broadest published baseline for the whole practice
   found for this page. Later data cover the design-system half: zeroheight's *Design Systems Report 2026* (fifth edition, 147
   design-system practitioners, 90% in North America, Western Europe or Oceania, published by a documentation-tool vendor) found that 61% said their team did not
   have enough people to meet its goals, satisfaction with buy-in fell from 42% to 32% in a year, and 60% reported no automation
   of their token pipeline.[^zh-2026] The DesignOps Assembly publishes annual benchmarking reports on the wider practice, but they
   could not be opened for this page, so none of their figures are used.

**Does ResearchOps sit inside DesignOps?** NN/g says yes: "Research Operations is a specialized subcomponent of Design
Operations."[^nng-faq] Many organisations, though, run ResearchOps as a separate team with its own concerns: participants, consent,
incentives and research repositories.

::: decision Editorial distinction used in this Atlas
This page owns **craft and system** (design system, tooling, critique, handoff, design-team health). [ResearchOps](../researchops/)
owns **participants and insight** (recruitment, consent, repositories). This is the Atlas's split, chosen to avoid two pages
teaching the same thing; it is not an industry boundary, and in a small organisation one person often does both.
:::

## Origins, vocabulary and neighbours

### Origins and evolution

The building blocks are older than the label. A few milestones are well documented:

- **Design tokens** were created by the Salesforce design system team, and the name comes from "Jon & Jina", according to the
  Design Tokens Community Group's own technical reports (Jon Levine and Jina Anne; the report gives first names only).[^dtcg-tr]
- **Nathan Curtis** described solitary, centralised and federated team models for scaling a design system in September 2015.[^curtis-models]
- **Brad Frost's *Atomic Design*** (2016) gave teams a shared mental model for building interfaces from atoms up to pages, and
  collected early arguments that a design system is a product that needs makers, users and governance.[^frost-ch2][^frost-ch5]
- **The *DesignOps Handbook*** (InVision DesignBetter, June 2018), written by Kate Battles (Fitbit), Meredith Black (Pinterest),
  Collin Whitehead (Dropbox) and Dave Malouf (Design Ops Summit), gave the discipline a shared reference.[^dribbble-handbook]
- **NN/g's research programme** (2019–2020) supplied the most-quoted definition, a menu of focus areas, and a maturity survey.[^nng-101][^nng-defs][^nng-maturity]
- **Tooling caught up.** Design tools added variables, developer handoff modes and usage analytics, and in October 2025 the Design
  Tokens Community Group published the first stable version (2025.10) of a vendor-neutral token format.[^dtcg-stable]

No source opened for this page dates the first use of the word "DesignOps", so this page does not claim one.

### Glossary and mental model

| Term | Meaning | Example |
|---|---|---|
| Design system | "A complete set of standards intended to manage design at scale using reusable components and patterns" (NN/g)[^nng-ds101] | Tokens, a Figma library, a React package, usage guidance |
| Design token | A named design decision stored as data and translated for each platform[^dtcg-format] | `color.text.primary` → `#1a1a1a` on web, a colour asset on iOS |
| Primitive vs semantic token | A raw value (`blue-700`) vs a value named for its purpose (`button.primary.background`) that refers to a primitive | Rebrand by changing primitives; re-theme by remapping semantics |
| Alias | A token whose value is a reference to another token, written `{group.token}` in DTCG files[^dtcg-format] | `"$value": "{color.blue-700}"` |
| Mode / theme | One set of values for the same tokens (light, dark, brand B) | Figma variable modes[^figma-variables] |
| Component, variant | A reusable UI element; one configuration of it | Button; Button / primary / disabled |
| Instance, detach | A placed copy linked to the library; breaking that link so it no longer updates[^figma-analytics] | A designer detaches a modal to add a third button |
| Coverage | Share of UI elements in product code that come from the system | 450 of 600 interactive elements = 75% |
| Contribution | A change proposed by a team that consumes the system | A product team upstreams a file-upload component |
| Critique | A session that analyses whether a design meets its objectives, as opposed to approving it[^nng-critique] | Weekly 45-minute crit with a facilitator |
| Handoff | The point where a design is ready for engineering, with specs, states and accessibility notes | Figma "Ready for dev" status[^figma-devmode] |
| Design debt (UX debt) | Ongoing experience problems caused by a fast, easy or careless solution[^nng-uxdebt] | Three inconsistent error patterns in one flow |
| Intake | The single front door for design requests, with the information needed to prioritise | A form plus a weekly triage |
| Codemod | A script that rewrites consumers' code automatically for a migration | Rename every `<Button kind=…>` to `<Button variant=…>` |
| axe (axe-core) | Deque's open-source library of automated accessibility rules, used by many test tools[^storybook-a11y] | A component test fails on a missing accessible name |
| Design program manager | A role that runs planning, capacity and cross-team delivery for design[^nng-faq] | Owns intake and the quarterly capacity plan |

#### A mental model: a studio and a supply chain

Hold two pictures at once.

1. **A studio.** People with a craft, who need clear roles, a steady flow of well-framed work, honest critique, time to think and a
   path to grow. DesignOps runs the studio: intake, capacity, rituals, hiring, career frameworks.
2. **A supply chain.** Design decisions flow from tokens into a design library and code packages, then into many products. DesignOps
   (with engineering) runs the supply chain: versioned releases, contribution rules, quality gates and usage telemetry.

The studio without the supply chain produces good work that does not scale; the supply chain without the studio produces a
component library nobody asked for. Most failures on this page come from running only one of the two.

### How DesignOps relates to other Ops

::: figure DesignOps and its neighbours: what crosses each boundary
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 14, "rankSpacing": 26, "padding": 8}}}%%
flowchart TB
  RO["ResearchOps: participants, repositories, insight"]
  PO["ProductOps: roadmaps, launches, product data"]
  CO["ContentOps: words, content models, UX writing"]
  D["DesignOps: design team and design system"]
  RL["ReleaseOps, DevOps: build and release pipelines"]
  WM["WebOps, MobileOps: running the shipped apps"]
  DX["DevExOps: developer friction and tooling"]
  RO -->|"insight for design work"| D
  PO <-->|"priorities in, capacity out"| D
  CO <-->|"copy in components"| D
  D -->|"versioned packages"| RL
  RL --> WM
  D -.->|"component APIs, docs"| DX
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class D core
  class RO,PO,CO,RL,WM,DX neutral
```
Text equivalent: DesignOps sits in the middle. Above it, ResearchOps supplies insight for design work, ProductOps exchanges
priorities for capacity (two-way), and ContentOps exchanges the copy that lives inside components (two-way). Below it, DesignOps
ships versioned packages to ReleaseOps and DevOps pipelines, which deliver to the apps run by WebOps and MobileOps. A dotted line
to DevExOps shows that component APIs and documentation are part of the developer experience.
:::

| Neighbour | Shared ground | DesignOps owns | The neighbour owns |
|---|---|---|---|
| [ResearchOps](../researchops/) | Often one team in small orgs; both serve designers | Craft, system, design-team health | Participants, consent, incentives, research repositories |
| [ProductOps](../productops/) | Planning cadence, launches | Design capacity and design quality | Product operating model, analytics, roadmaps |
| [ContentOps](../contentops/) | Components carry words | Component look, behaviour, states | Words, voice, content models, translation |
| [AgileOps](../agileops/) | Team rituals | Design rituals (critique, design QA) | Team cadence, flow metrics |
| [WebOps](../webops/), [MobileOps](../mobileops/) | Shipped UI quality | The system the apps are built from | Running, releasing and monitoring the apps |
| [ReleaseOps](../releaseops/), [DevOps](../devops/) | Packages, CI | What is in a design-system release and its semver | Pipelines, deployment, rollback |
| [DevExOps](../devexops/) | Engineers consume the system | Component APIs, docs, migration guides | Wider developer friction and platforms |
| [CXOps](../cxops/) | Journey quality | Consistency and accessibility of the interface | Cross-journey feedback loops and survey metrics |

## Principles and operating model

### Charter and principles

No official DesignOps manifesto exists. The charter below is **this Atlas's proposal**, built from the sources on this page;
adapt it, and write down what you reject and why.

**Mission.** Make it easy for designers to do excellent work and for product teams to ship consistent, accessible interfaces, and
show the effect in numbers leaders care about.

1. **Start from measured pain.** NN/g's advice is to treat DesignOps as a design problem: interview, survey and run listening tours
   before choosing what to build.[^nng-faq][^nng-101] Never start from the full menu.
2. **Serve, do not gate.** Every process step must save the people who follow it more time than it costs them. Remove steps that do
   not.
3. **The system is a product.** It has customers (designers and engineers), a roadmap, a backlog, releases, support and funding.
   Frost quotes Nathan Curtis: "A design system is a living, funded product with a roadmap & backlog, serving an
   ecosystem."[^frost-ch5]
4. **Decisions live in one place.** A colour, spacing step or behaviour is decided once, as a token or component, and flows to every
   platform.
5. **Accessibility is a property of the system, not an audit.** Tokens and components meet WCAG 2.2 AA before release, and products
   inherit that baseline.
6. **Change is versioned and announced.** Breaking changes go in major releases, after at least one minor release that deprecates
   the old behaviour, as SemVer recommends.[^semver]
7. **Contribution beats central heroics.** Product teams can propose and build additions against published criteria.
8. **Measure outcomes, not output.** Coverage and cycle time matter more than the number of components shipped.

**Non-goals.** Owning every design decision; approving every screen; running research logistics; replacing engineering ownership
of front-end code.

### Fundamentals: the nine areas

NN/g organises DesignOps into three questions with three areas each.[^nng-101] The table uses NN/g's area names and this page's
short descriptions.

| NN/g question | Area | What it covers | Typical artefact |
|---|---|---|---|
| How we work together | Organize | Team structure, roles | Org chart, role definitions |
| | Collaborate | Meetings, spaces, communities of practice | Critique cadence, design guild |
| | Humanize | Hiring, onboarding, career paths | Interview kit, career framework |
| How we get our work done | Standardize | Consistent tools and processes | Tool stack, file conventions |
| | Harmonize | Design systems, research repositories, asset libraries | Design system, libraries |
| | Prioritize | Bottlenecks, capacity, ranking projects | Intake, capacity plan |
| How our work creates impact | Measure | Defining and tracking design quality | Scorecard |
| | Socialize | Communicating design's value | Case studies, demos |
| | Enable | Teaching non-designers design activities | Workshops, toolkits |

The design system itself has layers that are worth naming separately, because each has a different owner and change rate:

| Layer | Contents | Changes | Usually owned by |
|---|---|---|---|
| Foundations | Tokens: colour, type, spacing, radius, motion, elevation | Rarely; high blast radius | System team |
| Components | Coded and design-tool components with states and accessibility behaviour | Often; versioned | System team with contributors |
| Patterns | Combinations for recurring tasks (forms, empty states, error handling) | Moderately | Contributors with system review |
| Guidance | When to use what, content rules, accessibility notes | Continuously | System team, ContentOps for words |
| Tooling and telemetry | Packages, docs site, linting, usage analytics | Continuously | System team with platform engineering |

### Roles, ownership and RACI

Roles vary widely; NN/g notes that "anyone can do DesignOps" and that many organisations give the work to design managers or
senior designers before creating dedicated roles.[^nng-faq] Common dedicated roles are the **DesignOps manager** (owns the operating
model), the **design program manager or producer** (intake, capacity, delivery coordination), and the **design-system team**:
NN/g's minimum is one interaction designer, one visual designer and one developer, ideally with an executive sponsor.[^nng-ds101]

**Team structure.** A 2025 NN/g article by Anna Kaley proposes the managed-UX integration model, in which designers report to design leaders while
working day to day in a product team for long periods; the article warns that centralised teams become a short-term service and that fully
decentralised teams fragment and limit growth. Its advice: begin with a purpose, not with a structure.[^nng-muxi] For the design
system itself, Curtis's three models still frame the choice: a **solitary** team that owns the system for its own product (which
"don't scale"), a **centralised** team serving others (consistent but at risk of losing product context), or a **federated** group
of designers from several products (relevant but harder to decide and record).[^curtis-models] Many organisations run a small
central team with federated contributors.

RACI for recurring DesignOps work (R = responsible, A = accountable, C = consulted, I = informed):

| Activity | DesignOps / program mgr | Design-system team | Design leader | Product designers | Engineering | Product mgmt |
|---|---|---|---|---|---|---|
| Intake and capacity plan | A, R | I | C | C | I | C |
| Critique cadence | R | I | A | R | I | I |
| Career framework and calibration | R | I | A | C | I | I |
| Token and component releases | C | A, R | I | C | R | I |
| Contribution review | C | A, R | C | R | R | I |
| Accessibility baseline | C | A, R | C | R | R | I |
| Handoff definition of done | R | C | A | R | R | C |
| Scorecard and reporting | A, R | R | C | I | C | C |

### Lifecycle

Two lifecycles run side by side. The **team lifecycle** follows the year: plan capacity, hire and onboard, run rituals, review and
calibrate, adjust structure. The **component lifecycle** governs the system, and it needs to be explicit because consumers depend on
it. GOV.UK's design system, for example, labels new components "Trial" and moves them to stable after six months if no negative
feedback arrives; trial components can also be deprecated.[^govuk-lifecycle]

::: figure Lifecycle of a design-system component (this Atlas's model, using GOV.UK's Trial and Stable labels)
```mermaid
stateDiagram-v2
  direction TB
  state "Proposed (evidence of need)" as Proposed
  state "Trial (released, feedback open)" as Trial
  state "Stable (supported)" as Stable
  state "Deprecated (warning, migration guide)" as Deprecated
  state "Removed (next major release)" as Removed
  [*] --> Proposed
  Proposed --> Trial: meets proposal criteria
  Proposed --> [*]: rejected or duplicate
  Trial --> Stable: research and feedback OK
  Trial --> Deprecated: did not work
  Stable --> Deprecated: replaced or no longer needed
  Deprecated --> Removed: at least one minor release later
  Removed --> [*]
```
Text equivalent: A component starts as Proposed with evidence of need; it is either rejected or moves to Trial when it meets the
proposal criteria. From Trial it becomes Stable when research and feedback are good, or Deprecated if it did not work. A Stable
component becomes Deprecated when it is replaced or no longer needed. A Deprecated component, which carries a warning and a migration
guide, is Removed in a later major release, at least one minor release after the deprecation.
:::

### Operating model and governance

A workable operating model is a short list of cadences with owners and outputs. Lengths are starting points, not rules.

| Cadence | Purpose | Owner | Output |
|---|---|---|---|
| Weekly intake triage (30 min) | Accept, decline or redirect requests | Design program manager | Updated queue, decisions sent |
| Weekly critique (45–60 min) | Improve work in progress against objectives | Rotating facilitator | Notes and actions per presenter |
| Fortnightly system office hours | Help consumers; collect needs | System team | Support log, backlog items |
| Release train (every 2–4 weeks) | Ship tokens and components | System team | Versioned release, notes |
| Monthly design-system review | Decide contributions, deprecations | System lead with federated reps | Decision records |
| Quarterly capacity and scorecard review | Rebalance designers; report outcomes | DesignOps manager, design leader | Capacity plan, scorecard |
| Twice-yearly calibration | Consistent levelling and promotion | Design leader | Calibrated ratings, promotion decisions |

**Governance** answers Frost's three questions: who approves changes to the system, how changes reach live products, and how people
find out.[^frost-ch5] Write the answers down. **Escalation**: a consumer blocked by the system can ship a local workaround *with a
ticket* the same day; the system team must answer within an agreed time (for example two working days) whether to fix, accept as a
pattern, or ask for a contribution.

## Architecture and workflow

### Reference architecture: the design-system supply chain

The architecture below is technology-neutral. Tool names in the text are examples checked in October 2026, not recommendations.

::: figure Reference architecture: from token source to shipped products, with feedback
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 18, "rankSpacing": 26, "padding": 8}}}%%
flowchart TB
  T["Token files (DTCG JSON), version control"]
  C["Component code and tests, version control"]
  TB["Token build: CSS, iOS, Android"]
  G["CI gates: contrast, a11y, visual diff"]
  LIB["Design-tool library and variables"]
  PKG["Versioned packages"]
  DOC["Docs site and release notes"]
  P["Product teams' apps"]
  TEL["Telemetry: library analytics, code scans"]
  BL["Backlog and deprecations: the next change"]
  T --> TB --> G
  C --> G
  G -->|"sync after gates"| LIB
  G --> PKG
  G --> DOC
  LIB --> P
  PKG --> P
  P --> TEL --> BL
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class T,C,TB,PKG,LIB,DOC core
  class G decision
  class P,TEL,BL neutral
```
Text equivalent: Token files in DTCG JSON and component code with tests both live in version control. Tokens go through a token
build that produces CSS, iOS and Android outputs; the build output and the component code then pass CI gates for contrast,
accessibility and visual differences. Only after the gates do three things happen: token values are synchronised to the design
tool's library and variables, versioned packages are published, and the docs site and release notes are updated. Product teams
build their apps from the library and the packages. Their apps feed telemetry (library analytics and code scans), which becomes
backlog items and deprecation decisions: the next change to tokens and code.
:::

| Component | Responsibility | Example implementations (as of October 2026) | Trade-off |
|---|---|---|---|
| Token source | One file set that every platform derives from | DTCG 2025.10 JSON in a repository[^dtcg-format] | Tool support for 2025.10 is still partial (see [tooling](#tooling-landscape)) |
| Token build | Translate tokens to platform code | Style Dictionary, Terrazzo, Tokens Studio (DTCG's listed reference implementations)[^dtcg-stable] | Custom transforms become code you maintain |
| Design library | Components and variables designers use | Figma libraries and variables;[^figma-variables] Penpot, Sketch | Library and code can drift unless synced and checked |
| Component code | The implementation products ship | Framework packages (React, SwiftUI, Compose, Vue…) | Multi-framework support multiplies work |
| Gates | Stop regressions before release | Contrast checks (Lab 2), axe-based tests, visual comparisons[^storybook-a11y][^playwright-visual] | Automated checks miss many issues; keep human review |
| Docs | Guidance, examples, release notes | A docs site; Storybook | Docs rot unless part of the definition of done |
| Telemetry | Show adoption and friction | Design-tool library analytics;[^figma-analytics] code scans (Lab 3) | Each source sees only part of reality |

**Trust boundary.** The design-tool library is usually editable by many designers; code packages are not. Treat the code
repository as the source of truth for anything that ships, and sync towards the design tool, or run a two-way process with review
on both sides. Never let an unreviewed design-tool edit change production colours automatically.

### End-to-end workflow: a design request from intake to shipped UI

::: figure Design request workflow with the happy path and the exception path
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 18, "rankSpacing": 24, "padding": 8}}}%%
flowchart TB
  R["Product team: request with goal, deadline, evidence"] --> T{"DesignOps triage"}
  T -->|"decline or redirect"| X["Reply with reason or route elsewhere"]
  T -->|"accept"| D["Designer: explore, critique, iterate"]
  D --> F{"Existing components fit?"}
  F -->|"yes"| H["Ready for dev: states, a11y notes"]
  F -->|"no"| G["Gap report to system team"]
  G --> S{"System team decision"}
  S -->|"fix or add variant"| REL["System release"]
  S -->|"needs more time"| W["Local workaround with ticket"]
  REL --> H
  W --> H
  H --> B["Engineering build and design QA"]
  B --> A["Accepted; outcome metric agreed"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class R,D,H,B,A core
  class T,F,S decision
  class G,W risk
  class X,REL neutral
```
Text equivalent: A product team sends a request with a goal, a deadline and evidence. DesignOps triage either declines or
redirects it, with a reason, or accepts it and assigns a designer, who explores, takes the work to critique and iterates. If
existing components fit (the happy path), the designer marks the work ready for development with states and accessibility notes.
If not (the exception path, whose gap report and workaround are shaded red), the designer sends a gap report to the system team, which either fixes the gap or adds a
variant in a system release, or, when that needs more time, approves a local workaround tracked by a ticket. Both routes return to
ready for development; engineering then builds the work, the designer runs design QA, and the product team accepts it with an
agreed outcome metric.
:::

The exception path is where most organisations go wrong: without an agreed route, designers detach components silently, engineers
fork them, and the system loses both coverage and the information about what it is missing.

## Practices and playbooks

Each playbook names a trigger, an owner, the steps, an acceptance test and what to do when it fails.

| Practice | Goal | Trigger | Owner | Output | Verification |
|---|---|---|---|---|---|
| Intake and capacity | Work matches capacity, trade-offs visible | Any request for design time | Design program manager | Ranked queue, capacity plan | Request cycle time; % of capacity on top priorities |
| Critique | Better work, shared standards | Work in progress at any stage | Rotating facilitator | Notes, actions | Participant survey; repeat issues fall |
| Handoff | Engineering builds what was designed | Design ready for build | Designer and tech lead | Ready-for-dev package | Design QA defects per screen |
| Contribution | The system grows from real needs | A gap report or proposal | System team | Decision record; component in trial | Time to decision; contributed share |
| Releases and deprecation | Change without breaking consumers | Merged changes | System team | Versioned release, notes, codemods | Upgrade lag; breaking changes outside majors = 0 |
| Accessibility in the system | Products inherit an AA baseline | Any token or component change | System team | Passing gates, a11y notes | Gate pass rate; audit findings traced to system |
| People practices | Healthy, growing team | Hiring, onboarding, review cycles | DesignOps manager, leader | Interview kit, framework, calibration | Time to productivity; attrition; promotion equity |

### Playbook: intake and capacity

1. Publish **one front door** (a form or ticket type; see the [intake template](#templates)). Requests arriving in chat are
   politely redirected.
2. Require the **problem and outcome**, not the solution: who is affected, what changes for them, how success is measured, the
   deadline and why it is fixed.
3. **Triage weekly** with the design leader and a product representative: accept, decline, redirect (to the system's existing
   patterns, to self-service guidance, or to [ResearchOps](../researchops/) for a research need).
4. **Size in designer-weeks** with a range, not a point estimate.
5. Keep a **capacity plan**: available designer-weeks per quarter after holidays, rituals and system contribution time (see the
   [worked calculation](#cost-capacity-and-sustainability)).
6. When demand exceeds capacity, **show the trade-off** to the product leaders who own priorities; do not quietly overload
   designers.

**Acceptance.** Every active piece of work has an owner, a size and an expected date; nobody is assigned to more than two
initiatives. **Contingency.** If a fixed deadline cannot be met, offer a reduced scope that reuses existing components first.

### Playbook: critique and review rituals

NN/g distinguishes a **critique**, which analyses whether a design meets its objectives and improves work in progress, from a
**design review**, which evaluates a design against heuristics, often near the end, to gain approval.[^nng-critique] Mixing them
makes critique feel like a gate and makes people bring work too late.

1. Separate the calendar: **critique** (weekly, peers, work in progress) and **review** (milestone, decision-makers, sign-off).
2. Give each critique a **facilitator** (rotating), **presenters** who state the objectives and the specific feedback wanted, and
   **critiquers**; NN/g describes these three roles.[^nng-critique]
3. **Agree scope and objectives first**; comments refer to objectives and user needs, not taste.
4. Use a **round robin** or a quota of comments so quieter people speak.
5. The facilitator turns directive comments ("make it blue") into questions about objectives, and records actions.
6. Do not solve problems live; presenters follow up.

**Acceptance.** Every presenter leaves with recorded actions. **Warning sign.** The same senior person speaks first and longest in
every session; rotate facilitation and enforce turn-taking.

### Playbook: handoff that engineering trusts

1. Agree a **definition of ready for development**: all states (empty, loading, error, disabled, focus), responsive behaviour,
   content rules, accessibility notes (headings, labels, focus order, announcements), and links to system components rather than
   copies.
2. Mark readiness in the tool. Figma's Dev Mode, for example, offers a "Ready for dev" status, version comparison and annotations
   (Professional, Education, Organization, Government and Enterprise plans with a Full or Dev seat, as of October 2026).[^figma-devmode]
3. Use **accessibility annotations** so intent survives the handoff. GitHub open-sourced its Annotation Toolkit, a Figma library for
   documenting accessibility details, in September 2025.[^github-annotations]
4. Link design components to code components where your tools allow it. Figma's Code Connect, "a bridge between your codebase and
   Figma's Dev Mode", needs a Full or Dev seat; Figma's own help pages differ on plans (October 2026): the Code Connect article
   lists Professional, Organization, Government and Enterprise,[^figma-codeconnect] while the Dev Mode guide omits
   Government.[^figma-devmode] Check before you budget.
5. Run **design QA** on a build before release: compare states and behaviour, not pixels alone.

**Acceptance.** Design-QA defects per screen fall release over release. **Rollback.** If engineering cannot build a design within the
sprint, the designer and tech lead agree a scope that uses existing components and log the rest as design debt.

### Playbook: contribution and governance

GOV.UK's design system publishes concrete criteria that make contribution decisions predictable: at proposal stage a component must
be **useful** (evidence that many teams need it) and **unique** (not a duplicate); before publication it must be **usable** (tested
in research with a representative sample of users, including disabled people), **consistent** (reuses existing styles and
components) and **versatile** (works across services, browsers, assistive technologies and devices).[^govuk-criteria]

::: figure Contribution decision flow, with the exception path for urgent product needs
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 16, "rankSpacing": 26, "padding": 8}}}%%
flowchart TB
  A["Gap report or proposal"] --> B{"Useful to several teams?"}
  B -->|"no"| L["Local component, documented in product;<br/>re-propose later if others need it"]
  B -->|"yes"| C{"Unique: not a variant of an existing one?"}
  C -->|"no"| V["Extend existing component (variant or prop)"]
  C -->|"yes"| D["Build: usable, consistent, versatile"]
  D --> E{"Passes research and gates?"}
  E -->|"no"| D
  E -->|"yes"| T["Release as Trial"]
  U["Urgent product deadline"] -.->|"ticketed workaround"| L
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class A,D,T,V core
  class B,C,E decision
  class U,L risk
```
Text equivalent: A gap report or proposal is checked for usefulness to several teams. If not useful, it stays a local component
documented in the product. If useful, it is checked for uniqueness; if it is really a variant of an existing component, the existing
component is extended. If unique, it is built to be usable, consistent and versatile, then checked against research and quality
gates, looping back until it passes and is released as Trial. An urgent product deadline can take a ticketed local workaround
(dotted), and a local component is re-proposed if other teams later need it.
:::

Record each decision in a short decision record (template in [Templates](#templates)). Curtis warns that in federated groups "no
one keeps track or can recall the path that led to a decision"; written records are the fix.[^curtis-models]

### Playbook: releases, versioning and deprecation

1. Use **semantic versioning**: MAJOR for incompatible changes, MINOR for backward-compatible additions, PATCH for fixes.[^semver]
2. Define **what counts as breaking for a design system**, which is wider than code APIs. Volvo Cars' design system uses the test "if
   a team can bump the version, release their application, and end users see no bugs" and counts layout-affecting design updates as
   potentially breaking, while treating markup as non-public.[^volvo-releases] Token renames and changes to a token's meaning are
   breaking too.
3. **Deprecate before removing.** SemVer asks for at least one minor release containing the deprecation before removal in a
   major.[^semver] DTCG token files can carry `$deprecated` with an explanation.[^dtcg-format]
4. **Give the community a window.** Australia's Agriculture Design System opens breaking or deprecating changes as labelled draft
   pull requests, announces them, and keeps them open for at least one week before its team decides.[^agds-change]
5. **Ship on a train** (Volvo aims to release its CSS package every two weeks[^volvo-releases]) with release notes that say what to
   do, not only what changed. Provide codemods for mechanical migrations.
6. **Track upgrade lag** per consuming app (see [metrics](#metrics-and-kpis)).

### Playbook: accessibility built into the system

The aim is that a product built from the system starts at WCAG 2.2 AA for everything the system controls. Relevant AA success
criteria include text contrast of at least 4.5:1 (3:1 for large text), non-text contrast of 3:1 for component boundaries and states,
pointer targets of at least 24 by 24 CSS pixels (with exceptions), and focused components not being entirely hidden by
author-created content.[^wcag22]

1. **Tokens.** Declare which foreground/background pairs are allowed and test their contrast on every change (Lab 2 builds this
   gate). Include focus-ring and border tokens in the pairs (non-text contrast).
2. **Components.** Each ships with keyboard behaviour, focus management, accessible names, and documented screen-reader output,
   tested with assistive technology, not only with automated checks.
3. **Automation.** Run axe-based checks in component tests. Storybook's accessibility addon, built on Deque's axe-core, can fail
   CI when `parameters.a11y.test` is `'error'`; Storybook's documentation says it "automatically catches up to 57% of WCAG
   issues", citing a Deque study.[^storybook-a11y] Deque's 57% is a share of issues **by volume** in its own first-time audits
   (more than 2,000 audits, nearly 300,000 issues), not a share of WCAG success criteria: frequent issue types raise the
   percentage.[^deque-57] Treat it as "automation finds many of the issues you will have", never as "automation covers
   most of WCAG"; keyboard, focus, reading-order and screen-reader behaviour still need manual testing.
4. **Visual regressions.** Screenshot comparisons catch unintended changes; Playwright warns that rendering varies by operating
   system, version and hardware, so generate baselines in the same environment that checks them.[^playwright-visual]
5. **Guidance.** Usage notes say what the system cannot guarantee (for example meaningful link text, heading order on a page).

Legal duties depend on jurisdiction and sector; this is orientation, not legal advice (October 2026). The European Accessibility
Act covers products and services such as computers, smartphones, e-books, e-commerce and banking[^eaa] and applies from 28 June
2025;[^eaa-date] EN 301 549 V4.1.1 (WCAG 2.2 AA) was published on 2 September 2026, but V3.2.1 (WCAG 2.1) stays the cited standard
until its Official Journal reference, expected on 16 December 2026;[^en301549] US state and local governments must meet WCAG 2.1 AA
from 26 April 2027 or 2028, depending on size.[^ada-title2] [ContentOps](../contentops/) has a fuller table.

### Playbook: people practices

- **Hiring.** A structured interview kit per level (portfolio review rubric, collaboration exercise, the same questions for every
  candidate) and a diverse panel.
- **Onboarding.** A 30-day plan: tools and file conventions, the design system, a buddy, shadowing critique, a first small shipped
  change.
- **Career framework.** Levels for individual contributors that go as high as management levels; NN/g's survey found that 82% of
  respondents reported no advancement path outside management.[^nng-maturity]
- **Calibration.** Cross-team calibration before ratings and promotions; check outcomes for equity.
- **Load.** Track designers per initiative and time spent on non-design work; NN/g's original motivation for DesignOps is to return
  that time to the craft.[^nng-101]

## Methods, standards and tools

### Methods, standards and frameworks

Separate what is normative from what is advice:

| Source | Type | Use it for | Caveat |
|---|---|---|---|
| WCAG 2.2 (W3C Recommendation since 5 October 2023; current edition 12 December 2024)[^wcag22] | Normative web standard; referenced by laws in many jurisdictions | Accessibility baseline for tokens and components | Laws may cite WCAG 2.1 rather than 2.2 (see above) |
| DTCG Design Tokens Format Module 2025.10[^dtcg-format] | Community Group specification, stable; "not a W3C Standard nor is it on the W3C Standards Track" | Tool-neutral token files | Tools implement it at different speeds |
| Semantic Versioning 2.0.0[^semver] | Widely used convention | Release numbering and deprecation | You must define "breaking" for visual changes yourself |
| NN/g DesignOps framework[^nng-101] | Practitioner framework | Choosing focus areas | A menu, not a maturity model or a standard |
| Atomic design (Frost, 2016)[^frost-ch2] | Mental model | Structuring components | "Atomic design is not a linear process" |
| HEART and Goals–Signals–Metrics (Google, CHI 2010)[^heart] | Research framework | Choosing user-centred metrics for design outcomes | Pick a few categories; not all apply |
| GOV.UK contribution criteria[^govuk-criteria] | One organisation's documented practice | Contribution rules | Written for UK government services |

**Tokens in practice.** A DTCG token is a JSON object whose only required property is `$value`; `$type`, `$description` and
`$deprecated` are optional, groups can set a `$type` their children inherit, and an alias such as `"{color.blue-700}"` resolves to
the target token's `$value`.[^dtcg-format] In 2025.10 a colour value is an object with `colorSpace` and `components` (plus optional
`alpha` and a six-digit `hex` fallback),[^dtcg-color] and a dimension is an object such as `{"value": 1, "unit": "rem"}`.[^dtcg-format]
The format recommends the media type `application/design-tokens+json` and the extensions `.tokens` or `.tokens.json`.[^dtcg-format]

### Tooling landscape

Vendor-neutral categories first; examples are illustrations checked in October 2026, not endorsements.

| Category | Job | Example options | Selection criteria | Risks |
|---|---|---|---|---|
| Design tool and libraries | Components, variables, collaboration | Figma, Penpot, Sketch | Library publishing, variables and modes, analytics, permissions, export formats | Plan-gated features; lock-in of library structure |
| Token pipeline | Translate tokens per platform | Style Dictionary (5.7.0 on npm, 2026-10-23), Terrazzo, Tokens Studio | DTCG 2025.10 support, custom transforms, platform outputs | Style Dictionary's docs say 2025.10 support is still "a work in progress in v5"[^sd-dtcg] |
| Component workshop and docs | Develop, document, test components | Storybook; a docs site | Framework support, a11y and visual testing integration | Docs that are not part of the definition of done go stale |
| Automated quality gates | Contrast, a11y, visual diff | Custom contrast checks; axe-core; Playwright screenshots | CI integration, false-positive handling | Partial coverage of WCAG; environment-sensitive screenshots |
| Handoff | Specs, readiness, code links | Figma Dev Mode, Code Connect; annotations | Seat and plan costs, framework mapping | Generated code is a starting point, not a component |
| Usage telemetry | Adoption and detaches | Design-tool library analytics (plan-gated, below); code scanners such as react-scanner | Coverage of drafts, nested components, all platforms | Each source sees part of reality (Lab 1, Lab 3) |
| Work management | Intake, capacity, decisions | Any ticketing tool with forms | One front door, reporting | Over-engineered workflows nobody follows |

Plan and seat details change often. As of October 2026 Figma's help centre says: library analytics is "Available on the
Organization and Enterprise plans", data updates daily, covers up to one year, does not count instances in other people's drafts and
does not count nested components as insertions;[^figma-analytics] the Library Analytics API "is only available to organizations on
the Enterprise plan".[^figma-analytics-api] Check before you budget.

#### Token pipelines compared (as of October 2026)

The DTCG group lists three reference implementations of its format.[^dtcg-stable] The comparison below uses only what their own
documentation and the npm registry say; none of them was benchmarked for this page, and support claims change quickly.

| Tool | What it is | DTCG 2025.10 status (vendor's own words) | Licence, release (npm, 2026-10-23) |
|---|---|---|---|
| Style Dictionary | Build system that turns token files into platform code via transforms and formats | DTCG format supported since v4; 2025.10 "does not have full support yet", work in progress in v5[^sd-dtcg] | Apache-2.0; `style-dictionary` 5.7.0 |
| Terrazzo | CLI that reads DTCG token JSON and generates code through plugins (CSS, Sass, JS/TS, Swift, Tailwind and others) | Claims to be "the only tool that supports the full DTCG format"; links 2025.10 as the official format[^terrazzo] | MIT; `@terrazzo/cli` 2.10.0 |
| Tokens Studio | Figma plugin for editing tokens, plus `sd-transforms` for Style Dictionary | Plugin defaults to its "legacy" format; a DTCG format option exists and more DTCG types are promised "in future releases"[^tokens-studio-format] | `@tokens-studio/sd-transforms` MIT, 2.0.3; plugin licence not checked |

Choose on where your **source of truth** lives (repository or design tool), which **platforms** you must emit, and how much
**custom transform code** you will own. Before committing, feed Lab 2's token file to a candidate: can it read 2025.10 colour
objects?

#### Tool-stack governance

The Standardize area[^nng-101] is unglamorous but takes much of a DesignOps team's week. A short checklist:

- **Seats and licences.** Audit design-tool seats each quarter against active use and role (full editor, developer, viewer);
  remove leavers on the HR exit date; record who approves paid seats.
- **Files and libraries.** One naming convention for teams, projects, files and libraries (for example `<product> / <area> /
  <feature>`); one published library per layer (foundations, components, patterns), each with a named owner.
- **Archiving.** Move files untouched for two quarters to an archive project; unpublish libraries that have a replacement, after a
  deprecation notice.
- **Branching and review.** Changes to published libraries go through a branch and a review, the same rule as code, where the tool
  supports branching; record who can publish.
- **Access.** External contractors get project-level access with an end date; no shared logins.

### Automation and AI

Automation pays off where the work is mechanical and checkable: token builds, contrast and accessibility gates, visual comparisons,
release notes from commit messages, codemods for migrations, and usage reports. It pays off less where judgement is the product:
critique, prioritisation, and deciding what belongs in the system.

AI tooling is moving into handoff. Figma describes its MCP server as giving "AI agents the design context they need to generate code
from your Figma files", including variables and components; it is listed for Starter to Enterprise plans (Figma for Government: desktop
server only), with the desktop server for Dev or Full seats on paid plans, and agents can also write to the canvas in a beta that Figma says will later become usage-based (as
of October 2026).[^figma-mcp] Treat these tools as accelerators with three controls:

1. **Design-system context first.** Generated code is only consistent if it reuses real components; Figma itself positions Code
   Connect as the way to keep generated code aligned with your codebase.[^figma-mcp]
2. **Same gates as human code.** Generated UI goes through the contrast, accessibility and visual gates and through code review.
3. **Write access is a change.** An agent that can edit libraries or variables can change many products at once; restrict it to
   drafts or branches and review its changes like any other contribution.

## DesignOps in practice

### Reference implementation: operating artefacts

A mid-sized organisation (illustrative: 40 designers, 12 product teams, web and mobile) could run on the following set. Each
artefact has a template in [Templates](#templates).

| Artefact | Owner | Review cadence | Where it lives |
|---|---|---|---|
| DesignOps charter (mission, scope, non-goals, services) | DesignOps manager | Yearly | Wiki |
| Intake form and triage rules | Design program manager | Quarterly | Ticketing tool |
| Capacity plan | Design program manager | Quarterly, adjusted monthly | Spreadsheet or planning tool |
| Critique guide | Design leader | Yearly | Wiki |
| Definition of ready for development | Design leader and tech leads | Twice a year | Wiki, linked from tickets |
| Design system: tokens, components, docs | System team | Release train | Repository, design library, docs site |
| Contribution criteria and decision records | System team | Per decision | Repository |
| Release notes and deprecation schedule | System team | Per release | Docs site, changelog |
| Career framework and calibration guide | DesignOps manager | Yearly | HR system or wiki |
| Scorecard | DesignOps manager | Quarterly | Dashboard |

The **CI gate** for tokens can be as small as one job. The workflow below runs the Lab 2 script on every pull request that touches
tokens.

_Example status: YAML syntax-checked, not executed (requires a GitHub repository with the Lab 2 files under `tokens/`). Action
versions and commit SHAs checked against the actions' GitHub releases on 2026-10-23._

```yaml
name: design-tokens
on:
  pull_request:
    paths: ["tokens/**"]
permissions:
  contents: read
jobs:
  tokens:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false
      - uses: actions/setup-node@949feb2413d6458794dcd2491c4babbbce0c15c1 # v7.1.0
        with:
          node-version: "24"
      - name: Build tokens and gate contrast
        run: |
          node tokens/build-tokens.mjs tokens/tokens.json tokens/pairs.json \
            > tokens.css
      - uses: actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9 # v7.0.2
        with:
          name: tokens-css
          path: tokens.css
```

The job has read-only repository permissions and no secrets, and `persist-credentials: false` keeps the checkout token out of the
workspace; publishing the package is a separate, protected release job owned by [ReleaseOps](../releaseops/) practice. Each action
is pinned to a full commit SHA with the release as a comment: a tag such as `v7` can be moved to different code, a commit SHA
cannot, and a dependency bot can still propose updates. Keep the versions current: GitHub moved runners to Node 24 by default
in June 2026 and set 23 September 2026 for removing Node 20,[^gh-node20] and Node.js 20 itself reached end of life on 30 April
2026 (Node.js 24 is in maintenance LTS; Node.js 26 becomes Active LTS on 28 October 2026).[^node-schedule]

### Hands-on labs

Three runnable labs and one tabletop exercise, all on **synthetic data**, no accounts and no cost. Labs 1–3 were run on 2026-10-23
exactly as printed (Python 3.8.10; Labs 2 and 3 on Node.js 24.22.1 LTS; Ubuntu Linux); the expected outputs are copied from those
runs. Work in a new
folder such as `~/designops-labs` and delete it afterwards.

#### Lab 1 (beginner): read a detach report like a DesignOps lead

**Objective.** Turn a library-analytics export into a short list of components to investigate, and learn why a detach rate is a
question rather than a verdict. **Prerequisites.** Python 3.8+. **Time.** 20 minutes. **Risk.** None.

The CSV uses four of the fields that Figma's Library Analytics API returns for component actions (`week`, `component_name`,
`insertions`, `detachments`).[^figma-analytics-endpoints] The API returns paginated JSON (`rows`, `cursor`, `next_page`) with more
fields, such as `component_key` and `component_set_name`; to reuse the script, call it with `group_by=component` and flatten the
rows into these four columns. The API itself was not called for this lab.

1. Create the folder and the export.

_Example status: verified by execution on 2026-10-23 (bash, Linux)._

```bash
mkdir -p ~/designops-labs/lab1 && cd ~/designops-labs/lab1
cat > actions.csv <<'EOF'
week,component_name,insertions,detachments
2026-09-07,Button,140,6
2026-09-07,Modal,22,9
2026-09-07,Data table,35,4
2026-09-07,Date picker,12,7
2026-09-14,Button,151,5
2026-09-14,Modal,25,11
2026-09-14,Data table,31,3
2026-09-14,Date picker,9,6
2026-09-21,Button,133,7
2026-09-21,Modal,19,8
2026-09-21,Data table,40,5
2026-09-21,Date picker,14,8
EOF
```

2. Save the script as `detach_report.py`.

_Example status: verified by execution on 2026-10-23 (Python 3.8.10, standard library only)._

```python
"""Detach rate per component from a library-analytics export (standard library only).

detach rate = detachments / insertions over the window. A high rate is a question to ask
the teams detaching, not a verdict: some components are designed to be detached.
"""
import csv
import sys
from collections import defaultdict

MIN_INSERTIONS = 30   # ignore components with too little use to judge
ALERT_RATE = 0.25     # investigate when a quarter or more of insertions are detached

totals = defaultdict(lambda: [0, 0])
with open(sys.argv[1], newline="") as f:
    for row in csv.DictReader(f):
        t = totals[row["component_name"]]
        t[0] += int(row["insertions"])
        t[1] += int(row["detachments"])

print(f"{'component':<12} {'inserts':>7} {'detach':>6} {'rate':>6}  action")
for name, (ins, det) in sorted(totals.items(), key=lambda kv: -kv[1][1] / kv[1][0]):
    rate = det / ins
    if ins < MIN_INSERTIONS:
        action = "too little use to judge"
    elif rate >= ALERT_RATE:
        action = "INVESTIGATE: interview detaching teams"
    else:
        action = "ok"
    print(f"{name:<12} {ins:>7} {det:>6} {rate:>6.1%}  {action}")
```

3. Run it.

_Example status: verified by execution on 2026-10-23._

```bash
python3 detach_report.py actions.csv
```

**Expected output.**

```text
component    inserts detach   rate  action
Date picker       35     21  60.0%  INVESTIGATE: interview detaching teams
Modal             66     28  42.4%  INVESTIGATE: interview detaching teams
Data table       106     12  11.3%  ok
Button           424     18   4.2%  ok
```

**Validation.** Check one row by hand: the modal has 22 + 25 + 19 = 66 insertions and 9 + 11 + 8 = 28 detachments; 28 ÷ 66 = 42.4%.
**Interpretation.** The date picker and modal need conversations, not mandates: a detached modal may mean the component lacks a
footer slot that product teams legitimately need. Figma's own guidance warns that a high detachment rate can be expected for some
components.[^figma-metrics] **Troubleshooting.** `KeyError: 'component_name'`: the CSV header differs; rename the columns or change
the script. `ZeroDivisionError`: a component with zero insertions; skip it. **Teardown.** `rm -r ~/designops-labs/lab1`.

#### Lab 2 (intermediate): a token build with a contrast gate

**Objective.** Store design decisions as DTCG 2025.10 tokens, resolve aliases, generate CSS custom properties, warn about deprecated
tokens and fail the build when a declared text/background pair falls below WCAG 2.2's 4.5:1. **Prerequisites.** Node.js 22 or later
(no packages; the script uses `replaceAll` and `??`, and older lines are out of support). **Time.** 30 minutes. **Risk.** None.

1. Create the token file, which follows the DTCG colour and dimension formats.[^dtcg-format][^dtcg-color]

_Example status: verified by execution on 2026-10-23; the JSON is also syntax-checked by the Atlas validator._

```json
{
  "color": {
    "$type": "color",
    "blue-700": {
      "$value": { "colorSpace": "srgb", "components": [0.03137, 0.31765, 0.65882],
                  "hex": "#0851a8" }
    },
    "grey-500": {
      "$value": { "colorSpace": "srgb", "components": [0.53333, 0.53333, 0.53333],
                  "hex": "#888888" },
      "$deprecated": "Below 4.5:1 on white; use color.grey-700. Removed in 5.0.0."
    },
    "grey-700": {
      "$value": { "colorSpace": "srgb", "components": [0.34902, 0.34902, 0.34902],
                  "hex": "#595959" }
    },
    "white": {
      "$value": { "colorSpace": "srgb", "components": [1, 1, 1], "hex": "#ffffff" }
    }
  },
  "space": {
    "$type": "dimension",
    "200": { "$value": { "value": 0.5, "unit": "rem" } },
    "400": { "$value": { "value": 1, "unit": "rem" } }
  },
  "button": {
    "primary": {
      "background": { "$type": "color", "$value": "{color.blue-700}" },
      "text": { "$type": "color", "$value": "{color.white}" },
      "padding": { "$type": "dimension", "$value": "{space.400}" }
    }
  },
  "form": {
    "hint": {
      "$type": "color",
      "$value": "{color.grey-500}",
      "$description": "Hint text under form fields"
    }
  }
}
```

Save it as `~/designops-labs/lab2/tokens.json`.

2. Declare the colour pairs that the system allows, and the minimum ratio for each, in `pairs.json`.

_Example status: verified by execution on 2026-10-23._

```json
[
  { "fg": "button.primary.text", "bg": "button.primary.background", "min": 4.5 },
  { "fg": "form.hint", "bg": "color.white", "min": 4.5 }
]
```

3. Save the build script as `build-tokens.mjs`. It implements WCAG 2.2's relative-luminance and contrast-ratio
   definitions.[^wcag22]

_Example status: verified by execution on 2026-10-23 (Node.js 24.22.1)._

```javascript
// Teaching script: resolve DTCG 2025.10 curly-brace aliases, emit CSS custom
// properties, warn on deprecated tokens and fail on WCAG contrast violations.
// Not a conformant DTCG tool (no $ref/JSON Pointer, no $extends, sRGB only).
// Usage: node build-tokens.mjs tokens.json pairs.json > tokens.css
import { readFileSync } from 'node:fs';

const tree = JSON.parse(readFileSync(process.argv[2], 'utf8'));
const pairs = JSON.parse(readFileSync(process.argv[3], 'utf8'));
const tokens = new Map(); // "group.token" -> { raw, type, deprecated }

function walk(node, path, inheritedType) {
  const type = node.$type ?? inheritedType;
  if ('$value' in node) {
    tokens.set(path.join('.'), { raw: node.$value, type, deprecated: node.$deprecated });
    return;
  }
  for (const [key, child] of Object.entries(node)) {
    if (!key.startsWith('$')) walk(child, [...path, key], type);
  }
}
walk(tree, [], undefined);

const warned = new Set();
function resolve(name, chain = []) {
  if (chain.includes(name)) throw new Error(`circular reference: ${[...chain, name]}`);
  const t = tokens.get(name);
  if (!t) throw new Error(`unknown token ${name}`);
  if (chain.length && t.deprecated && !warned.has(chain[0])) {
    warned.add(chain[0]);
    console.error(`WARN ${chain[0]} uses deprecated token ${name}`);
  }
  const m = typeof t.raw === 'string' && t.raw.match(/^\{([^}]+)\}$/);
  return m ? resolve(m[1], [...chain, name]) : t.raw;
}

function css(type, v) {
  if (type === 'color') return v.hex;
  if (type === 'dimension') return `${v.value}${v.unit}`;
  return String(v);
}

// WCAG 2.2 relative luminance and contrast ratio for sRGB components (0..1).
const lin = (c) => (c <= 0.04045 ? c / 12.92 : ((c + 0.055) / 1.055) ** 2.4);
const lum = ({ components: [r, g, b] }) =>
  0.2126 * lin(r) + 0.7152 * lin(g) + 0.0722 * lin(b);
function contrast(a, b) {
  const [hi, lo] = [lum(a), lum(b)].sort((x, y) => y - x);
  return (hi + 0.05) / (lo + 0.05);
}

const lines = [':root {'];
for (const [name, t] of tokens) {
  lines.push(`  --${name.replaceAll('.', '-')}: ${css(t.type, resolve(name))};`);
}
lines.push('}');
console.log(lines.join('\n'));

let failures = 0;
for (const p of pairs) {
  const ratio = contrast(resolve(p.fg), resolve(p.bg));
  const verdict = ratio >= p.min ? 'PASS' : 'FAIL';
  if (verdict === 'FAIL') failures++;
  console.error(`${verdict} ${p.fg} on ${p.bg}: ${ratio.toFixed(2)}:1 (min ${p.min}:1)`);
}
process.exitCode = failures ? 1 : 0;
```

4. Run the build. It should fail.

_Example status: verified by execution on 2026-10-23._

```bash
cd ~/designops-labs/lab2
node build-tokens.mjs tokens.json pairs.json > tokens.css; echo "exit=$?"
```

**Expected output** (standard error, then the exit code):

```text
WARN form.hint uses deprecated token color.grey-500
PASS button.primary.text on button.primary.background: 7.63:1 (min 4.5:1)
FAIL form.hint on color.white: 3.54:1 (min 4.5:1)
exit=1
```

5. Fix the semantic token, not the component: point `form.hint` at `{color.grey-700}` and run again.

_Example status: verified by execution on 2026-10-23 (GNU sed)._

```bash
sed -i 's/"{color.grey-500}"/"{color.grey-700}"/' tokens.json
node build-tokens.mjs tokens.json pairs.json > tokens.css; echo "exit=$?"
grep form-hint tokens.css
```

**Expected output.**

```text
PASS button.primary.text on button.primary.background: 7.63:1 (min 4.5:1)
PASS form.hint on color.white: 7.00:1 (min 4.5:1)
exit=0
  --form-hint: #595959;
```

**Validation.** The ratios match an independent calculation (#888888 on white is 3.54:1, #595959 is 7.00:1, #0851a8 is 7.63:1).
`tokens.css` contains one custom property per token, with aliases resolved. **Troubleshooting.** `unknown token`: an alias names a
token that does not exist (check spelling; group names are part of the path). `circular reference`: two tokens point at each other.
On macOS use `sed -i ''`. **Limits.** As its header says, the script is not a conformant DTCG tool (conformant tools must also
support `$ref` JSON Pointer references). In production, use a maintained
pipeline and keep the contrast gate as a separate check. **Teardown.** `rm -r ~/designops-labs/lab2`.

#### Lab 3 (intermediate): measure design-system coverage in code

**Objective.** Measure how much of a codebase's UI comes from the design-system package, and list what does not.
**Prerequisites.** Node.js 22 or later, npm, network access to the npm registry. **Time.** 30 minutes. **Risk.** Low: `npm audit` reported
six high-severity advisories in react-scanner 1.2.0's transitive glob dependencies (braces, micromatch, picomatch, fast-glob) with
no fix available on 2026-10-23. They concern denial of service or incorrect matching from malicious glob patterns; run the scanner
only on your own code, in a throwaway folder, and never in a production service. react-scanner 1.2.0 was last published in
October 2024, so treat it as a lab tool; for CI, prefer a maintained AST scanner or a small script of your own on the Babel or
TypeScript compiler API.

react-scanner statically analyses JavaScript and TypeScript and extracts React component and prop usage.[^react-scanner]

1. Create a folder, install the scanner and create two sample files. `@acme/ds` is a fictional design-system package.

_Example status: verified by execution on 2026-10-23 (Node.js 24.22.1, npm 11, react-scanner 1.2.0)._

```bash
mkdir -p ~/designops-labs/lab3/src/checkout ~/designops-labs/lab3/src/account
cd ~/designops-labs/lab3
npm init -y > /dev/null
npm install --save-exact react-scanner@1.2.0
cat > src/checkout/Payment.jsx <<'EOF'
import { Button, TextInput } from '@acme/ds';
import FancyButton from '../legacy/FancyButton';

export function Payment() {
  return (
    <form>
      <TextInput label="Card number" />
      <TextInput label="Expiry" />
      <Button variant="primary">Pay</Button>
      <FancyButton>Cancel</FancyButton>
    </form>
  );
}
EOF
cat > src/account/Profile.jsx <<'EOF'
import { Button, Card } from '@acme/ds';

export function Profile() {
  return (
    <Card>
      <h2>Profile</h2>
      <Button variant="secondary">Edit</Button>
      <button className="link-btn">Sign out</button>
    </Card>
  );
}
EOF
cat > raw.config.js <<'EOF'
module.exports = {
  crawlFrom: './src',
  includeSubComponents: true,
  processors: [['raw-report', { outputTo: './raw.json' }]],
};
EOF
npx react-scanner -c raw.config.js
```

2. Save the post-processor as `coverage.mjs`. It defines coverage as design-system instances divided by design-system instances
   plus custom components plus native controls; structural HTML such as `div` and `h2` is ignored.

_Example status: verified by execution on 2026-10-23 (Node.js 24.22.1)._

```javascript
// Design-system coverage from a react-scanner raw report.
// coverage = DS instances / (DS instances + custom components + native controls)
// Usage: node coverage.mjs raw.json @acme/ds
import { readFileSync } from 'node:fs';

const report = JSON.parse(readFileSync(process.argv[2], 'utf8'));
const dsPackage = process.argv[3];
const NATIVE_CONTROLS = new Set(['button', 'input', 'select', 'textarea', 'a']);
const tally = { ds: 0, custom: 0, native: 0 };
const offenders = new Map();

for (const [name, { instances }] of Object.entries(report)) {
  for (const inst of instances) {
    const from = inst.importInfo?.moduleName;
    let kind = null;
    if (from === dsPackage || from?.startsWith(`${dsPackage}/`)) kind = 'ds';
    else if (/^[A-Z]/.test(name)) kind = 'custom';
    else if (NATIVE_CONTROLS.has(name)) kind = 'native';
    if (!kind) continue; // structural HTML such as div, form, h2
    tally[kind]++;
    if (kind !== 'ds') {
      const key = `${kind}:${name}`;
      offenders.set(key, (offenders.get(key) ?? 0) + 1);
    }
  }
}

const total = tally.ds + tally.custom + tally.native;
const pct = total ? ((100 * tally.ds) / total).toFixed(1) : 'n/a';
console.log(`DS instances ${tally.ds}, custom ${tally.custom}, native ${tally.native}`);
console.log(`Coverage: ${tally.ds}/${total} = ${pct}%`);
for (const [key, n] of [...offenders].sort((a, b) => b[1] - a[1])) {
  console.log(`  not from DS: ${key} x${n}`);
}
```

3. Run it.

_Example status: verified by execution on 2026-10-23._

```bash
node coverage.mjs raw.json @acme/ds
```

**Expected output.**

```text
DS instances 5, custom 1, native 1
Coverage: 5/7 = 71.4%
  not from DS: native:button x1
  not from DS: custom:FancyButton x1
```

**Validation.** Count by hand: `Payment.jsx` has two `TextInput` and one `Button` from `@acme/ds` plus a local `FancyButton`;
`Profile.jsx` has a `Card` and a `Button` from `@acme/ds` plus a native `<button>`: 5 of 7. **Interpretation.** The two offenders
are the backlog: is `FancyButton` a missing variant, or a local exception? Is the native sign-out button styled as a link because
the system lacks a link-style button? **Troubleshooting.** `Scanned 0 files`: check `crawlFrom` and that files end in `.js`, `.jsx`,
`.ts` or `.tsx` (the default glob excludes `.test` and `.spec` files).[^react-scanner] Re-exported components (a product wrapper
around a system component) count as custom; decide whether wrappers should count and document the rule. **Teardown.**
`rm -r ~/designops-labs/lab3`.

#### Lab 4 (advanced, tabletop): decide a contribution

**Objective.** Practise a governance decision with evidence. **Prerequisites.** Read the [contribution playbook](#playbook-contribution-and-governance).
**Time.** 45 minutes with three people (system lead, product designer, engineer). **Risk.** None. Not executable; there is no
expected program output.

::: example Illustrative scenario: the "stepper" proposal
The payments team proposes a multi-step progress indicator ("stepper"). Evidence: screenshots of four different steppers in four
products; one usability test of the payments version with six participants, none of whom used assistive technology; the code is
React-only, while two of the four products are native mobile apps. A similar "progress bar" component already exists in the system.
:::

1. Apply the proposal criteria (useful, unique) and write one sentence for each.
2. Apply the publication criteria (usable, consistent, versatile) and list the missing evidence.
3. Decide: reject, extend the progress bar, accept as a proposal with conditions, or release as trial.
4. Write a decision record using the [template](#templates), including what the payments team does this sprint.

**Expected output.** A decision record. A defensible answer: *useful* is met (four products built their own); *unique* is doubtful
until the team shows why the progress bar cannot be extended; *usable* is not yet met (no participants using assistive technology);
*versatile* is not met (React only, two native consumers). Decision: accept the proposal, investigate extending the progress bar
first, and let the payments team ship its local version with a ticket. **Validation.** Another group given the same evidence should
reach a similar decision from your record alone. **Teardown.** File the record; delete scratch notes.

### Use cases and scenarios

The first case is documented public practice; the others are **illustrative scenarios** built from the practices on this page,
not reports about real companies.

**1. A design system run by contribution (documented: GOV.UK).** The GOV.UK Design System serves many teams across government. It
publishes contribution criteria with evidence requirements at proposal and publication stages,[^govuk-criteria] labels new components
"Trial" and promotes them after six months without negative feedback,[^govuk-lifecycle] and invites anyone to suggest improvements,
with community discussions, research sessions and help to "upstream" work teams have already built.[^govuk-community] The lesson for
other organisations: written criteria and visible lifecycle states let a small central team accept work from many contributors
without becoming a bottleneck. Pitfall: criteria such as "tested with a representative sample including disabled users" take time;
contributors need a way to ship locally meanwhile.

**2. A design team growing from 15 to 45 designers (illustrative).** Symptoms at 25 designers: requests arrive in chat; two squads
share one designer; critique has become a status meeting; three senior designers leave because the only promotion path is
management. Method: a design program manager is hired first (not a system team); one intake form; a quarterly capacity plan that
caps designers at two initiatives; separate critique and review; an individual-contributor ladder up to principal level, calibrated
twice a year. Trade-off: product managers lose the ability to ask designers directly for small changes; give them a fast lane for
requests under two days. Success: median request cycle time falls; regretted attrition falls; a pulse survey shows more time on
design work.

**3. Multi-brand theming after an acquisition (illustrative).** Two products with different brands must share one component set.
Method: split tokens into primitives (each brand's palette), semantic tokens (`button.primary.background`) and brand modes; components
use semantic tokens only; contrast pairs are tested per brand mode (Lab 2's gate run once per mode). Trade-off: the refactor gives no
visible benefit for a quarter; the second brand's palette may need adjusting to pass contrast. Success: a new screen ships in both
brands from one implementation; brand-specific overrides in product code trend to zero.

**4. Accessibility remediation in an EAA-scope service (illustrative).** An audit of a European e-commerce checkout lists 120
findings. Method: classify each finding by where the fix belongs: token (contrast), component (focus, names, target size), pattern
(error handling), or page (content, headings). Fix tokens and components in the system first, release, and track how many findings
each release closes; teams fix page-level findings themselves. Trade-off: system releases need consumers to upgrade before findings
close, so upgrade lag becomes the critical path. Success: share of findings closed by system releases; zero new findings of the same
class in later audits. Legal scope and deadlines need advice for the specific service and country.

## Measure, govern, pay

### Metrics and KPIs

Choose a few metrics that answer leaders' questions, and pair each with a qualitative check. HEART's Goals–Signals–Metrics process
(set the goal, find the signal, then define the metric) works for design-system outcomes as well as product features.[^heart]

| KPI | Definition and formula | Data source | Pitfall | Cadence |
|---|---|---|---|---|
| Code coverage of the system | System instances ÷ (system + custom + native controls), per app | Code scans (Lab 3) | Wrappers and re-exports distort counts; define the rule | Monthly |
| Detach rate | Detachments ÷ insertions per component, over a window | Design-tool analytics (Lab 1) | Drafts and nested components may be missing;[^figma-analytics] some detaches are intended (Lab 1) | Monthly |
| Upgrade lag | Days from a system release to adoption in each consuming app; report median and worst | Package manifests, dependency bots | One abandoned app skews the mean | Per release |
| Time to decision on contributions | Days from proposal to recorded decision | Decision records | Fast "no" without reasons | Monthly |
| Accessibility gate pass rate | Passing system builds ÷ all builds; audit findings traced to system components | CI, audits | Gates only cover what they test | Per release, per audit |
| Request cycle time | Days from accepted request to design acceptance | Intake tool | Mixing two-day fixes with two-month projects; report by size | Monthly |
| Capacity on top priorities | Designer-weeks on top-N priorities ÷ available designer-weeks | Capacity plan | Plans that do not match reality | Quarterly |
| Design-team health | Regretted attrition; promotions by level and group; pulse-survey items on time for craft | HR data, surveys | Small teams: protect individuals with minimum group sizes | Quarterly |

**Leading vs lagging.** Detach rate, decision time and upgrade lag are leading signals; coverage, audit findings and attrition lag.

**Vanity traps.** Components shipped (see [Anti-patterns](#anti-patterns-and-myths)); raw insert counts, which rise with headcount;
"coverage 100%", which may mean a wrapper hides custom code.

#### Worked calculation: a quarterly scorecard

Illustrative numbers for one quarter in the 40-designer organisation used above:

- **Coverage.** A scan of the checkout app finds 1,140 system instances, 210 custom components and 150 native controls:
  1,140 ÷ (1,140 + 210 + 150) = 1,140 ÷ 1,500 = **76.0%**, up from 71.0% last quarter.
- **Detach rate.** The modal had 290 insertions and 87 detachments: 87 ÷ 290 = **30.0%**, above an investigation threshold of 25%.
  Interviews show teams need a footer slot; the next minor release adds it.
- **Upgrade lag.** Release 3.4.0 shipped on 1 July. Seven apps adopted it after 6, 9, 12, 14, 20, 41 and 63 days: median **14 days**,
  worst 63 (an app without an active team; escalate ownership rather than the median).
- **Capacity.** 40 designers × 12 weeks = 480 designer-weeks; minus 10% leave and holidays (48) and 15% rituals, critique and system
  contribution (72) = 360 available; top-five priorities consumed 252: 252 ÷ 360 = **70%**.

What to do with it: the coverage trend and the modal fix go to the product leadership review; the 63-day upgrade lag becomes an
ownership question for engineering leaders; capacity at 70% on top priorities is presented with the list of what the other 30% was.

### Quality, accessibility, privacy and security

- **Accessibility** is the main compliance exposure DesignOps influences; see the [accessibility playbook](#playbook-accessibility-built-into-the-system)
  for standards and dated legal orientation.
- **Quality.** Visual regressions are caught by screenshot comparison; behavioural regressions by component tests; both run in CI
  before a release.
- **Privacy.** Design files, research clips and prototypes often contain real customer data copied from production. Rule: synthetic
  or anonymised data in design files; research recordings stay in the research repository under [ResearchOps](../researchops/)
  controls. Usage telemetry about designers (who detaches what) is for improving the system, not for performance reviews.
- **Security.** Package publishing credentials belong to protected release jobs, not to every contributor; tokens and component
  packages are part of the software supply chain, so apply the same review, signing and dependency hygiene as other packages (see
  [DevSecOps](../devsecops/)); the same holds for AI agents with write access ([Automation and AI](#automation-and-ai)).
- **Licences.** Fonts, icon sets and illustration libraries carry licences that may not allow embedding in apps or redistribution in
  open-source packages. Keep a licence register.

### Cost, capacity and sustainability

The main costs are **people** (system team, design program managers), **tool seats** (some features are plan- or seat-gated, as
noted above) and **consumer effort** (upgrades and migrations). The main benefit claimed for design systems is designer and engineer
time saved, but the evidence is thin and should be stated carefully.

The most-cited figure comes from Figma: in a 2019 study with its own designers working on two constructed tasks, participants with a
design system "completed their objective 34% faster" than without one. The post does not report the sample size, and its author
treats 34% as an upper bound because the system was perfectly relevant to the tasks.[^figma-study]

#### Worked calculation: is a three-person system team worth it?

Illustrative assumptions, stated so they can be challenged:

- 40 product designers spend 50% of their time on work where the system is relevant.
- Assume a **10%** saving on that work (well below Figma's 34% upper bound, because real systems are partly relevant and partly
  out of date).
- Saving: 40 × 0.5 × 0.10 = **2.0 designer-equivalents** per year.
- Cost: a system team of 3 (one designer, two engineers) = **3.0 people**.

On design time alone the team does not pay for itself. It pays only if engineering savings, accessibility risk avoided, or rebrand
and theming costs avoided are added; for example, if 60 front-end engineers save 5% of their time (60 × 0.05 = 3.0), the total is
5.0 people-equivalents against 3.0 people. **The decision rests on assumptions you must measure** (Lab 3's coverage, cycle times
before and after) rather than on a vendor percentage. For a team of five designers on one product, the same arithmetic usually
favours adopting an existing open-source system over building one, which matches NN/g's advice to build a custom system only when
existing ones cannot meet your needs.[^nng-ds101]

**Capacity.** Reserve explicit system-contribution time in product designers' capacity (worked above), or contributions never
happen.

**Sustainability.** Design choices affect page weight (images, fonts, motion) and therefore energy use; a system can set budgets
for font families and image formats. This page does not quantify the effect; [GreenOps](../greenops/) covers measurement.

### Assurance of the operating model

How do you know DesignOps itself works?

- **Feedback loops.** A short consumer survey after each quarter (designers and engineers): is the system helping, what blocks you?
- **Exception monitoring.** Count local workarounds with tickets; a rising count means the system is not keeping up.
- **Decision audit.** Sample five contribution decisions per quarter: was the record complete, was the time to decision within the
  target?
- **Drift checks.** Compare token values in the design tool and the code packages after each release.

::: figure The DesignOps measurement loop
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 16, "rankSpacing": 26, "padding": 8}}}%%
flowchart TB
  G["Goal: e.g. consistent checkout UI"] --> S["Signals: detaches, scans, gaps, surveys"]
  S --> M["Metrics: coverage, detach rate, upgrade lag"]
  M --> R["Monthly review with consumers"]
  R --> A{"Action needed?"}
  A -->|"component gap"| B["Backlog: fix, variant, or pattern"]
  A -->|"process friction"| P["Change intake, critique or release cadence"]
  A -->|"no"| K["Keep; check the metric is still useful"]
  B --> REL["Release and announce"]
  P --> REL
  REL --> S
  K --> G
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class G,S,M,R core
  class A decision
  class B,P,K,REL neutral
```
Text equivalent: A goal (for example a consistent checkout UI) defines the signals to watch: detaches, code scans, gap reports and
surveys. Signals become metrics such as coverage, detach rate and upgrade lag, which are reviewed monthly with consumers. The review
decides whether action is needed: a component gap goes to the backlog as a fix, variant or pattern; process friction changes intake,
critique or release cadence; both lead to a release and announcement that feeds new signals. If no action is needed, the team keeps
the metric but checks that it is still useful against the goal.
:::

## When things go wrong

### Common failures and troubleshooting

| Symptom | Likely cause | Diagnosis | Remediation | Prevention |
|---|---|---|---|---|
| Teams build their own versions of system components | System missing variants, or slow to respond | Lab 3 offenders list; interview two teams | Fast path for gap reports; add variants | Office hours; time-to-decision target |
| High detach rate on one component | Missing slot or variant, or a component meant to be detached | Lab 1 per component; look at detached copies | Add the variant, or document the detach as intended | Review detach rates monthly |
| Design and code libraries disagree | Manual sync, edits in one place only | Diff token values design tool vs package | Make one side the source; automate sync | Drift check in each release |
| Apps stuck on old versions | Breaking changes in minors; no migration help; no owner | Upgrade lag per app | Codemods, migration guides, pairing | Strict semver; deprecation windows |
| Accessibility regressions after a release | Token change without contrast gate; untested component behaviour | Which release introduced it (changelog, bisect) | Patch release; see runbook below | Gates for pairs and components |
| Designers overloaded; quality drops | No intake, no capacity plan | Count initiatives per designer | Triage; show trade-offs to product leaders | Capacity cap per designer |
| Critique feels like judgement | Critique and review mixed; no facilitation | Ask attendees; watch who speaks | Separate critique from review; rotate facilitator | Critique guide; scope stated first |
| DesignOps seen as bureaucracy | Steps that save the team less than they cost | Time each step; survey consumers | Remove or automate steps | Quarterly process-cost review |

### Worked runbook: a token release broke contrast in production

::: example Illustrative incident
Release 4.2.0 of a design system changed `color.grey-500` to a lighter value as part of a palette refresh. Two days later, support
tickets reported that form hints were hard to read; an internal audit confirmed hint text on white at 3.5:1 in three apps.
:::

::: figure Runbook for a design-system release that causes an accessibility regression
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 16, "rankSpacing": 24, "padding": 8}}}%%
flowchart TB
  A["Report: hint text hard to read"] --> B["Confirm: measure contrast in affected apps"]
  B --> C{"Caused by a system release?"}
  C -->|"no"| X["Route to the product team that owns the page"]
  C -->|"yes"| D["Identify release and token (changelog, diff)"]
  D --> E{"Fix by remapping a semantic token?"}
  E -->|"yes"| F["Patch release: remap token, gate passes"]
  E -->|"no"| G["Patch release reverting the value"]
  F --> H["Notify consumers; track upgrade per app"]
  G --> H
  H --> I["Post-incident: add the missing pair to the gate"]
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  class A,B risk
  class C,E decision
  class D,F,G,H,I,X core
```
Text equivalent: A report says hint text is hard to read. The team confirms by measuring contrast in the affected apps, then asks
whether a system release caused it. If not, the issue goes to the product team that owns the page. If yes, the team identifies the
release and token from the changelog and diff, then asks whether remapping a semantic token fixes it. If yes, a patch release remaps
the token and the gate passes; if not, a patch release reverts the value. Either way consumers are notified and upgrades are tracked
per app, and the post-incident review adds the missing colour pair to the contrast gate.
:::

1. **Confirm and size (first hour).** Measure the failing pair (the Lab 2 formula, or a contrast checker) in each reported app;
   list affected components and apps. Severity is high for text that fails 4.5:1 in a core flow.
2. **Find the cause.** Diff token values between 4.1.x and 4.2.0. Here: `color.grey-500` became lighter, and `form.hint` aliases it.
   The gate did not catch it because `form.hint` on white was not in the declared pairs.
3. **Choose the fix.** Prefer remapping the *semantic* token (`form.hint` → `color.grey-700`) over reverting the palette, so the
   refresh can stay. Run the gate with the new pair added.
4. **Release a patch** (4.2.1): a fix that restores intended behaviour is a PATCH under semver.[^semver] Release notes say what
   happened, which apps should upgrade, and that no code change is needed.
5. **Help consumers.** Open upgrade tickets for each affected app; for apps that cannot upgrade this week, provide a one-line CSS
   override with an expiry date.
6. **Close.** Verify contrast in each app after upgrade; record time to detect, time to patch, time to full upgrade.
7. **Prevent.** Add every semantic text token on every background it is documented for to `pairs.json`; require gate output in
   release review; add a check that fails when a new semantic colour token has no declared pair.

**Rollback.** If the patch itself causes problems, consumers pin 4.1.x; the system team publishes a 4.2.2 that reverts both changes.

### Anti-patterns and myths

| Anti-pattern or myth | Why it is tempting | What goes wrong | Instead |
|---|---|---|---|
| "DesignOps = design system" | The system is visible and buildable | People problems (overload, no career path) remain and talent leaves | Cover both halves; start from the pain survey |
| Building a custom system on day one | Brand pride; it feels strategic | Years of maintenance for a small team; NN/g advises custom systems only when existing ones cannot meet your needs[^nng-ds101] | Adopt and theme an existing system; customise later |
| The overlord system team | One product's team owns it "for everyone" | Curtis: other teams' needs become distractions; "Overlords don't scale"[^curtis-models] | Central team with federated contributors |
| Governance as approval | Control feels safe | Teams detach and fork rather than wait | Criteria, decision deadlines, ticketed local workarounds |
| Measuring components shipped | Easy to count | Rewards unused components | Coverage, detach rate, upgrade lag, cycle time |
| Using telemetry to rate designers | Data is there | Designers stop using the library honestly | Telemetry for the system, not for performance |
| "Automation makes it accessible" | Gates are green | Automated checks find only part of the issues (see the [accessibility playbook](#playbook-accessibility-built-into-the-system)) | Gates plus assistive-technology testing with people |
| Critique as a status meeting | Leaders want visibility | No learning; work arrives late | Separate critique from review |
| Breaking changes in minor releases | Shipping fast | Consumers stop upgrading | Semver, deprecation windows, codemods |

## Deciding and adopting

### When to use it and when not to

**Invest in DesignOps (as a practice) when** several of these are true: more than one product team depends on design; designers
report spending significant time on logistics or rework; the same component exists in several versions; accessibility findings
repeat; designers leave for lack of growth; leaders cannot say what design delivers.

**Create dedicated roles when** the practice no longer fits in design managers' time. NN/g notes that not every organisation needs
dedicated DesignOps roles, and that teams with substantial, rapid growth may benefit most from one.[^nng-faq] A common first hire is a
design program manager; a design-system team comes when coverage and consistency, not capacity, are the main pain.

**Do not** (yet):

- Build a custom design system for a prototype or a product likely to change direction; NN/g says a full system is unlikely to pay
  off in that case.[^nng-ds101]
- Hire a DesignOps manager for three designers on one product: adopt habits (critique, intake, an off-the-shelf system) instead.
- Add process to a team that ships well and is not growing.

**Hidden responsibilities.** A design system is never finished: Frost quotes Airbnb's Alex Schleifer that "the biggest existential
threat to any system is neglect".[^frost-ch5] Budget for maintenance, support and migrations for as long as products use it.

### Decision framework

::: figure Decision tree: what DesignOps investment fits your situation
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 14, "rankSpacing": 24, "padding": 8}}}%%
flowchart TB
  A{"More than one product team relies on design?"}
  A -->|"no"| N["Habits only: critique, intake list, existing open-source system"]
  A -->|"yes"| B{"Main pain is people and flow, or consistency?"}
  B -->|"people and flow"| C["First hire: design program manager"]
  B -->|"consistency, accessibility"| D{"Can an existing system be themed to fit?"}
  D -->|"yes"| E["Adopt and theme; small system team"]
  D -->|"no"| F["Custom system as a funded product"]
  B -->|"both"| G["Program manager first, then system team"]
  C --> H["Review in two quarters with metrics"]
  E --> H
  F --> H
  G --> H
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class A,B,D decision
  class C,E,F,G core
  class N,H neutral
```
Text equivalent: First question: does more than one product team rely on design? If not, adopt habits only: critique, an intake
list and an existing open-source system. If yes, ask whether the main pain is people and flow, consistency and accessibility, or
both. People and flow: hire a design program manager first. Consistency: ask whether an existing system can be themed to fit; if
yes, adopt and theme it with a small system team; if not, build a custom system as a funded product. Both: program manager first,
then a system team. Every path ends in a review after two quarters with metrics.
:::

A weighted comparison helps when the choice is between adopting an existing system and building one. Score each option 1–5 per
criterion and multiply by the weight; the weights are this page's illustration, not a standard.

| Criterion | Weight | Adopt and theme (example scores) | Build custom (example scores) |
|---|---|---|---|
| Fit to brand and interaction needs | 0.25 | 3 | 5 |
| Accessibility maturity on day one | 0.20 | 4 | 2 |
| Time to first value | 0.20 | 5 | 2 |
| Long-term maintenance cost | 0.20 | 4 | 2 |
| Control over roadmap | 0.15 | 2 | 5 |
| **Weighted total** | 1.00 | **3.65** | **3.20** |

Adopt: 0.25×3 + 0.20×4 + 0.20×5 + 0.20×4 + 0.15×2 = 0.75 + 0.80 + 1.00 + 0.80 + 0.30 = 3.65. Build: 1.25 + 0.40 + 0.40 + 0.40 + 0.75
= 3.20. The weights decide the answer: with brand fit at 0.45, accessibility and time to value at 0.10 each, and the rest unchanged,
adopt scores 1.35 + 0.40 + 0.50 + 0.80 + 0.30 = 3.35 and build scores 2.25 + 0.20 + 0.20 + 0.40 + 0.75 = 3.80. Agreeing the weights
with leaders is the real decision.

### Maturity model

This is **this Atlas's model**, not an official one; NN/g's survey asked respondents to self-rate maturity on five levels but this
page does not reproduce its definitions.[^nng-maturity]

::: figure Maturity progression (Atlas model) with the main exit criterion for each level
```mermaid
%%{init: {"flowchart": {"wrappingWidth": 120, "nodeSpacing": 14, "rankSpacing": 22, "padding": 8}}}%%
flowchart TB
  L1["1 Ad hoc: heroes and chat requests<br/>Exit: 90% of requests via intake; 1 library"] --> L2
  L2["2 Organised: intake, critique, shared library<br/>Exit: 3 releases with gates; 0 breaking minors"] --> L3
  L3["3 Systematic: system run as a product<br/>Exit: 2 quarterly scorecards with decisions"] --> L4
  L4["4 Measured: outcomes tied to product goals<br/>Exit: 2 quarters with a change traced to a metric"] --> L5
  L5["5 Adaptive: continuous improvement"]
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  class L1,L2 neutral
  class L3,L4,L5 core
```
Text equivalent: Five levels from top to bottom. Level 1, ad hoc: heroes and requests by chat; exit when 90% of requests arrive
through the intake and one shared library remains. Level 2, organised: intake, critique and a shared library; exit after three
consecutive releases that passed the contrast and accessibility gates with no breaking change in a minor release. Level 3,
systematic: the design system is run as a product; exit after two quarterly scorecards that each led to a recorded decision.
Level 4, measured: outcomes are tied to product goals; exit after two consecutive quarters in which a process change was traced to
a metric and the metric moved. Level 5, adaptive: continuous improvement, held by removing at least one process step a quarter.
The full criteria are in the table below.
:::

| Level | Observable behaviour | Evidence | Measurable exit criterion (illustrative thresholds) |
|---|---|---|---|
| 1 Ad hoc | Requests by chat; several libraries; reviews depend on the manager | No intake records; duplicated components | At least 90% of requests over one month arrive through the intake; one shared library, others archived |
| 2 Organised | Intake and critique run; one shared library; onboarding plan | Intake log, critique notes | Tokens in version control; three consecutive releases pass the contrast and a11y gates; no breaking change in a minor release |
| 3 Systematic | Releases with semver; contrast and a11y gates; contribution criteria; career framework | Changelog, gate output, decision records | 4–6 metrics with owners; two consecutive quarterly scorecards each lead to at least one recorded decision; median time to decision on contributions within its target |
| 4 Measured | Scorecard reviewed with product leaders; capacity plan drives trade-offs | Quarterly scorecards with decisions | Two consecutive quarters in which at least one process change is traced to a metric and that metric moved in the intended direction |
| 5 Adaptive | Operating model changes in response to data; system evolves with products | Process changes traced to metrics; process-cost reviews | Not an end state: stay here only while each quarterly review removes or automates at least one step and the scorecard holds |

### Adoption roadmap: 30/60/90 days

For an organisation at level 1–2 starting a DesignOps practice with one dedicated person (illustrative).

| Window | Actions | Owner | Milestone and metric |
|---|---|---|---|
| Days 1–30 | Listening tour with designers, PMs, engineers; survey time spent on non-design work; inventory libraries, duplicate components and open accessibility findings; set up one intake form | DesignOps lead | Pain report with top three problems; baseline request cycle time |
| Days 31–60 | Weekly triage and capacity plan; separate critique from review; choose: adopt and theme an existing system, or consolidate yours; put tokens in version control with a contrast gate (Lab 2) | DesignOps lead, design leader, one engineer | Capacity plan published; first token release; gate in CI |
| Days 61–90 | Publish contribution criteria and lifecycle labels; first coverage scan (Lab 3) and detach report (Lab 1); draft career framework; first scorecard to leaders | DesignOps lead, system team, design leader | Scorecard v1 with 4–6 metrics; decision on system funding for the next two quarters |

Quick wins: one intake form, a critique guide, and fixing the three most-detached components. Dependencies: engineering time for
tokens and packages; a leader willing to make trade-offs visible.

## Toolkit

### Checklists

**Quick start (first month)**

- [ ] Listening tour done; top three pains written down with evidence
- [ ] One intake form; chat requests redirected
- [ ] Critique and review separated on the calendar
- [ ] Inventory of libraries, duplicate components and open accessibility findings
- [ ] A decision on the system: adopt and theme, consolidate, or build

**Design-system release readiness**

- [ ] Version number follows semver; breaking changes only in a major
- [ ] Deprecations announced at least one minor release earlier, with migration guide
- [ ] Contrast gate passes for every declared pair, in every mode
- [ ] Component accessibility tests pass; manual assistive-technology check for changed components
- [ ] Visual comparison reviewed; intended changes approved
- [ ] Design library and code tokens match (drift check)
- [ ] Release notes say what consumers must do

**Handoff (definition of ready for development)**

- [ ] All states designed: empty, loading, error, disabled, focus, hover
- [ ] Responsive behaviour and content rules defined
- [ ] Accessibility notes: headings, labels, focus order, announcements
- [ ] System components linked, not copied; gaps reported
- [ ] Outcome metric agreed with the product team

**Quarterly review**

- [ ] Scorecard updated; each metric has an owner and an action
- [ ] Capacity plan reconciled with what actually happened
- [ ] Process cost reviewed; at least one step removed or automated
- [ ] Upgrade lag outliers escalated to their owners
- [ ] Career framework and calibration outcomes checked for equity

**Governance audit**

- [ ] Decision records exist for every contribution decided this quarter
- [ ] Publishing credentials limited to protected release jobs
- [ ] Font, icon and illustration licences registered
- [ ] No real customer data in shared design files

### Templates

**1. DesignOps charter (one page).**

```text
DesignOps charter — <organisation>, version <n>, <date>
Mission:      <one sentence: what designers and product teams get>
Scope:        team operations | design system | tooling | measurement
Not in scope: research logistics (ResearchOps); words (ContentOps); pipelines
Services:     intake and capacity; critique programme; design system releases;
              onboarding; career framework; scorecard
Customers:    designers; product managers; front-end and mobile engineers
Principles:   serve, do not gate; system is a product; a11y built in; semver
Metrics:      coverage; detach rate; upgrade lag; request cycle time; health
Cadences:     weekly triage and critique; release train every <n> weeks;
              monthly system review; quarterly scorecard
Escalation:   blocked teams ship a ticketed workaround; answer within 2 days
Owner:        <name, role>          Review: yearly
```

**2. Design request intake form.**

```text
Title:
Requester and team:
Problem (who is affected, what is hard for them today):
Outcome (what changes and how we will measure it):
Evidence (data, research, support tickets):
Deadline and why it is fixed (or "flexible"):
Scope guess: small (< 2 days) | medium (< 2 weeks) | large
Dependencies (engineering, content, legal, research):
Existing system components that might fit:
--- triage (DesignOps) ---
Decision: accept | decline | redirect to <where>   Size: <designer-weeks>
Assigned designer:            Expected start:          Reason if declined:
```

**3. Contribution decision record.**

```text
DR-<number>: <component or change>             Date:          Status:
Proposed by:                 Consumers affected:
Evidence of need (useful):   <products, screenshots, tickets>
Uniqueness check:            <existing components considered and why not>
Research and testing:        <participants incl. assistive technology users>
Platforms:                   <web | iOS | Android | ...>
Decision:                    reject | extend <component> | trial | stable
Conditions and owner:
Interim for requester:       <local workaround ticket, expiry date>
Version impact:              patch | minor | major
Review date:
```

**4. Release note.**

```text
<package> <version> — <date>
Who must act:     <apps or "no action needed">
Breaking:         <list or "none">
Deprecated:       <item> → use <replacement>; removal planned in <major>
Added / Fixed:    <items>
Accessibility:    <gate results; manual checks done>
Migration:        <codemod command or guide link>
```

**5. Quarterly DesignOps scorecard.**

| Metric | Last quarter | This quarter | Target | Owner | Action |
|---|---|---|---|---|---|
| Coverage (key app) | 71.0% | 76.0% | 80% | System lead | Fix modal footer slot |
| Median upgrade lag | 21 days | 14 days | 14 days | System lead | Escalate one ownerless app |
| Request cycle time (medium) | 15 days | 12 days | 10 days | Program manager | Fast lane for small requests |
| Capacity on top priorities | 62% | 70% | 75% | Program manager | Present the other 30% |
| Regretted attrition (rolling 12 months) | — | — | Down | Design leader | Promotion calibration |

### Deep comparisons

| Approach | Strengths | Weaknesses | Choose when |
|---|---|---|---|
| No DesignOps function (habits only) | No overhead | Does not scale beyond a few designers | One product, small team |
| Design program manager only | Fixes intake, capacity, rituals quickly | Consistency problems remain | People and flow are the pain |
| Design-system team only | Fixes consistency and accessibility | Team health ignored; system may lack product context | Many products, manageable team size |
| Full DesignOps (both halves) | Covers people, process and craft | Most expensive; risk of bureaucracy | Large or fast-growing design organisation |

For the neighbouring disciplines, see the [ownership table](#how-designops-relates-to-other-ops).

### FAQ

**Is DesignOps just a new name for design management?** No. Design management covers leading designers and the quality of their
work; DesignOps builds the operational system (intake, tooling, the design system, rituals, measurement) that lets that management
scale. In small organisations the same person does both.

**Do we need a design system to do DesignOps?** No (see [What DesignOps is not](#what-designops-is-not)). Many teams start with
intake, critique and capacity, and adopt an existing system.

**Should the design-system team report to design or engineering?** Either works if both disciplines are on the team and the
roadmap serves both designers and engineers. Report it where funding is most stable; the failure mode is a system that serves only
one side.

**How do we stop teams detaching components?** Do not stop them; learn from them. Interview the teams behind the highest detach
rates (Lab 1), add the missing variants, and document intended detaches.

**Is DTCG 2025.10 a W3C standard?** No. It is a stable Community Group report, not on the W3C Standards Track (see the
[standards table](#methods-standards-and-frameworks)), and still the best vendor-neutral target available.

**Does passing automated accessibility tests mean we meet WCAG?** No. Automated checks find a share of the issues, not a share of
the success criteria (the [accessibility playbook](#playbook-accessibility-built-into-the-system) explains the often-quoted 57%);
the rest needs manual and assistive-technology testing.

**Can AI replace the design-system team?** Not on current evidence. AI tools can draft code from designs and can write to design
files,[^figma-mcp] but the decisions that make a system valuable (what belongs in it, what breaks consumers, what is accessible in
practice) still need people, review and gates.

## Going further

### Advanced topics and emerging direction

- **Established capability:** tokens as code with platform outputs; semver releases; contrast and axe-based gates; usage analytics.
- **Maturing (2025–2026):** DTCG 2025.10 with theming and modern colour spaces,[^dtcg-stable] still unevenly supported by tools (see
  the [token-pipeline comparison](#token-pipelines-compared-as-of-october-2026)); design-to-code links; accessibility annotations.
- **Active and uncertain:** AI agents that generate UI or write back into libraries (canvas writing is in beta as of October
  2026[^figma-mcp]); the open questions are review, provenance and who owns an agent's change.
- **Measurement research:** moving from usage counts to outcomes with frameworks such as HEART;[^heart] evidence on the return of
  design systems remains thin, and vendor studies are upper bounds.[^figma-study]

### Learning path

| Stage | Goal | Activities |
|---|---|---|
| Prerequisites | Basic vocabulary | Read [What DesignOps is](#what-designops-is) and the glossary; know what CSS variables and npm packages are |
| 1-day primer | See the whole field | NN/g's DesignOps 101 and FAQ;[^nng-101][^nng-faq] this page's [operating model](#operating-model-and-governance); run Lab 1 |
| 1-week practice | Hands-on with the system half | Labs 2 and 3; read the DTCG format introduction;[^dtcg-format] WCAG 2.2 contrast and target-size criteria[^wcag22] |
| 30-day progression | Run something real | Listening tour and pain report; intake form; critique guide; one token release with a gate |
| Advanced specialisation | Pick a track | Design-system engineering (token pipelines, multi-platform); design program management (capacity, portfolio); design leadership (career frameworks, org design) |
| Portfolio projects | Show evidence | A coverage report with a backlog; a contribution decision record; a scorecard with before/after numbers |

Leaders can stop after [Deciding and adopting](#deciding-and-adopting); practitioners should complete the labs; architects should
focus on the [reference architecture](#reference-architecture-the-design-system-supply-chain) and the release playbook.

## Wrap-up

### Executive recap and cheat sheet

| Topic | Remember |
|---|---|
| Definition | People, processes and craft, orchestrated to amplify design's value at scale (NN/g) |
| Two halves | Run the design team and run the design system as a product |
| First move | Listening tour and pain survey; one intake; separate critique from review |
| System decision | Adopt and theme before building custom |
| Tokens | DTCG 2025.10 JSON in version control; semantic tokens over primitives |
| Releases | Semver; deprecate before removing; release notes say what to do |
| Accessibility | Gates for contrast and components, plus testing with people; WCAG 2.2 AA target |
| Metrics | Coverage, detach rate, upgrade lag, request cycle time, team health |
| Watch-outs | Gatekeeping; components-shipped metrics; telemetry used against designers; neglect |
| Next action | Run Lab 3 on your main app and bring the offenders list to the next review |

### A judgement call: fund a custom design system or adopt an open-source one?

::: example Illustrative dilemma
A fintech with 22 designers, 9 product teams, a web app and two native apps is rebranding. The design leader wants a custom system
("our brand is our differentiator"). The engineering director wants to adopt and theme a mature open-source React library ("we
cannot staff another product"). Budget allows three new hires.
:::

**Assumptions.** The open-source library covers about 70% of needed components and has documented accessibility behaviour; it
offers no native mobile components; the brand team's requirements are mostly visual (colour, type, shape, motion), not new
interaction patterns.

**Option A: build custom.** Full control and brand fit; but three hires would be building basics (buttons, inputs, dialogs) for a
year, accessibility maturity starts from zero, and native apps still need their own components either way.

**Option B: adopt and theme.** Faster; accessible basics on day one; but theming limits may block parts of the brand, and the team
depends on another project's roadmap.

**Why the attractive choice can be wrong.** "Our brand is our differentiator" sounds decisive, but if the brand requirements are
visual, tokens deliver them in either option; the differentiating cost of A is mostly re-implementing commodity behaviour. The
risk in B is real but testable.

**Decision process.** Run a two-week spike: implement the new brand's tokens on the open-source library for five representative
screens, run the contrast gate per mode, and list what cannot be themed. If the list is short, choose B and spend the hires on a
token pipeline (web and native), native components, and a design program manager. If the list contains core interaction patterns,
choose a hybrid: adopt for commodity components, build the differentiating ones. **Uncertainty.** The spike will not reveal
long-term divergence between the library's roadmap and yours; schedule a yearly review.

### Learning objectives and mastery check

After this page you should be able to **explain** DesignOps and its two halves; **distinguish** it from ResearchOps, ProductOps and
ContentOps; **design** an intake, critique and contribution process; **build** a token pipeline with an accessibility gate;
**calculate** coverage, detach rate, upgrade lag and capacity; **run** a release-regression runbook; and **decide** whether to
adopt, build or wait.

::: answer 1. A component has 400 insertions and 140 detachments in a quarter. What is the detach rate, and what do you do?
140 ÷ 400 = 35%. Above a 25% investigation threshold, so interview the teams detaching it and inspect the detached copies. If they
add the same missing slot, add a variant; if detaching is intended (for example a template meant to be customised), document it
and exclude it from the alert.
:::

::: answer 2. An app has 900 system instances, 250 custom components and 50 native controls. What is its coverage?
900 ÷ (900 + 250 + 50) = 900 ÷ 1,200 = 75%. Then look at the offenders list: 250 custom components matter more than 50 native
controls if a few of them are clones of system components.
:::

::: answer 3. A team renames the token `color.text.muted` to `color.text.subtle` and ships it as version 3.7.0. What is wrong?
Renaming a token breaks every consumer that references it, so under semver it is a major change. The right path: add the new name
in a minor release, mark the old one `$deprecated` with an explanation, keep it for at least one minor release, then remove it in
4.0.0 with a codemod.
:::

::: answer 4. White text on #0851a8 measures 7.63:1 and grey #888888 on white measures 3.54:1. Which pass WCAG 2.2 AA for body text?
Body text needs at least 4.5:1 (SC 1.4.3), so the first passes and the second fails. The grey would pass 3:1 only for large-scale
text (at least 18 point, or 14 point bold) or as a non-text boundary under SC 1.4.11.
:::

::: answer 5. Leaders ask for "number of components shipped" as the design system's main KPI. What do you propose instead?
Coverage in key apps, detach rate on top components, median upgrade lag, and time to decision on contributions, each with a target
and owner. Components shipped rewards building things nobody adopts.
:::

::: answer 6. A three-designer start-up asks whether to hire a DesignOps manager. What do you advise?
Not yet. Adopt habits (weekly critique, a shared request list, an existing open-source system with your tokens) and revisit when
there are several product teams or growth is rapid (see [When to use it and when not to](#when-to-use-it-and-when-not-to)).
:::

::: answer 7. Product managers complain that DesignOps slows them down. How do you diagnose it?
Measure request cycle time by size and time each process step; survey requesters. Add a fast lane for small requests, remove steps
that cost more than they save, and check whether governance has become approval. The goal is to serve, not to gate.
:::

### Conclusion

DesignOps is easy to recognise and to get wrong. The label is established; what varies is which problems an organisation
decides to solve. The evidence collapses into one line: **run the studio and run the supply chain**, measure both with a handful of
numbers you can defend, treat telemetry as a question, not a verdict, and ask whether each process saves more time
than it costs. A DesignOps function that does this becomes invisible in the best sense: designers design, engineers build from
parts they trust, and users get interfaces that are consistent and usable by everyone. One that does not
becomes a queue in front of the people it was meant to help.

## Sources and further reading

All sources below were opened on 2026-10-23. Product plan and feature details are as of October 2026 and change often. Legal
references are orientation, not advice.

[^nng-101]: [DesignOps 101](https://www.nngroup.com/articles/design-operations-101/) — Kate Kaplan, Nielsen Norman Group, 2019-07-21. Checked 2026-10-23.
[^nng-defs]: [DesignOps: What's the Point? How Practitioners Define DesignOps Value](https://www.nngroup.com/articles/design-ops-definitions/) — Kate Kaplan, Nielsen Norman Group, 2020-05-24. Checked 2026-10-23.
[^nng-maturity]: [DesignOps Maturity: Low in Most Organizations](https://www.nngroup.com/articles/designops-maturity-low/) — Kate Kaplan, Nielsen Norman Group, 2020-06-07 (survey of 557 UX and design professionals, self-reported). Checked 2026-10-23.
[^nng-faq]: [DesignOps FAQ: 6 Common Questions About Design Operations](https://www.nngroup.com/articles/design-ops-faq/) — Kate Kaplan, Nielsen Norman Group, 2019-11-10. Checked 2026-10-23.
[^nng-muxi]: [Managed-UX Integration: A Team Model for UX Autonomy and Product Alignment](https://www.nngroup.com/articles/managed-ux/) — Anna Kaley, Nielsen Norman Group, 2025-10-17. Checked 2026-10-23.
[^nng-ds101]: [Design Systems 101](https://www.nngroup.com/articles/design-systems-101/) — Therese Fessenden, Nielsen Norman Group, 2021-04-11 (reviewed 2026-08-27). Checked 2026-10-23.
[^nng-critique]: [Design Critiques: Encourage a Positive Culture to Improve Products](https://www.nngroup.com/articles/design-critiques/) — Sarah Gibbons, Nielsen Norman Group, 2016-10-23. Checked 2026-10-23.
[^nng-uxdebt]: [UX Debt: How to Identify, Prioritize, and Resolve](https://www.nngroup.com/articles/ux-debt/) — Anna Kaley, Nielsen Norman Group, 2018-11-11. Checked 2026-10-23.
[^dribbble-handbook]: [Design Better's free Design Ops Handbook](https://dribbble.com/stories/2018/06/29/design-betters-free-design-ops-handbook) — Dribbble, 2018-06-29 (the handbook is now sold by Design Better: [DesignOps Handbook](https://designbetterpodcast.com/p/designops-handbook)). Checked 2026-10-23.
[^conductors]: [The Design Conductors: Your Essential Guide to Design Operations](https://bookshop.sg/products/the-design-conductors-your-essential-guide-to-design-operations) — Rachel Posman and John Calhoun, Rosenfeld Media, 2024 (retailer listing; the publisher's page could not be fetched automatically). Checked 2026-10-23.
[^hsc-course]: [Realising The Full Strategic Value of Design Operations](https://henrystewartconferences.com/creative-operations/strategic-value-design-ops) — Henry Stewart Conferences, on-demand course, undated. Checked 2026-10-23.
[^curtis-models]: [Team Models for Scaling a Design System](https://articles.centercentre.com/?p=860) — Nathan Curtis, 2015-09-17, republished by Center Centre. Checked 2026-10-23.
[^frost-ch2]: [Atomic Design, chapter 2: Atomic Design Methodology](https://atomicdesign.bradfrost.com/chapter-2/) — Brad Frost, 2016. Checked 2026-10-23.
[^frost-ch5]: [Atomic Design, chapter 5: Maintaining Design Systems](https://atomicdesign.bradfrost.com/chapter-5/) — Brad Frost, 2016 (quotations of Nathan Curtis and Alex Schleifer as printed by Frost). Checked 2026-10-23.
[^dtcg-stable]: [Design Tokens specification reaches first stable version](https://www.w3.org/community/design-tokens/2025/10/28/design-tokens-specification-reaches-first-stable-version/) — W3C Design Tokens Community Group, 2025-10-28. Checked 2026-10-23.
[^dtcg-format]: [Design Tokens Format Module 2025.10](https://www.designtokens.org/tr/2025.10/format/) — Design Tokens Community Group, 2025.10. Checked 2026-10-23.
[^dtcg-color]: [Design Tokens Color Module 2025.10](https://www.designtokens.org/tr/2025.10/color/) — Design Tokens Community Group, 2025.10. Checked 2026-10-23.
[^dtcg-tr]: [Design Tokens Technical Reports 2025.10](https://www.designtokens.org/tr/2025.10/) — Design Tokens Community Group, 2025.10 (abstract credits the Salesforce design system team). Checked 2026-10-23.
[^sd-dtcg]: [Design Tokens Community Group (DTCG) support](https://styledictionary.com/info/dtcg/) — Style Dictionary documentation, live page (npm latest 5.7.0 on 2026-10-23). Checked 2026-10-23.
[^figma-variables]: [Guide to variables in Figma](https://help.figma.com/hc/en-us/articles/15339657135383-Guide-to-variables-in-Figma) — Figma Help Center, live page. Checked 2026-10-23.
[^figma-analytics]: [View and explore library analytics](https://help.figma.com/hc/en-us/articles/360039238353-Track-library-and-component-usage) — Figma Help Center, live page. Checked 2026-10-23.
[^figma-analytics-api]: [Library Analytics API introduction](https://developers.figma.com/docs/rest-api/library-analytics-intro) — Figma developer documentation, live page. Checked 2026-10-23.
[^figma-analytics-endpoints]: [Library analytics endpoints](https://developers.figma.com/docs/rest-api/library-analytics-endpoints/) — Figma developer documentation, live page. Checked 2026-10-23.
[^figma-devmode]: [Guide to Dev Mode](https://help.figma.com/hc/en-us/articles/15023124644247-Guide-to-Dev-Mode) — Figma Help Center, live page. Checked 2026-10-23.
[^figma-codeconnect]: [Code Connect](https://help.figma.com/hc/en-us/articles/23920389749655-Code-Connect) — Figma Help Center, live page. Checked 2026-10-23.
[^figma-mcp]: [Guide to the Figma MCP server](https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Figma-MCP-server) — Figma Help Center, live page. Checked 2026-10-23.
[^figma-study]: [Measuring the value of design systems](https://www.figma.com/blog/measuring-the-value-of-design-systems/) — Clancy Slack, Figma blog, 2019-12-19 (vendor study; sample size not reported). Checked 2026-10-23.
[^figma-metrics]: [Design systems 104: Making metrics matter](https://www.figma.com/blog/design-systems-104-making-metrics-matter/) — Carly Ayres, Figma blog, 2025-02-11. Checked 2026-10-23.
[^github-annotations]: [Open sourcing the GitHub Annotation Toolkit](https://github.blog/changelog/2025-09-22-open-sourcing-the-github-annotation-toolkit) — GitHub Changelog, 2025-09-22. Checked 2026-10-23.
[^storybook-a11y]: [Accessibility tests](https://storybook.js.org/docs/writing-tests/accessibility-testing) — Storybook documentation, live page (the 57% figure is a Deque study as cited by Storybook). Checked 2026-10-23.
[^playwright-visual]: [Visual comparisons](https://playwright.dev/docs/test-snapshots) — Playwright documentation, live page. Checked 2026-10-23.
[^react-scanner]: [react-scanner](https://github.com/moroshko/react-scanner) — GitHub repository (npm 1.2.0), MIT licence. Checked 2026-10-23.
[^wcag22]: [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/) — W3C Recommendation since 2023-10-05; current edition 2024-12-12 ([publication history](https://www.w3.org/standards/history/WCAG22/)). Checked 2026-10-23.
[^eaa]: [European Accessibility Act](https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/union-equality-strategy-rights-persons-disabilities-2021-2030/european-accessibility-act_en) — European Commission, undated. Checked 2026-10-23.
[^eaa-date]: [The EAA comes into effect in June 2025. Are you ready?](https://accessible-eu-centre.ec.europa.eu/content-corner/news/eaa-comes-effect-june-2025-are-you-ready-2025-01-31_en) — AccessibleEU, 2025-01-31. Checked 2026-10-23.
[^en301549]: [EN 301 549 V4.1.1 published](https://nda.ie/news/en301549-published) — National Disability Authority (Ireland), 2026. Checked 2026-10-23.
[^ada-title2]: [Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments](https://www.ada.gov/resources/2024-03-08-web-rule/) — U.S. Department of Justice, 2024, compliance dates as amended by the interim final rule of 2026-04-20. Checked 2026-10-23.
[^semver]: [Semantic Versioning 2.0.0](https://semver.org/) — semver.org. Checked 2026-10-23.
[^volvo-releases]: [Releases and versioning](https://designsystem.volvocars.com/web/developing/releases/) — Volvo Cars Design System, live page. Checked 2026-10-23.
[^agds-change]: [Change management](https://design-system.agriculture.gov.au/guides/change-management) — Agriculture Design System, Australian Government, live page. Checked 2026-10-23.
[^govuk-criteria]: [Contribution criteria](https://design-system.service.gov.uk/community/contribution-criteria/) — GOV.UK Design System, live page. Checked 2026-10-23.
[^govuk-lifecycle]: [Component lifecycle statuses](https://design-system.service.gov.uk/community/component-lifecycle-statuses/) — GOV.UK Design System, live page. Checked 2026-10-23.
[^govuk-community]: [Community](https://design-system.service.gov.uk/community/) — GOV.UK Design System, live page. Checked 2026-10-23.
[^zh-2026]: [Design Systems Report 2026](https://report.zeroheight.com/2026) — zeroheight, fifth edition, 2026 (147 design-system practitioners, 90% from North America, Western Europe and Oceania, most in companies over 1,000 employees; recruitment not described; published by a documentation-tool vendor). Checked 2026-10-23.
[^deque-57]: [Automated testing study identifies 57 percent of digital accessibility issues](https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/) — Deque Systems, 2021-03-10 (vendor study; issue volume across more than 2,000 first-time audits). Checked 2026-10-23.
[^gh-node20]: [Deprecation of Node 20 on GitHub Actions runners](https://github.blog/changelog/2026-09-23-deprecation-of-node-20-on-github-actions-runners/) — GitHub Changelog, 2025-09-19 with editor's notes to 2026-08-25. Checked 2026-10-23.
[^node-schedule]: [Node.js release schedule](https://github.com/nodejs/Release) — Node.js Release Working Group (`schedule.json`: v20 end 2026-04-30, v22 end 2027-04-30, v24 maintenance from 2026-10-20, end 2028-04-30; v26 LTS from 2026-10-28). Checked 2026-10-23.
[^terrazzo]: [Terrazzo documentation](https://terrazzo.app/docs/) and [DTCG tokens guide](https://terrazzo.app/docs/guides/dtcg/) — Terrazzo, live pages. Checked 2026-10-23.
[^tokens-studio-format]: [Token format](https://docs.tokens.studio/manage-settings/token-format) — Tokens Studio documentation, live page, undated. Checked 2026-10-23.
[^heart]: [Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications](https://research.google/pubs/measuring-the-user-experience-on-a-large-scale-user-centered-metrics-for-web-applications/) — Kerry Rodden, Hilary Hutchinson, Xin Fu, CHI 2010, Google Research. Checked 2026-10-23.

**Further reading**

- [DesignOps Handbook](https://designbetterpodcast.com/p/designops-handbook) — Kate Battles, Meredith Black, Dave Malouf, Collin
  Whitehead; Design Better (paid).
- [Design Tokens Community Group FAQ](https://www.designtokens.org/faq/) — status and scope of the format.

**Changelog**

- 2026-10-23: first complete draft (research, ledger, labs 1–3 executed, 9 diagrams); after the first browser QA, the
  reference architecture and request workflow figures were redrawn for legibility (no subgraph titles crossed by edges, no
  sequence labels crossing lifelines).
- 2026-10-23 (revision after independent review r1): CI example moved to SHA-pinned checkout/setup-node/upload-artifact v7 on
  Node.js 24 with a pinning note; Labs 2–3 re-run on Node.js 24.22.1 (outputs unchanged); 57% figure explained once (issue volume,
  Deque study opened); zeroheight 2026 report added; token-pipeline comparison, tool-stack governance and measurable maturity exit
  criteria added; precision fixes (WCAG 2.2 dates, MUXI, handbook authors, Code Connect plans, Lab 1 API shape, react-scanner
  status, Lab 2/runbook version); repeated points cross-linked instead of restated.
- 2026-10-23, post-score polish: Figma MCP plan wording (Government: desktop server only); Deque 57% caveat no longer names
  contrast; zeroheight population stated instead of "self-selected"; Node.js 26 LTS date added; maturity and contribution figures
  redrawn without crossing edges; conclusion and FAQ trimmed.