Definition
A component is a reusable part of an interface with defined behavior. Buttons, text inputs, cards, tabs, and modals are components. What makes something a component is not that it appears more than once but that it has been specified: it has a name, a set of properties it accepts, states it can be in, and rules about what it does when someone interacts with it. That specification is a contract. A drawing of a button is an image; a button component says what the label can contain, how it behaves while disabled, what happens on press, and how it responds when the text is long. Appearance is only one of three parts. Contract, appearance, and behavior together are what teams actually reuse.
Why It Exists
Components exist because repetition is expensive twice over. For the person using a product, every slightly different version of the same control is a small relearning tax: is this thing clickable, does it behave like the last one, will it confirm before it acts. Consistency removes that tax and lets attention go to the task. For the team building the product, redrawing and reimplementing the same control produces drift — five button styles, four spacing values, three different loading behaviors — and every one of them has to be maintained, tested, and made accessible separately. Defining a control once and using it everywhere converts a recurring cost into a single one. The savings compound as a product and its team grow.
Examples
- →A button component defines label, icon placement, size, and visual emphasis, and specifies how it looks and behaves when hovered, focused, pressed, disabled, and loading. Every use in the product inherits those decisions rather than restating them.
- →A text input component owns its label, placeholder, help text, and error message, and decides where validation messages appear. Because the rule lives in one place, error handling reads the same across every form in the product.
- →A card component groups an image, a title, supporting text, and an action into one unit with consistent internal spacing. It solves the grouping problem once so that lists of dissimilar content still feel like a set.
- →A modal component handles more than a panel over a dimmed background: it traps keyboard focus, restores focus to the trigger on close, and responds to the Escape key. Those behaviors are the real value of the component.
History
Modular thinking predates screens. Architecture and manufacturing spent the nineteenth and twentieth centuries moving toward standardized, interchangeable parts, because parts made to a shared specification could be produced, replaced, and combined without bespoke fitting. Graphical computing adopted the same logic early. The Xerox Star, released in 1981, presented a consistent set of on-screen objects and controls rather than letting each program invent its own. Toolkits that followed on the Macintosh and Windows gave developers ready-made menus, scrollbars, and dialogs. The web began with a small fixed set of form elements, then filled the gaps with framework libraries during the 2000s and 2010s. In 2016 Brad Frost's Atomic Design gave teams a vocabulary for composing small pieces into larger structures deliberately.
In Modern Design
A modern component library is maintained in two places at once: a design tool and a codebase. The goal is parity — the component a designer places and the component an engineer imports express the same contract, so a handoff is a reference rather than a reconstruction. Design tokens carry the shared values beneath both: color, spacing, radius, and type scale named once and consumed everywhere, so a change to a token propagates instead of requiring a hunt. Alla Kholmatova's work on design systems stresses that this only holds when the shared language is genuinely shared; a library with no agreement behind it fragments as fast as no library at all. Governance, naming, and documented intent matter as much as the components themselves.
Real-World Example
Think about a product with a dozen forms built by different teams over three years. Each form has a submit button. Without a component, one is blue with square corners, another is green with a spinner, a third disables itself silently while processing. A user who learned the first form gains nothing when they reach the third. Then an accessibility review finds that focus outlines are missing. With scattered buttons, the fix is a dozen separate changes, each with its own chance of being missed. With one button component, it is one change, deployed everywhere at once. The same argument applies to a rebrand, a new language with longer words, and a dark theme. The component is where all of those changes land.
Key Principles
- →A component is a contract, an appearance, and a behavior together, not simply a reusable drawing.
- →Name components by what they are and do, not by where they first appeared, or the name stops being true the moment the component is reused.
- →Every component needs its states defined — default, hover, focus, pressed, disabled, loading, error, empty — because undefined states get improvised inconsistently.
- →Compose small components into larger ones rather than building large components with many switches, since composition stays readable as requirements grow.
- →Shared tokens for color, spacing, and type let a single change propagate through the whole library instead of being applied by hand.
- →A component should be documented with its intent and its limits, so people know both when to use it and when not to.
Why it matters
Components are where consistency stops being an aspiration and becomes a mechanism. Teams cannot hold a hundred spacing and color decisions in their heads, and asking them to try produces exactly the drift that consistency was meant to prevent. Building the decision into a reusable part means the consistent choice is also the easiest one to make. That has consequences beyond appearance. Accessibility work, keyboard support, localization, and theming all become tractable when they live in shared parts rather than being reapplied to every screen. Components also change how teams spend their time: when the routine pieces are settled, the remaining attention goes to the parts of a product that are genuinely particular, which is where design judgment actually earns its keep.
Then vs Now
Then
Reusable controls arrived as platform toolkits. Developers used the menus, buttons, and dialogs the operating system supplied, and the look of a program came largely from the platform. Consistency was inherited rather than designed, and changing anything meant writing custom drawing code from scratch, so most software simply accepted the defaults it was given.
Now
Teams maintain their own libraries in design tools and code together, layered on tokens that carry brand and theme. Consistency is something an organization builds and governs rather than inherits. That brings freedom and obligation at once: the library must be documented, versioned, and kept honest, or it drifts back into the fragmentation it was created to prevent.
Try it yourself
Open a product you use daily and find every button in a single flow. Photograph or screenshot each one, then line them up and compare. Note the differences in height, corner radius, label capitalization, icon use, and what happens while the action is processing. Then write a one-page specification for a single button that could replace all of them: the properties it accepts, the emphasis levels it supports, and each state it must define. Be explicit about what it should refuse to do. Finally, look for a case in your collection that your specification cannot express, and decide whether that case is a genuine exception or simply an old inconsistency that was never questioned.