Component-Driven Development: Build UIs Bottom-Up
Component-Driven Development (CDD) builds UIs bottom-up, like assembling a car from its engine and wheels. It's used to manage complex UIs by creating small, independent components first. The footgun is building components too coupled to app-specific logic.
Why it exists
Modern user interfaces are highly interactive and must work across hundreds of devices. As applications grow, managing UI complexity with a traditional top-down approach becomes slow and error-prone. CDD was created to manage this complexity by breaking UIs into small, independent, and reusable parts.
The mental model
Think of building a UI like assembling with LEGO bricks instead of sculpting from a block of clay. With clay (a top-down monolith), changing one part can crack the whole structure. With LEGOs (CDD), you build standard bricks (components) first, then combine them into larger structures (screens). You can swap, replace, and reuse bricks easily across your entire project.
How it works
Development starts with the smallest, most fundamental pieces of the UI, like buttons, inputs, or icons. These "primitive" components are built and tested in isolation from the main application, often in a dedicated tool like Storybook. They are designed to be configurable via properties (props). More complex components are then composed from these primitives. Finally, entire pages are assembled from these composite components. The application itself becomes a lightweight orchestrator of these pre-built, well-tested parts.
When to use it
CDD is ideal for large-scale applications, projects with a formal design system, and teams that need to work in parallel. It shines when you need to ensure UI consistency across many screens or even multiple applications. It also speeds up development by creating a shorter feedback loop; you can perfect a component once instead of tweaking it in ten different places.
When not to use it
For very small, simple projects or one-off prototypes, the overhead of setting up a component-driven workflow might be overkill. If your UI has very little repetition and consists mostly of unique layouts, the primary benefit of reusability is diminished. It's a process investment that pays dividends with scale and complexity.
One canonical example
Instead of building a user profile page from top to bottom, a CDD approach starts with the atoms. First, you build an Avatar component, a UserInfo component, and a Button component. Each is developed and documented independently. You then combine them into a ProfileHeader component. Finally, the ProfilePage simply renders the ProfileHeader alongside other components, passing in the necessary data as props.
Interview question
What is the primary method Component-Driven Development uses to manage UI complexity?
- a.It ensures UI components are tightly integrated with the application's business logic.
- b.It provides tools that automatically generate UI code from design specifications.
- c.It encourages building full-page layouts first, then breaking them down into smaller pieces.
- d.It allows individual UI parts to be developed and tested in isolation before being composed.Correct
Why? this is the answer
The core of CDD is building small, independent UI parts in isolation, like LEGOs, before composing them into larger structures. This modularity is how it primarily addresses complexity. Tightly coupling components with business logic (option A) is explicitly mentioned as a 'footgun' or anti-pattern.
Just read this? Test yourself on what you have been reading.
Read the original → component-driven.dev
- #design systems
- #frontend
- #cdd
- #ui architecture
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on design systems — each one lists the topics its interview covers.
See open roles