Component-Driven Development
Design Processes
Building an interface from small, independent, reusable parts, bottom-up.
In practice
Component-driven development starts with the smallest pieces — a button, an input, a card — builds and tests each in isolation, then composes them into screens. It is the engineering counterpart to a design system: the same components exist in the design file and the codebase, and a change to one propagates everywhere it is used.
Questions
What is Component-Driven Development?
Component-driven development is building UI as a library of self-contained, composable components, developed and tested individually before being assembled into pages.
Why do you use Component-Driven Development?
It makes consistency automatic and change cheap. Fix a component once and every screen that uses it is fixed.
How do you use/apply Component-Driven Development?
Define components from the design system, build each in isolation with its states documented, compose screens from them, and never style a screen directly.
When do you use Component-Driven Development?
For any product that will outlive its first release. The overhead is real on day one and repaid many times over by month three.
Who uses Component-Driven Development?
Front-end engineers, design-system teams and the designers who feed them.
