Governance and delivery

Every module before this one taught you to build a system. This one teaches you to run one, and to get someone to pay for it. Those are different skills, and the second is where most design-system work quietly dies. A beautiful Figma library with no versioning discipline, no contribution path, and no executive who believes in it is a museum piece. The agency reality is blunter still. You are not billing for artefacts, you are billing for a system that keeps earning its keep after you have left the room. So we cover four things in order: how a living system changes without breaking its users (versioning and deprecation), how new work flows into it (contribution and maturity models), how you scope and sell the work to a client (pilots, scorecards, reuse economics, and the stakeholder pitch), and how you write the governance contract and handoff that make it outlast the engagement.

Versioning: a public API for design

The moment a client starts consuming your tokens and components in production, your system is an API, and every change you make is a change to a contract other people depend on. Amateur systems change silently and break their consumers; professional systems version. The industry standard is semantic versioning (semver): a MAJOR.MINOR.PATCH triple where you bump PATCH for a backwards-compatible fix, MINOR for a backwards-compatible addition, and MAJOR for a breaking change. It applies to tokens as literally as to code. Renaming color.background.brand or changing what it resolves to for existing consumers is a breaking change and demands a major bump; adding a brand-new token is a minor; correcting a token that was pointing at the wrong value is a patch.

Two real systems mark the ends of the discipline spectrum, and you should be able to argue for either depending on the client.

Atlassian runs a formal token lifecycle with three states: active → deprecated → deleted. A token is never yanked; it is first marked deprecated (still works, but flagged, with a documented replacement and migration note), lives through a grace period, and only then is deleted in a later major. Crucially, Atlassian treats semantic tokens as the only supported public API and backgrounds the raw palette entirely, with the governing doctrine: “don’t use a token just because the colors match.” The contract is the semantic layer; the palette underneath is theirs to change. It is the single most important governance idea in tokens. You version the layer people are allowed to touch, and keep the layer they are not allowed to touch free to move.

Porsche takes the opposite temperament: a deliberately tiny, locked semantic set and calendar-driven strict semver, a major version every six months on a fixed cadence rather than whenever breaking changes happen to pile up. Consumers know that if they are on the current major, nothing breaks under them until the next scheduled window, so they can plan the migration into a sprint months ahead. They chose governance rigour over flexibility on purpose. For a client that ships quarterly and hates surprises, calendar semver is a feature rather than a limitation.

Deprecation is a lifecycle, not a delete key

Deleting a component the day you replace it is how you lose trust. The Atlassian model generalises to any client system: when something has to go, mark it deprecated with a machine-readable flag and a documented successor, announce it in the changelog, hold it through at least one release cycle so teams can migrate on their own schedule, and only delete it in a subsequent major. The changelog is not optional paperwork. It is the audit trail that lets a consuming team answer “what changed, why, and when” without emailing you. Andrew Couldwell is emphatic that this is process, not decoration:

He notes that BuzzFeed calls theirs Release Notes and documents everything down to a hex code, a pixel value, a border-radius, a new token, or a renamed CSS class. For a client engagement, the changelog doubles as your invoice made legible, the visible proof that the retainer is buying continuous, careful change rather than silent drift.

Contribution: who is allowed to add, and how

The single most expensive governance mistake is expecting the wrong people to feed the system. Dan Mall states the doctrine flatly, and almost every organisation gets it backwards:

His division of labour is a kitchen: “I cook, she cleans.” Product teams invent new things for their customers; the system team collects what they invented, extracting components from the product and abstracting them for others to reuse. “Systems people want to do system things. Product people want to create things. This is the way.” When the split is right, “design system contribution becomes automatic just by virtue of everyone doing the work they’re supposed to do... When done well, it feels like magic.” The anti-pattern he names by sight: “I’ve seen design system teams create elaborate checklists that product teams need to comply with in order to contribute, and then they wonder why contribution is so low or even nonexistent.” If your contribution model is a compliance form, you have built a toll booth rather than a pipeline.

That maps onto Nathan Curtis’s classic split between a centralized model (one team owns everything), a distributed model (everyone owns their piece), and a federated model (a central core plus representatives seconded from product teams). Mall gives a soft recommendation for the federated model, and it is the right default for most client systems: you own the core and the abstraction rigour, and named people on each product team feed real usage back in.

The Hot Potato Process

Mall’s answer to how designers and engineers actually collaborate on contributions is the Hot Potato Process. Rather than a relay where the designer works alone for two weeks and then throws a spec over the wall, it is a rapid back-and-forth where the front-end engineer leads in the browser and the whole team continually converges and diverges. His picture of the rhythm:

Four named moves make it run:

