Lead Designer Series — Playbook 05 of 08
Design systems that are governed, adopted, and maintained — not just built.
Enterprise design systems fail in a predictable sequence. Year one is the build: component libraries, token architecture, documentation, Figma coverage. The work is visible, the mandate is clear, and the team is energised. Year two is where the system either becomes infrastructure or begins its quiet divergence into irrelevance. Adoption rates plateau. Local variations proliferate. Engineering implements components inconsistently. The contribution model breaks down. The platform team that owns the system has no mandate to enforce anything.
This is the Year Two Trap — and most design system practitioners are not prepared for it because the resources that exist to help them were written for year one.
This playbook addresses design systems as a governance and operations problem, not an aesthetic or component problem. It covers how to build adoption into the system architecture from the start, how to establish the contribution model that prevents divergence, and how to make the business case for system investment in terms that engineering, product, and finance leadership will act on.
| Section | What it covers |
| Diagnostic | The Design System Health DiagnosticComplete before reading — assesses your system across four dimensions: adoption rate, contribution governance, documentation quality, and cross-functional trust |
| Chapter 01 | The Year Two TrapWhy enterprise design systems stall in their second year; the four failure patterns; how to identify which stage of divergence your system is in and what the recovery path looks like |
| Chapter 02 | Governance — The Ownership ModelHow to structure design system ownership across a large organisation; the Contribution Tier System; why governance without mandate fails and how to build the authority structure that prevents it |
| Chapter 03 | Adoption — Building Use InWhy adoption is an architectural decision, not a communication one; the VIP Lane model for driving early contributor engagement; how to measure adoption in terms that are meaningful to engineering and product leadership |
| Chapter 04 | The Engineering RelationshipHow to structure the design–engineering interface around the design system; the Engineering Waste Calculator framework; how to quantify the cost of inconsistency in terms that make the investment case self-evident |
| Chapter 05 | Token Architecture at ScaleHow to structure a token system that survives theme changes, platform expansion, and team growth; common token architecture failures in enterprise environments and how to prevent them |
| Chapter 06 | The Strangler Pattern — Migrating Legacy SystemsA five-phase framework for migrating from a fragmented legacy design system to a governed platform — without halting delivery or triggering engineering resistance |
| Chapter 07 | The System Health MatrixA four-dimension measurement framework for ongoing system health — covering adoption, contribution quality, documentation coverage, and cross-functional satisfaction |
| Chapter 08 | Making the Business CaseHow to frame design system investment in terms of engineering efficiency, delivery speed, and risk reduction; the format that gets resource allocated rather than noted with interest |
| Appendix | Frameworks and TemplatesThe Contribution Tier System reference; Engineering Waste Calculator template; System Health Matrix as a standalone working tool; the Strangler Pattern phase framework |
- You own or contribute to a design system that is past its initial build phase and showing signs of divergence
- Your design system has good Figma coverage but inconsistent engineering implementation
- Adoption rates are lower than expected and you're not sure whether the problem is governance, communication, or architecture
- You need to make the business case for design system investment to an audience that speaks in engineering efficiency terms
- You're inheriting a legacy system and need a structured approach to migration without halting delivery