Paving the adoption path of your Design System for engineers
summary
Clear, testable changes: add unit tests before refactors, extract UI logic so behavior can be swapped, and offer gradual deprecation warnings so teams migrate at their own pace. Run a developer survey to validate pain points, standardize naming and project structure, publish weekly release notes, and provide AST codemods to automate safe renames. Track uptake and iterate; small, instrumented migrations and transparent decisions convince teams to stop forking and start contributing.
AI-written summary · about
chapters (15)
- 0:00Paving the Adoption Path of Your Design System for Engineers Jeremias Menichelli
- 3:54THERE ARE SOME GIFS AND ANIMATIONS!
- 4:17WHAT IS A DESIGN SYSTEM?
- 6:55DESIGN SYSTEMS NEED TO BE FIRST A DESIGN TEAM EFFORT, WITH ENGINEERING OUTCOMES
- 9:22DEVELOPER EXPERIENCE IS KEY
- 14:27DESIGN SYSTEMS ADOPTION IS NOT ONLY ABOUT USAGE, IT'S ALSO COLLABORATION AND SAFE ENGAGEMENT OF ANOTHER CODEBASE
- 19:35VALIDATE for the future
- 20:41HAVING A PRODUCT VISION IS KEY
- 32:34Write meaningful warnings, link to changelogs, documents and migration quides to speed up the changes
- 37:38YOU PAVE THE WAY, THE TEAMS MAKE THE MOVE
- 38:05YOU NEED SPACE FOR MAINTAINANCE, PLANNING AND EXPERIMENTATION IN THE PROJECT
- 40:20COMMUNICATION IS KEY
- 40:48TIME FOR RECAP
- 43:58WORKING ON THE ENGINEERING OF A DESIGN SYSTEM IS LIKE BEING AN OSS MAINTAINER
- 45:02HAVE FUN!
related talks
19mDesign Systems: How to Foster Participation
19mYou've Built a Design System - Now What?
43mScalable Best Practices for Your Development Team
21mExpanding your Design System's sphere of influence and other lessons
27m"Design Systems from 0 to 1"
18mDesign Systems in Practice
36mConsistency is Key - Working with a Design System
26mKeeping your design system alive