Session overview
Most design systems are dead within 18 months of their first major team change. This session diagnoses why that happens and presents the patterns we've used to ship design systems that survive multiple reorganisations, product pivots, and even leadership changes.
Why design systems die
The session opens with case studies of design systems we've seen fail — anonymised but real. Common failure modes:
- The original maintainer leaves, no one inherits ownership.
- Product teams stop reaching for system components because adoption friction is too high.
- The system loses leadership sponsorship after a re-org.
- The Figma library drifts from the code library; designers stop trusting it.
- The system bloats with one-off variants until nobody can find the right component.
The patterns that survive
- Tokens over components. Tokens are the load-bearing layer. Components come and go.
- One named owner. Not "the platform team owns it." A single named person.
- Adoption metrics reported visibly. Make the system's contribution to the business undeniable.
- Single source of truth. Code and design tokens compiled from the same file.
- Documentation in-repo. Out-of-repo docs die. In-repo docs survive.
Case study: the 200-person team
A walkthrough of a system we built that survived three product rebrands and one major reorganisation — including the specific organisational patterns that made it sustainable.
Q&A topics
- How to fund design system work in tight budget cycles.
- How to recover a system that's been neglected.
- When to invest in a system vs use a third-party library.
- How to handle product team pushback on system constraints.
Recording
Contact us to request the recording.