From Constraint to Flexible API: Building a Balanced Design System
summary
A constraint-first design system evolves into a guided-but-flexible library that enforces patterns while permitting escape hatches: typography splits into title heading text components that start by accepting only strings and later allow React nodes with a guarded as prop; buttons and links gain explicit links as button or anchor variants and a link variant on Button; card APIs undergo seven API iterations to land on header/footer subcomponents plus a free body slot; API decisions live on GitHub and ship after cross-team review.
AI-written summary · about
chapters (10)
- 0:00Introduction to design systems
- 2:36Problems with inconsistent UI
- 5:48Two approaches to fixing issues
- 7:56Design system team challenges
- 8:59Goals for building the system
- 10:43Typography component evolution
- 15:24Buttons and links design
- 18:17Card component API decisions
- 22:53Design system journey curve
- 24:44Collaborative API decisions
related talks
24mSid Kshetrapal-Walking the line between Flexibility and Consistency in Component libraries
25mBuilding a Design System as a team
44mWriting good components
21mDesign Systems 101: The Developer Approach to Better Frontends
32mIntroduction to Design Systems
29mBulletproof Design Systems
34mBuilding (And Re-Building) the Airbnb Design System
40mA lean approach to building design systems