Design Component

Origin & evolution

The modern framing comes from Brad Frost's Atomic Design, conceived in 2013 and published as a book in 2016. Frost borrowed chemistry's vocabulary to describe how interfaces compose: atoms (a label, an input, a button) combine into molecules (a search field), molecules into organisms (a header), and organisms into templates and pages. The contribution was less the labels than the claim underneath them, that an interface is a system of recombinable parts rather than a stack of fixed page designs. Frost has since said the labels themselves matter little; the discipline of composition🖼️CompositionWorkspaceA published arrangement of graph entities that has an identity of its own: a gallery, a board, a deck. Membership can be derived by running its query, position is authored by a person, and both are stored because both are real.View reference → is the point.

The idea has older roots. Frost drew the compositional logic from Christopher Alexander's A Pattern Language (1977), and the engineering side matured in parallel as front-end frameworks (React in 2013, then Vue and others) made the component a literal unit of code, a function returning a piece of UI. The two lineages converged: what a designer calls a component and what an engineer calls a component became, for the first time, plausibly the same object.

That convergence sharpened the problem the concept now exists to solve. A button defined in Figma and re-implemented by hand in code is two artefacts that look identical on the day they ship and diverge by the next release🚢ReleaseProduct SpecificationA shipped version of the productView reference →. Design systems🧰Design SystemDesign SystemThe root design system entityView reference → answered this by treating the component as the contract: documented states, named variants🆎VariantGrowthA variant in an A/B testView reference →, and increasingly a token-driven styling layer so a single colour change propagates to every instance. The live debate is how tight that coupling should be, with tools generating code from design files at one extreme and hand-built component libraries with rigorous documentation at the other.

How it works in practice

A team building a billing dashboard🎛️DashboardData & AnalyticsAn analytics dashboardView reference → needs🫀NeedUserA user need, pain, desire, or constraintView reference → a Button. They define it once: three variants (primary, secondary, ghost), four sizes, and the full interaction set, default, hover, focus, disabled, loading. Colour and radius come from tokens, so the button never carries a hard-coded #2563EB; it references colour.action.primary. The same definition exists as a React component consuming the same tokens.

Six weeks later the brand colour🌈Brand ColourBrand IdentityA brand colour definitionView reference → shifts. One token value changes, and every button across forty-one screens updates, in the design file and in production, without anyone touching forty-one screens. A new engineer building the refunds page reaches for the existing Button instead of styling a fresh one, so the refund flow inherits the focus ring and disabled behaviour for free. The component earned its keep the moment reuse beat reinvention.

Design Component vs. its neighbours

• Design token🪙Design TokenDesign SystemA design token (colour, spacing, typography)View reference → is the value, not the thing. A token holds a single decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference →, spacing.4 = 16px, colour.action.primary. A component consumes tokens to style itself. Edit the token and every component that references it moves; the token is the atom of style, the component the atom of structure.
• Design pattern🧩Design PatternDesign SystemA documented design patternView reference → is a reusable solution🔧SolutionDiscoveryA proposed approach to address an opportunityView reference → to a recurring problem, "how should destructive actions be confirmed", and it is solution-shaped and often abstract. A component is a concrete, named, buildable object. A pattern might be realised by several components working together; a component might follow several patterns.
• Design system is the whole of which the component is a part. The system contains the components, the tokens, the patterns, and the guidelines, and governs how they fit. A lone component is a part without a frame; the system is what makes a hundred components feel like one product.

In the graph

In the Unified Product Graph, a design component sits in the Experience, Design & Brand region as a self-nesting hub, the one entity that mirrors atomic design's atom-to-organism nesting directly. A design_system_contains_design_componentDesign SystemcontainsDesign Componenthierarchy edge places it under its system; design_component_styled_by_design_tokenDesign Componentstyled byDesign Tokenhierarchy wires it to the values it consumes; design_component_follows_design_patternDesign ComponentfollowsDesign Patternhierarchy records the solution it embodies; and product_built_with_design_componentProductbuilt withDesign Componenthierarchy connects it outward to what actually ships. That structure makes the single-source-of-truth claim queryable: a component connected to its tokens, its pattern, and the product is provably the same object across design and code, and a component connected to nothing is visibly orphaned.

Composition is the component's own edge. design_component_composes_design_componentDesign ComponentcomposesDesign Componenthierarchy records the atom-to-organism nesting directly, and from 0.39.0 it is authorable across product graphs. The case it exists for is the wrapper: a product keeps its own Button that wraps the design system's, adding a default or narrowing an API, while the design system is a separately published package with a separate graph. Until 0.39.0 that relationship could only be written in the wrapper's description, which is where 11 of them were found. The existing edge was widened rather than a second wraps verb minted, because a wrap is composition read across a graph boundary, and one relationship carrying two names is the shape the catalog works to avoid.

0.39.0 also gave the component a second, non-owning parent. feature_area_groups_design_component lets a feature area📁Feature AreaProduct SpecificationA grouping of related featuresView reference → group components the way a real catalog does, by product surface🪟SurfaceExperience DesignA place inside a screen, the features that occupy it, and the rule that decides who wins itView reference → rather than alphabetically. Ownership does not move with it: a component is still owned by its design_system🧰Design SystemDesign SystemThe root design system entityView reference →, its product🧬ProductStrategyThe product being created, the root of the graphView reference →, or a parent component, and the area only groups. One component can sit under several areas without any of them holding it.