Breaking changes in Design system
summary
Claim: breaking changes are inevitable but often avoidable in closed systems when usage is measurable and migrations are scripted. Evidence: more than a thousand releases inform patterns like monolithic, coupled/locked and independent versioning and a simple button prop rename (small → size) shows how blast radius depends on actual usage. Tools and outcomes: Figma usage analytics and repo scanners track adoption, component analytics proves safe removal, code mods written with jscodeshift automate migrations, and strict semantic versioning plus regression checks reduce surprises.
AI-written summary · about
chapters (11)
- 0:00Breaking changes in design systems
- 2:15Process and design changes
- 7:34Development and versioning
- 11:09Developer survey on updates
- 12:37Impact and mitigation
- 18:13Component API changes
- 21:26Analytics for breaking changes
- 24:53Visual regression testing
- 26:58Building robustness
- 28:24Planning breaking changes
- 29:26Summary
related talks
28mHow to stop breaking other people's things
50mThe Cutting Edge Of Versioning
45mPaving the adoption path of your Design System for engineers
30mBreaking backwards compatibility: The easy way!
27mDesigning Even Larger (JavaScript) Applications
31mIncremental Design - A conversation with a designer and a developer
40m“Where We Can Go”
44mBackwards Incompatible Tales