Composite components versus layout primitives

WHAT THIS TESTS This checks whether you understand the central design-system tension: enforcing consistency versus enabling flexibility, and how that maps to component granularity.

A GOOD ANSWER COVERS Primitives such as Stack, Grid, and Box are unopinionated building blocks. They maximize flexibility and composition, keep the API small, and adapt to new layouts, but they push design and accessibility decisions onto every consumer, risking inconsistency. Composites such as UserProfileCard encode a specific pattern. They guarantee visual and behavioral consistency, speed up common work, and centralize accessibility, but they are rigid, proliferate as one-off variants accumulate, and grow the API surface and maintenance burden. The right choice depends on reuse frequency and variation: build a composite when a pattern is common and stable across products; rely on primitives when layouts vary or are still evolving. Mature systems layer both, exposing primitives plus a curated set of high-value composites.

COMMON WRONG ANSWERS Claiming one model is always superior. Ignoring the long-term maintenance cost of many narrow composites. Forgetting that primitives can fragment accessibility and spacing if uncontrolled.

LIKELY FOLLOW-UPS How do you stop composite components from exploding into dozens of variants? How do you keep primitives from being misused? Where do tokens fit in this layering?

ONE CONCRETE EXAMPLE A marketing team needs many distinct hero layouts, so primitives like Stack and Grid serve them best. Meanwhile the dashboard renders the same user summary on twenty screens, so a UserProfileCard composite ensures every instance looks and behaves identically. Offering both lets each team pick the right altitude.