A design team updates the primary button component in their shared design system library. What happens to the 47 product screens that use that button?
AEach screen must be updated manually by a designer reviewing the change
BThe buttons update automatically across all screens because they reference the central component
COnly screens currently being actively worked on will reflect the change
DDevelopers must implement the change separately for each screen in code
This is the core value of modular design systems: changes propagate. Because every screen uses the same component (not a copy of it), updating the component definition updates every instance simultaneously. This is fundamentally different from a design approach where each screen has its own independently drawn button — in that case, updating all 47 screens would require manual effort on each one. The component is the unit; pages are assemblies.
Question 2 Multiple Choice
A product with dozens of screens, designed without a shared component library, develops inconsistent button sizes, variable spacing, and conflicting interaction patterns across screens. This problem is best described as:
AA color palette problem that requires a unified color system
BDesign drift — each screen was designed as an island rather than as an assembly of shared components
CA developer implementation error that does not reflect the design files
DAn inevitable consequence of having a large design team that cannot coordinate
Design drift is the natural outcome of page-centric design without shared components. Each time a designer creates a new screen from scratch, small variations creep in — slightly different button corners, inconsistent spacing, different hover states. Over dozens of screens, these accumulate into a visually incoherent product. A modular component library eliminates drift by making the component the canonical reference that all screens inherit from.
Question 3 True / False
In a modular design system, the page is the fundamental unit of design — components exist to support page-level layouts and should be designed with specific pages in mind.
TTrue
FFalse
Answer: False
This reverses the modular design philosophy. In a modular system, the component is the fundamental unit of design. Pages are not designed — they are composed by assembling components. Designing components 'for specific pages' breaks modularity: a component designed to work on one page may not work on others, defeating the purpose of reusability. Components should be designed to work independently and predictably in any context where they are assembled.
Question 4 True / False
A modular design system requires upfront investment in naming conventions and documentation, but that investment reduces long-term inconsistency and accelerates development as the product scales.
TTrue
FFalse
Answer: True
The upfront cost is real: documenting each component's purpose, usage rules, and states; establishing naming conventions that developers and designers share; building the hierarchy from atoms to full layout patterns. But the return on investment grows with scale. A new team member can immediately understand and use the system; a product with 200 screens maintains visual consistency; a rebrand propagates through the entire product by updating a handful of foundational components rather than hundreds of screens.
Question 5 Short Answer
Why does treating the component (rather than the page) as the fundamental unit of design eliminate the problem of visual drift across a large product?
Think about your answer, then reveal below.
Model answer: When components are the unit of design, every instance of a button, card, or form field across the product references the same defined component. There is only one canonical version of each element, and all screens inherit from it. If a component changes, all instances update. In contrast, page-centric design creates independent copies that diverge over time — each iteration of a button may differ slightly, and no mechanism enforces consistency. Modularity makes consistency the default rather than something that must be manually maintained.
The LEGO analogy is useful: bricks with a universal connection system snap together predictably regardless of which set they came from. Components in a design system work the same way — their defined interfaces and states make them combinable in any context while remaining visually coherent. Drift is structurally impossible when there is only one source of truth for each component.