A UI component is a reusable, self-contained building block of a user interface, such as a button, text field, checkbox, card or dialog, with a defined appearance, set of variants and states, and behavior. In UI design, components let teams assemble screens from tested parts instead of drawing every element from scratch.
A component exists in two linked forms: a design asset in a design tool and a coded implementation in a front-end framework. When both share the same name, properties and rules, designers and developers speak one language, which is the foundation of every design system.
Anatomy of a UI component
Every component has an anatomy: the named parts it is made of. A text field, for example, consists of a label, the input container, placeholder or value text, optional icons, helper text and an error message. Naming these parts makes specifications and discussions precise.
Components are configured through properties (props) rather than redrawn. A button might expose a variant, a size, an optional icon and a disabled flag. The visual values behind these properties come from design tokens, such as color, spacing and typography variables, so that a change to a token updates every component that uses it.
| Element | Description | Button example |
|---|---|---|
| Anatomy | Named parts of the component | Container, label, optional icon |
| Variants | Alternative visual forms | Primary, secondary, tertiary, destructive |
| Sizes | Defined dimensional steps | Small, medium, large |
| States | Appearance in each interaction condition | Default, hover, focus, pressed, disabled |
| Properties | Configurable inputs | Label text, icon, loading flag |
| Design tokens | Shared style values | Color, radius, spacing, type scale |
Interaction states
A component is complete only when every interaction state is designed. Missing states are one of the most frequent causes of inconsistent interfaces, because developers must improvise them during implementation.
| State | Trigger | Design requirement |
|---|---|---|
| Default | No interaction | Clear affordance that it is interactive |
| Hover | Pointer over the element | Subtle change; not available on touch |
| Focus | Keyboard or programmatic focus | Visible focus indicator with sufficient contrast |
| Pressed or active | Click or tap in progress | Immediate visual feedback |
| Disabled | Action unavailable | Recognizably inactive, still readable |
| Loading | Action in progress | Prevents duplicate actions |
| Error | Invalid input or failed action | Message plus non-color indicator |
The focus state deserves particular attention. Accessibility guidelines such as WCAG require that keyboard users can see where focus is, so removing the focus outline without a replacement is a serious defect.
Levels of UI components
Components range from simple to composite. The atomic design model describes this as a hierarchy in which small parts combine into larger ones, which helps teams decide where a new piece belongs.
| Level | Examples | Characteristics |
|---|---|---|
| Primitives (atoms) | Button, icon, label, input | Smallest reusable units |
| Composite components (molecules) | Search field with button, form field with label | Several primitives with one purpose |
| Patterns (organisms) | Navigation bar, data table, card list | Larger sections combining components |
| Templates | Page layouts with placeholders | Structure without final content |
UI components in relation to other design artifacts
Components connect several artifacts of the design process. Wireframes describe where elements go, components define what each element is and how it behaves, and the design system governs the whole library.
| Concept | Scope | Relationship to components |
|---|---|---|
| UI component | One reusable element | The unit itself |
| Design system | Components, tokens, guidelines and governance | Contains and maintains the component library |
| Wireframe | Low-fidelity screen structure | Uses simplified placeholders for components |
| Mockup | High-fidelity static screen | Assembled from finished components |
| Prototype | Interactive simulation | Shows component behavior and transitions |
Designing robust components
A good component works with real, unpredictable content. Labels may be long, translated into languages that expand text by 30 percent or more, or set at larger user font sizes. Components should therefore use flexible layout rules such as auto layout and defined minimum and maximum widths.
- Too many variants make a component hard to choose and maintain; a variant should exist only when it serves a distinct purpose.
- Detaching instances in design files breaks the link to the main component, so later updates no longer apply.
- Touch targets below about 44 by 44 points are difficult to tap on mobile devices.
- Color as the only state indicator excludes users with color vision deficiencies.
- Design and code drift occurs when the coded component changes without the design asset, or the reverse.
Mature teams document each component with usage guidelines: when to use it, when not to use it, accessibility behavior and content rules. Documentation turns a visual asset into a shared, reliable decision.
The short version
A UI component is like a standard building brick for apps and websites. A button, a search box or a pop-up window is designed once, carefully, and then reused wherever it is needed.
Because the same brick is used everywhere, the app looks and works consistently, and improving the brick once improves it on every screen. This saves time and makes the product easier to use.
Where it makes a difference
A company maintains three web applications in which designers had drawn buttons independently over several years. An audit finds more than twenty different button styles, several without a visible keyboard focus state.
The design team creates one button component with four variants, three sizes and seven defined states, built on shared color and spacing tokens. Developers implement a matching coded component, and both versions use identical property names.
Within a few releases, the old buttons are replaced. New screens are assembled faster, accessibility reviews stop flagging missing focus indicators, and a later brand color change is applied by updating a single token rather than editing every screen.