Design System as Infrastructure

What I owned

I championed the Figma Library direction and drove its establishment: the foundations, the reusable components and the visual language, and how designers outside the central team would consume the system. I authored and shaped the documentation that made the system usable beyond the core team, and I reviewed market and agency work against the system as part of the central governance model that stood between design and delivery. Years later, when the dominant source of inconsistency had moved downstream, I framed the new problem and drove the contract-mediated response to it.

1. Shape the foundations
2. Enable distributed designers
3. Govern the system
4. Reframe the problem
5. Define the contract model
6. Make it verifiable
7. Bound AI execution

This was not a solo system. A central design-system team, product designers across markets, frontend engineers and delivery partners built on it, extended it and pushed back on it. What I claim is the framing, the direction and the operating model: recognising when the nature of the problem had changed, deciding what the system should become next, and getting design and engineering behind it.

Building a design language for teams I would never meet

The first version of this problem was a design problem, and it was solved with design work. A shared Figma library, built properly: foundations that held, a component set with a variant structure teams could reason about, states and interaction behaviour resolved rather than implied, responsive rules that survived real content, and accessibility expectations written into the component rather than bolted on at review.

The harder part was making that work outside the room it was made in. A designer in a market I had never worked with needed to know which component to reach for, when not to use it, how to compose it into a page, and what they were still free to decide locally. Documentation was not an operational task at the end of the design work; it was how the system reached people the central team could not sit with, and I wrote and co-wrote it for that purpose. The library made the design language reusable, the documentation made it learnable, and central review made it governable.

Nothing that came later was a correction of this. It was the right operating model for the problem at that stage, and it solved that problem.

When scale moved the problem downstream

The Figma Library succeeded. Its success exposed the next constraint. Across a fragmented ecosystem of markets, agencies, delivery partners and technologies all moving at different speeds, designers knew how to use the system and review caught the work that drifted from it. The inconsistency that remained was appearing after design was approved.

With one delivery team or one agency, ambiguity in a specification is not a systemic problem, because someone can ask and someone can answer. Across 100+ markets using different teams, agencies and implementation environments, that conversation does not happen. Every ambiguity is resolved independently, differently, by people who never speak to each other.

Governance is what made this structural rather than incidental. Central review could confirm that a market's design conformed to the system. It could not remove the ambiguity a design file plus a document leaves behind, because behaviour, dependencies, runtime constraints and the definition of conformance were never in what got handed over. This, not AI, is why contracts became necessary.

The Figma Library successfully scaled the design language. The next problem was making design intent survive implementation.

The obvious response to inconsistent output is more review, more documentation and more meetings. That response scales linearly with the number of teams, which is another way of saying it does not scale. The system had to carry more of its own intent.

Consistency without forcing one implementation path

A global organisation needs consistency. It does not follow that every market and delivery partner can migrate to the same implementation technology, on the same timeline, at an acceptable cost. Treating technological uniformity as the goal would have made the design system a blocker for exactly the markets that most needed it.

So I made the design decisions themselves the thing that travelled. Semantic tokens expressed which decision a value represented rather than the value alone, and explicit compatibility mappings let a market adopt the system on the stack it already had. The system stopped asking teams to build the same way and started telling them what had to be true of whatever they built.

From documentation to design contracts

Documentation had already solved a version of this problem once, by making the design language learnable outside the central team. It could not solve the second version, because it still asks every developer and delivery partner to reconstruct design intent from a design file plus written guidance. That works when the reader shares context with the author. Across a global delivery ecosystem, most readers do not, and the reconstruction is where implementations diverge.

I proposed explicit design contracts and drove that direction. A contract is the next step in the same lineage, not a replacement for design work: the same intent, expressed in a form that can be read, reviewed, implemented and tested without the author in the room. That is what makes design intent portable, able to leave the room it was made in and still arrive intact.

One decision inside this work mattered more than the rest. An earlier framework-based exploration had tested how far the system could move from guidance into executable implementation. It was useful: building the system as running code forced structure, behaviour, state logic and constraints to become explicit, and it showed what a specification actually has to contain.

A framework could execute the system, but it could not be the system.

Tying design authority to one framework would have made the system's reach a function of that framework's adoption. So I moved the source of authority up a level, into governed design intent that any renderer could satisfy. The implementation became a consumer of the system rather than its definition. This was a decision about where authority lives, not a preference between front-end technologies.

Making design intent verifiable

Contracts made expectations explicit, which immediately raised the next question: how does anyone know an implementation actually conforms? Answering that with review alone repeats the original limit. It asks a small central team to manually inspect the output of an ecosystem far larger than itself.

I defined which expectations should be deterministically checkable, and where that boundary sits. Eight questions stopped needing a reviewer.

1. 01DOM structure. Does the implementation have the anatomy the contract describes?
2. 02Attributes. Are the required properties and semantics actually present?
3. 03Geometry. Do measurable spatial relationships hold at the sizes that matter?
4. 04Interaction. Does the component respond as specified to real input?
5. 05Runtime behaviour. Does it still behave correctly once it is running in a host page?
6. 06Semantics. Is the meaning exposed to assistive technology the intended one?
7. 07States. Is every declared state reachable and correct, not only the default?
8. 08Dependencies. Is everything the component needs present and resolved?

Whether the result is the right design is not on that list, and should not be automated away. That is the whole move: implementation expectations became testable rather than purely interpretive, so governance could rest on inspectable evidence, and judgement stayed where judgement belongs.

AI as a controlled execution layer

None of the work above was done for AI. It was done because distributed implementation was losing design intent. When AI-assisted implementation became practical, the architecture turned out to have a second use. Giving an agent a design file does not give it design-system intent; it inherits the same reconstruction problem the implementation teams already had, running faster.

The goal was not to let AI design the experience. It was to make the system explicit enough that AI could implement the experience we had already defined.

So the sequence changed. Instead of design file, then interpretation, then implementation: governed design intent, bounded execution, deterministic validation, then a human decision. I framed the problem, designed the execution architecture, set the validation strategy and governance boundaries, and designed the evaluation that tested it. AI executes inside a governed design system. It does not replace design authority.

Proving it, not asserting it

An architecture that sounds correct is not evidence. I designed a controlled benchmark to separate a repeatable execution model from a convincing demonstration: direct design interpretation against contract-mediated execution, two components, frozen conditions. Then I tested whether the same model survived a real component workflow, including the part where something goes wrong.

What became possible

This operating model is now moving into active use. As part of an ongoing platform migration, markets are beginning to work with contract-based design intent in real delivery rather than only controlled validation.

The contract-mediated execution model reflects the system's evolving operating model and controlled implementation approach, not how every market ships today.

Confidentiality note

This case study is presented in accordance with professional confidentiality obligations. Internal project names, team names, tool names, proprietary schemas, token naming conventions, private documentation and implementation details are not disclosed, and no internal design files or dashboards appear here. Scale figures are used as context only. Benchmark and validation evidence is bounded to the components and conditions described. Further detail is available for discussion in an interview.