• “Dear Engineer, what do you need right now?”: the magic words. The engineer is closest to the working software, so the team orients around unblocking them rather than around a document.
• “All Hands on Deck.” Move the end-of-project crunch collaboration to the beginning: “you get the same amount of collaboration and help, but without the stress.”
• “Kinda Like This.” Align with references first (pull up the App Store): “references shortcut the time to alignment, as opposed to having to design and build everything from scratch.”
• “Spot Comps.” When references run out, the designer sketches just one spot on the screen, not the whole thing. In parallel the designer produces an element collage, “just enough exploration that everyone knows where the designer is headed,” which is explicitly not a finished UI kit.

The Measuring Spoon Cycle and the rule of three

Contribution is not a one-off; it is a flywheel Mall calls the Measuring Spoon Cycle, and product always comes before system. Its four steps: (1) make a feature or product; (2) extract and abstract components from it to start the system; (3) make another product using the components you previously extracted; (4) return to step 2. “Then repeat this process. Forever. For as long as your company exists.” He pairs this with a hard eligibility gate for what earns a place in the system: “Can three other teams at this company use this component right now?” If not, don’t add it. Three is the smallest number at which a pattern is genuinely a pattern rather than a coincidence. Below three, you are abstracting noise.

To decide which characteristics of a real component to abstract, Mall uses an All / Most / Some / Few rubric. All: every instance has it, so it is mandatory in the abstraction. Most: highly recommended, include it. Some: “the most contentious criteria by far”: run a workshop to build consensus and effectively push the trait up into All or Most; if that fails, the system team’s call is the tiebreaker. Few: delay it, “wait for that obligation to become more common.”

Canon versus the expanded universe

Not everything a client builds belongs in the system, and saying so is itself a governance act. Mall borrows Lucasfilm’s 1994 distinction: canon is the immovable, official set everything must align to; the expanded universe is everything else, allowed and encouraged to exist locally without being blessed. The part teams miss is his nuance:

Deciding what gets promoted from a team’s expanded universe into canon, through a pilot-based contribution workflow, is the daily work of governance.

A maturity ladder you can steal: the estafette model

The clearest promotion ladder in the field is the NL Design System estafettemodel (Dutch for “relay-race model”), which stages component maturity through four gates: Help Wanted → Community → Candidate → Hall of Fame. A component starts as an unmet need (Help Wanted), gets built and used in the wild by contributing orgs (Community), is proposed for the shared core (Candidate), and only reaches Hall of Fame once it meets the centre’s contracts. The governance philosophy under it is the token seam you already know: the centre owns behaviour, accessibility, and token contracts, while each participating organisation (Utrecht, Amsterdam, Den Haag) owns only its token values as a JSON theme compiled to a CSS class. That is federated governance made concrete, and it is the model closest to a multi-brand client engagement.

Scoping and selling client work

Here is where the agency stops being a build shop and becomes a strategist. Mall’s central delivery doctrine is pilot-first: never build the system first. You extract the system from real product work rather than writing a component bible in the abstract.

The reason is commercial rather than philosophical. A design system you pitch before it exists is, in Mall’s words, vaporware. The whole of his chapter on the subject is titled The Broken Business of “Buy-In,” and his argument is that the standard buy-in playbook (elevator pitch, ROI projections, roadmap from zero) “almost never works” precisely because you are asking leadership to fund something imaginary. A pilot produces buy-in as a byproduct because it produces a real result. The framing question of a pilot is deliberately “What do we need to be able to make with our design system?” and never “what do we want,” because wanting answers “anything and everything,” which “is often what leads teams to create design system graveyards.”

The pilot scorecard

To choose which product to pilot on, Mall scores candidates on eight factors, each from 0 (unlikely) to 10 (very likely), then averages and runs them highest to lowest so the work gets easier as you extract components along the way. The eight factors:

1. Potential for common components: will its components be reusable elsewhere?
2. Potential for common patterns: will its patterns be reusable elsewhere?
3. High-value elements: is there a high-business-value component at its heart?
4. Technical feasibility: how simple is implementation; is a large refactor required?
5. Available champion: will someone see it through and evangelise the system?
6. Scope: is it accomplishable in the pilot timeframe (he uses three to four weeks)?
7. Technical independence: is it decoupled enough to have clear start and end points?
8. Marketing potential: will it excite others to adopt the system?

The scorecard has a political function beyond sequencing. When a loud stakeholder pushes a pet project under a “hand-wavy guise of ‘business value,’” the scorecard “turns that subjectivity into something more objective that can be debated and discussed against agreed-upon criteria.” As a consultant, that is your shield. You are not vetoing the CMO’s favourite; the criteria are. Mall runs multiple pilots concurrently, typically three (four teams: three product plus one system), because “three is the smallest number to see patterns emerge” and because components extracted from a single pilot rarely survive contact with the second use case.

Sell outcomes, not tools, and the reuse economics

Clients do not buy Figma variables; they buy shipping faster and looking good doing it. The hard ROI number to keep in your pocket is Mall’s: “One of my recent clients conducted a few pilots and used the tracked data to project a $40 million savings from an initial investment of $4 million... that’s a 1,000% return on investment.” That is the shape of the pitch, a small tracked pilot investment projected against a large reuse saving. His cautionary mirror image is a company whose colour-only rebrand “should have taken four weeks maximum” but, lacking a canonical source connecting all their buttons, cost “the amount of time and money it takes to put on a Broadway show.”

