Which statement best captures the working definition of a UI component used in this lesson?
Choose an answer, then check it.
UX/UI Design · Foundations
Components
On this page 9 sections
In 30 seconds
Components are the reusable building blocks of an interface: buttons, input fields, menus, cards, and more. Each is a ready-made piece with a defined look and behavior, and the core rule is consistency The rule that the same component looks and behaves the same way everywhere it appears. Full entry →: the same component A reusable piece of the interface, such as a button, a menu, or a card, with a defined look and behavior. Full entry → should look and behave the same everywhere. Components assemble into pages, and each one moves through states such as default, hover, pressed, disabled, and loading. Well-built components carry clear labels and work with the keyboard. Their quality, though, depends on the defaults a design system gives them.
Why this matters
People learn an interface through its components. A Save button that looks and works like every other Save button lets users act without thinking; the same button redrawn differently on each screen forces them to relearn the app every time. Consistency is what makes components trustworthy, and trust is what makes users fast. Components are also the shared vocabulary of design and development teams: when a dropdown is one defined thing, nobody argues about what it should do. Knowing what components are, how they behave in each state, and where their quality comes from separates interfaces that feel solid from interfaces that feel scrambled.
The college version
What a component is
The working definition of a component comes from two sources. Nielsen Norman Group defines a design system as a complete set of standards intended to manage design at scale using reusable components and patterns, which makes components the reusable pieces teams assemble into screens. The U.S. Web Design System states it more plainly: its components are simple and consistent solutions to common user-interface needs. Put together, a component is a reusable piece of the interface, a button, a menu, or a card, built once with a defined look and behavior, then used over and over. Components are the building blocks of an interface the way bricks are the building blocks of a wall: each piece is ordinary on its own, yet the same piece appears in hundreds of places. An original example: a recipe app has one Search Recipes button component. Whether it appears on the home screen, the browse screen, or the saved list, it is the same component with the same shape, color, and response when pressed. The team never redraws it; they reuse it. That one decision, repeated across an entire interface, is what components are for.
The common components
Every interface is assembled from a familiar cast of components, and each has a typical job. A button draws attention to an important action, which the U.S. Web Design System describes as a large selectable surface, and it is the standard way to say do this now, like the Pay Now button on a checkout screen. An input field lets users enter text, such as a search box or a shipping-address line. A dropdown, also called a select, lets users choose one option from a list, which suits many choices, like picking a country from several dozen. A checkbox lets users select one or more options from a list, typical for settings such as email me a receipt. A card groups content and actions about a single subject, the standard container for a product, a contact, or a news story. A modal A component that disables the page behind it to focus attention on one task or message. Full entry → disables the page behind it and focuses attention on one task or message, which makes it right for a forced choice like confirming a deletion. A navigation bar helps users see where they are and reach the main sections of a site. A toast A small, temporary notification that appears briefly to confirm an action such as a saved change. Full entry → is a small, temporary notification that confirms an action, such as Settings saved, appearing and disappearing on its own. Each component exists because a common need recurs, and reusing one piece is cheaper and more reliable than inventing a fresh piece every time.
Consistency, and components versus pages
The core rule of components is consistency: the same component should look and behave the same everywhere. Nielsen Norman Group explains the payoff: premade UI components let teams replicate designs quickly, reducing the need to reinvent the wheel and the risk of unintended inconsistency, and they create visual consistency across products and channels. Consistency has two halves. Visually, a button should not change its shape or color from screen to screen. Behaviorally, a component that opens a menu when clicked should open a menu every time, not a link on one screen and a menu on the next. An original example: a travel site whose calendar opens as a pop-up on some pages and navigates to a new page on others breaks the rule, because users click and guess. Components also stand in a clear relationship to pages. A component is a piece; a page is a whole screen assembled from pieces. A checkout page, for instance, is built from a card, two input fields, a country dropdown, a terms checkbox, and a button, with layout deciding how the pieces are arranged. Layout is its own topic in this course, so this lesson only marks the boundary: components are the parts, pages are the assembled whole, and layout is the arrangement.
States, accessibility, and the honest framing
A component is not one thing; it is a set of states it moves through as people interact with it. The U.S. Web Design System documents five core button states: default, the resting look; hover, when the pointer sits over the component; active, the brief moment of the press; focus The state of a component selected by the keyboard, marked with a visible outline. Full entry →, when the component is selected by keyboard; and disabled, when the action is unavailable. Many components add a loading state The appearance of a component while the system completes an action it started. Full entry →: while an action such as a payment processes, the button shows a small progress indicator so users know the click registered and the system is working. Accessibility is a general requirement built into components, not an add-on. The W3C Web Accessibility Initiative asks that form elements include clearly associated labels and that every interactive element be keyboard accessible, and the U.S. Web Design System adds that components must show a visible focus state when users tab to them. The honest framing closes the lesson: components are only as good as the defaults behind them. A component is a promise, this thing looks like this and does this, and someone must keep that promise. Design systems, covered in their own lesson in this course, define the defaults that make components consistent, accessible, and reusable. Without those standards, a pile of components is just a pile of parts.
Eli explains
The same idea, in plain words
Explain it like I’m 10
Components are the building blocks of an app or website. They are ready-made pieces of the interface, like buttons, menus, cards, and text boxes, and they get reused all over the place. Instead of drawing a new button for every screen, a team builds the button once and drops it in wherever it is needed. The golden rule is consistency: the same piece should look and behave the same way everywhere, so a button that saves your work on one screen acts the same on every screen. Components also have states: how they look when nothing is happening, when your pointer hovers over them, when you click them, when they are turned off, and when they are busy loading. Good components have clear labels and work with the keyboard, and their quality depends on the defaults the team sets for them.
Picture it like this
Think of components as building bricks. One brick is simple, but the same brick can be part of a house in one build and a tower in the next. You do not carve a new brick every time; you reach for the same one, and it clicks together with the others the same way every time.
Where the picture stops working
Bricks are mechanical and identical, while interface components carry meaning: a button promises an action, a card promises grouped content, and each has states and accessibility needs. And unlike bricks, a component's quality depends on the standards the team sets, so two teams with the same component list can build very different products.
Worked example
A team redesigning a city transit app noticed riders double-tapping the Buy Ticket button and getting charged twice. The old app drew a fresh button on every screen, so on the schedule screen the button looked like a link, and on the map screen it changed shape when pressed. The team replaced every variant with one Buy Ticket component: the same blue pill everywhere, with the same default, hover, pressed, disabled, and loading states. Riders now saw the button gray out and show a small spinner while the payment processed, and the double charges stopped. The team also gave the component a clear label and a visible keyboard focus, and tested it with five riders who navigate by keyboard.
Key takeaway
Components are reusable pieces of the interface, and the core rule is consistency: the same component must look and behave the same everywhere. Components assemble into pages, move through states, and need labels, keyboard access, and focus; they are only as good as the defaults a design system gives them.
Quick check
3 questions here, of 5 in this lesson’s practice set. Answers stay hidden until you check.
What is the core consistency rule for components?
Choose an answer, then check it.
A rider rests the mouse pointer over the Buy Ticket button without clicking. Which state is the button in?
Choose an answer, then check it.
Study tools & related lessonsYou’ll learn to · Common mistakes · Easily confused · Key vocabulary · Related
You’ll learn to
- Define a component using the working definition from Nielsen Norman Group and the U.S. Web Design System: a reusable piece of the interface, such as a button, a menu, or a card.
- Name common components, including buttons, input fields, dropdowns, checkboxes, cards, modals, navigation bars, and toasts, and say when each is typical.
- State the core consistency rule: the same component should look and behave the same everywhere.
- Distinguish components from pages: assembled pieces versus whole screens.
- Identify the component states: default, hover, pressed, disabled, and loading.
- Explain the general accessibility requirements in components (labels, keyboard use, focus) and why components are only as good as their defaults.
Common mistakes
Redrawing components for every screen. If each page gets its own button or card, the interface looks like a patchwork and users must relearn it constantly; reuse the same component everywhere.
Letting states drift. A button whose hover looks like a link, or a disabled control that still looks clickable, breaks the promise of the component; every state should be distinct and consistent.
Overusing modals. A modal blocks the whole page, so using one for a trivial message forces users to stop and dismiss it; reserve modals for tasks that truly need full attention.
Skipping labels, keyboard support, or focus. A component without a clear label or a visible focus state fails users who rely on screen readers or keyboards.
Assuming components carry themselves. A component is only as good as the defaults a design system gives it; without defined standards, the same component can drift apart across screens.
Easily confused
Component vs. Page
A component is a single reusable piece, such as a button or a card; a page is a whole screen assembled from components, with layout deciding the arrangement.
Hover state vs. Focus state
Hover appears when the pointer rests over a component; focus appears when the component is selected by keyboard and must stay visible so keyboard users can tell where they are.
Modal vs. Toast
A modal blocks the page and demands attention until dismissed, while a toast is a brief notification that appears and disappears on its own without blocking anything.
Key vocabulary
- component
- A reusable piece of the interface, such as a button, a menu, or a card, with a defined look and behavior.
- consistency
- The rule that the same component looks and behaves the same way everywhere it appears.
- default state
- The resting appearance of a component when no interaction is happening.
- hover state
- The appearance of a component while the pointer rests over it.
- pressed state
- The brief appearance of a component while it is being clicked.
- disabled state
- The appearance of a component whose action is currently unavailable.
- loading state
- The appearance of a component while the system completes an action it started.
- modal
- A component that disables the page behind it to focus attention on one task or message.
- toast
- A small, temporary notification that appears briefly to confirm an action such as a saved change.
- focus
- The state of a component selected by the keyboard, marked with a visible outline.
Sources & references
- Components Overview — U.S. Web Design System (USWDS)
- Button — U.S. Web Design System (USWDS)
- Design Systems 101 — Nielsen Norman Group (NN/g)
- Designing for Web Accessibility – Tips for Getting Started — W3C Web Accessibility Initiative
- Developing for Web Accessibility – Tips for Getting Started — W3C Web Accessibility Initiative (WAI)
- W3C WAI — Labeling Controls — W3C Web Accessibility Initiative
EliExplains lessons are original prose written from the open, credible references above. See Copyright & Licensing.
Researched 2026-08-21
Educational content only. It is not medical, legal or professional advice. Found an error? Tell us.