The Governance of Design Systems
summary
The presentation names four governance models and explains who actually updates a design system, when that becomes a bottleneck, and how responsibility scales: overlord / centralized / federator / decentralized. It shows actual practices—using Figma and component libraries, chopping ownership by product or component—and cites Polaris case studies that claim measurable operational efficiency gains. The core claim is that governance must be a deliberate choice tied to staffing, onboarding, and clear commit paths for the design system to work.
AI-written summary · about
chapters (16)
- 0:00Intro
- 1:14The investigation
- 1:52The expose
- 2:27The uphill battle
- 3:24A world without monsters
- 4:28The triumph
- 4:42The protective measures
- 7:04Keeping the problems at bay
- 7:38If a design system is a product
- 8:13Putting the system in design
- 8:30The overlord model
- 10:57The centralised model
- 12:13The federated model
- 14:09The decentralised model Process
- 15:32Solutions to systemie problems
- 16:20Beyond the initial battles