For multi-brand agency work specifically, the economics compound across brands, which is the argument that justifies the whole engagement. Brand one is a full build: you construct the functional core, the semantic contract, and the first brand’s perceptual layer from scratch. Brand two reuses the functional core and semantic tier wholesale and only supplies new token values, so a large majority of the work is already done, on the order of seventy percent reuse. Brands three and four go fast, because by then the abstraction has been battle-tested against two real perceptual skins and the only remaining work is theming. The cost curve bends down hard after brand one, which is why you scope brand one as the pilot and price the later brands as themes. (Treat the exact percentages as a planning heuristic for the reuse curve, not a measured constant; the one hard, sourced figure is Mall’s $40M against $4M.)

Couldwell’s stakeholder pitch matrix

Selling is never one pitch; it is a different pitch per audience, adjusted “depending on who we were talking to.” Couldwell’s matrix is the most useful sales tool in the field:

The executive move carries the most leverage, because “it’s hard for managers and executives to turn down something that makes them look good, when often all they have to do is say ‘Yes’ and grant you an endorsement and a few connections.” And Couldwell is precise about timing: selling “doesn’t belong at the end: because you don’t want to put in a lot of work only to be told ‘No’... And it doesn’t belong at the start, because you don’t know yet what you’re selling.” It is the same instinct as Mall’s pilot: you sell once you have a real, small result in hand. Above all, selling never stops:

The kickoff governance contract

Before a single token is drawn on a client engagement, write down who owns what. For multi-brand work the ownership line is the same seam you have drawn all course: you (or the central team) own the functional core, the primitives, and the semantic contract; the client owns their values. It is the NL Design System arrangement: the centre owns behaviour, accessibility, and token contracts, and each org owns only its token values. Spell it out in the kickoff document. The agency owns component behaviour, accessibility guarantees, the semantic token names and their meanings, and the versioning and deprecation policy; the client owns brand token values (colour, display type, imagery radius) and their own expanded-universe components. Pair this with Jina Anne’s brandable-versus-constant contract: some tokens the client may override (brand colour, display type), others stay locked system-wide (feedback colours, focus states, contrast-safe text) because they are accessibility-critical. A governance contract that names owners, names the locked set, and names the versioning cadence is the single artefact that prevents the most expensive fight of the engagement.

Handoff: build it so it survives you

The measure of a successful agency engagement is not what ships; it is what keeps running after you invoice the final milestone. Couldwell’s roles are how you engineer survival. Appoint a design system ambassador on each product team who carries a design-system voice into critiques, sprints, and product discussions and reports back to the core, “creating a valuable feedback loop.” Where you cannot staff a dedicated team, name guardians, system-minded people from product teams who meet to maintain the system. Institutionalise support with office hours and a first responder on call to triage issues and answer questions “so the rest of the team can stay focused on deep work.” Hand over the changelog discipline, the versioning policy, and the contribution workflow, not just the files. Mall’s framing seals it: a system that thrives eventually becomes a product, and “like any good product, it needs investment, a dedicated team, a roadmap, marketing, and: most importantly: loyal customers and users.” Your handoff is the roadmap and the first cohort of loyal users, embodied in named people with named responsibilities.

The panel: where the authorities diverge

On team model. Curtis and Mall favour federated (central core plus product-team representatives) as the pragmatic default. Porsche sits at the centralized extreme: a small, locked, calendar-versioned core where rigour beats flexibility. NL Design System sits at the distributed end, where the centre owns only contracts and orgs own their values by construction. There is no universally right answer, only a right answer for the client’s size, risk appetite, and number of brands.

On versioning temperament. Porsche versions strictly on a calendar so consumers can plan; Atlassian versions by lifecycle state (active/deprecated/deleted) with the semantic layer as the only public API; NLDS gates maturity through the estafette relay before anything is even eligible to be depended on. For a cautious enterprise client, argue calendar semver; for a fast-moving product org, argue lifecycle deprecation with generous windows.

On delivery stance. Mall is pilot-first: extract from real work, never build the system abstractly, and let buy-in fall out of a real result. A platform-first or standards-first stance (build the token bible and component kit up front, then mandate adoption) is the tempting alternative and the one clients often ask for by name. The open question going into the capstone is when each is right. Pilot-first wins when adoption is the risk, which is almost always in agency work. Platform-first is defensible only when a hard external standard or a rebrand deadline forces the abstraction before the pilots can run. For client work, default to Mall, and make platform-first a decision you have to justify rather than the reverse.

Further reading

• Nathan Curtis: “Design System Contribution”
• Andrew Couldwell: Laying the Foundations
• Dan Mall: free design-systems resources