Component Composition

Component composition is the practice of building complex UI patterns from small single responsibility components that snap together. You stop creating one massive component that tries to solve every problem with a mountain of props and configuration options. Instead you define primitives like containers headers bodies footers and controls. These pieces reference design tokens for all their visual decisions and combine in different combinations to create new interfaces. The design systems article nails this with its card decomposition image. What users see as one card is actually multiple components working in concert. This method keeps maintenance low and adaptability high as your product evolves in unexpected directions.

Component composition is not a giant button component with 14 props for every conceivable variant and state. That pattern feels smart during the initial build but collapses under real product pressure. It is not simply organizing your Figma layers better or adding more variants to existing components. Those are surface level changes that ignore the structural problem. It is not deep inheritance trees where one component extends another in a brittle chain. And it is not a substitute for governance or tokens. Without those foundations your composed components will still create inconsistency. The failures listed in the article all stem from ignoring composition in favor of rigid or isolated thinking.

Concrete examples from successful systems prove the point. Shopify Polaris refactored their card system in late 2020 after years of product teams hacking around the original rigid component. The new composed version includes Card CardHeader CardBody CardFooter and CardActions. When they launched the new checkout experience in 2022 every panel used these exact pieces in fresh combinations. The fraud team building Radar dashboards in 2023 pulled the same components for their metric cards. Zero modifications to the primitives were necessary. Stripe follows suit with their Elements library. Their payment forms are compositions of individual input components wrapped in layout primitives. This allowed them to ship entirely new billing experiences in 2021 without touching the core payment components. GitHub Primer applied the same thinking to their navigation. The sidebar navigation that shipped in 2019 became the foundation for the 2022 mobile bottom nav through different composition. The article image of snapping bricks is not decoration. It is a blueprint these teams followed. Linear the project management tool used composition to rebuild their advanced filter system in 2022. Their base dropdown and chip components combined into query builders that no one had planned for during the initial system build. This same principle applies to data tables. Instead of one DataTable component with 25 props the composed version uses Table Container TableHeader Row Cell Pagination and FilterBar as separate pieces allowing entirely new views without core library changes.

Apply component composition when your design system has solid tokens and core components but product teams are starting to invent workarounds for new features. This is the signal that your system needs to evolve from rigid to flexible. It is the perfect tool for recurring patterns like forms dashboards and detail views where the arrangement changes based on data or user context. IBM Carbon uses this model for their entire modular interface system. Different business units compose the same primitives into industry specific layouts. The dedicated ownership team the article recommends can maintain the quality of base pieces while product designers and engineers gain freedom to innovate. Use it once you have implemented the contribution paths and governance model described later in the guide. Without that support even the best composition approach will fragment. This matches the start with pain not ambition advice. Identify the patterns causing the most friction like inconsistent form layouts or dashboard widgets and decompose those first. Then let the system grow organically through real usage rather than theoretical perfection.

Avoid component composition in the earliest phases of product development when you are still figuring out the actual problems worth solving. You will waste time abstracting components that will be thrown away. It also does not make sense for highly custom marketing pages or one off data visualizations that have no reusable elements. Forcing composition there just slows everyone down. Skip it if your team lacks the governance structure to keep primitives updated. The article makes clear that systems without maintenance teams die fast and poorly maintained primitives create worse problems than monolithic components. Do not use it as an excuse to over abstract everything. A simple static banner does not need four composed pieces. That creates developer frustration and hurts adoption. The key is knowing which patterns repeat enough to justify the primitive breakdown.

Teams that master component composition avoid all five failure modes in the design systems article. Their systems grow from the edges as product teams contribute new compositions that sometimes become official patterns. Documentation focuses on both the pieces and the recommended assemblies which answers the when question the article stresses. The result is a living system that ships with the product rather than lagging behind it.

Stop building cathedrals when bricks will do the job better.