UI Library Glossary: 21 Terms Every Team Should Know

UI library terms can sound more complicated than the work itself. You may hear someone mention tokens, primitives, variants, or atomic design in the same meeting. This glossary explains what those words mean and, more importantly, when they are useful.

It is written for designers, developers, founders, and anyone who helps ship a product interface. You do not need to build a huge design system to benefit from these ideas. Start with the terms that solve a real problem for your team today.

Key takeaways

• A UI kit is a collection of ready-made visual pieces. A design system adds the rules that explain how and why to use them.
• Reusable components make common interface work faster, but only when their names, states, and documentation stay clear.
• Design tokens and semantic tokens keep colors, spacing, and type consistent while making themes and dark mode easier to manage.
• Accessibility is not a finishing pass. It belongs in every component from the first version.

UI Component Library

A UI component library is a shared collection of interface pieces, such as buttons, inputs, modals, and navigation. Each piece is built so a team can use it in more than one screen or product area.

Think of it as a toolbox for building interfaces. Before creating a new button, check the library first. If the right option already exists, use it and keep the product consistent.

UI Kit

A UI kit is a set of ready-made visual assets and components. It may include Figma files, code components, icons, color palettes, and page sections.

UI kits help you move quickly at the start of a project. They do not always include guidance for edge cases, content rules, or product decisions, which is where a design system becomes more useful.

Design System

A design system is the shared language behind a product interface. It combines components with rules for color, typography, spacing, voice, accessibility, and use.

A library tells you which button to use. A design system also tells you when a button should be primary, what its disabled state means, and how it should work with a keyboard.

Pattern Library

A pattern library collects common solutions to larger interface problems, such as checkout flows, empty states, search results, or account settings. A pattern usually combines several components.

Use a pattern library when teams keep solving the same user journey in slightly different ways. It saves time and gives people a more predictable product experience.

UI Component

A UI component is one focused part of an interface with a clear job. A button triggers an action. An alert communicates a status. A card groups related information.

Good components are small enough to understand and complete enough to use safely. Give each component one main responsibility before adding options to it.

Reusable Components

Reusable components are components designed for repeated use. They accept the few inputs they need, then render the same reliable behavior and visual structure everywhere.

Reuse should remove duplicate work, not force unrelated screens into the same shape. If a component needs many one-off exceptions, split it into a simpler shared piece and a page-specific wrapper.

Component-Based Design

Component-based design means building a product from connected, reusable parts instead of treating every screen as a unique drawing. Designers and developers can work from the same building blocks.

This approach makes changes safer. Update the shared component once, then review its uses instead of editing a similar control on every page by hand.

Atomic Design

Atomic design is a way to organize interface pieces by size and purpose. It starts with atoms, combines them into molecules, and groups those into organisms.

An atom is a basic part, such as a label or an icon. A molecule could be a label and input together. An organism could be a complete sign-up form. Use this model when it makes your library easier to navigate, not as a rule every file must follow.

Design Tokens

Design tokens are named values for repeated design choices. They can represent a color, a font size, a spacing step, a border radius, or a shadow.

Instead of putting the same blue value in twenty places, define a token once and use its name. This makes a visual update controlled and easier to review.

Semantic Tokens

Semantic tokens describe a job rather than a raw value. For example,text-primary says what a color is for, while blue-600 only says what it looks like.

Prefer semantic tokens in product code. They let you adjust a theme or add dark mode without hunting through every component for a color name.

CSS Variables

CSS variables are browser-supported names for values in CSS. They often carry design tokens into a live product, for example --color-surface or --space-4.

They are especially useful for theming because a parent element can change a value for everything inside it. Keep the names meaningful so other people can tell what they control.

UI Primitives

UI primitives are low-level building blocks that handle a single interaction or structure. A dialog primitive, for example, may handle focus and keyboard behavior without deciding its final appearance.

Build on primitives when several product components need the same hard behavior. They give you a solid base while leaving the visual design to your team.

Headless UI

Headless UI describes components that provide behavior and accessibility but very little styling. You bring your own markup and visual design.

It is a good fit when your product has a distinct visual language and you do not want to undo a library's default styles. It still saves you from rebuilding tricky interaction details from scratch.

Unstyled Components

Unstyled components are similar to headless components. They focus on structure, state, and behavior, then leave the final look to you.

The terms are often used interchangeably. When choosing a library, look beyond the label and check what markup, accessibility support, and styling control it actually gives you.

Component Variants

Component variants are approved versions of the same component. A button may have primary, secondary, and danger variants because each one communicates a different level of importance.

Add a variant when the difference has a repeatable meaning. Do not add one just to make one page look different. That is how a small component becomes difficult to use.

Props

Props are the inputs passed into a component. They can provide text, data, a state, an event handler, or a small visual choice such as a size or variant.

Good props are easy to predict. Name them after what they do, give common choices sensible defaults, and document the few combinations that should not be used together.

Theming

Theming is the process of applying a coordinated visual set to an interface. A theme can change colors, type, radii, and other tokens without changing a component's purpose.

Start with tokens before you add theme controls. When components use semantic values, a new theme is a controlled swap of values instead of a pile of component overrides.

Dark Mode

Dark mode is a theme that uses darker surfaces and adjusted text, border, and accent colors. It is not simply a white background turned black, because contrast and visual weight change too.

Test real screens in both modes. Check disabled controls, shadows, data charts, images, and focus rings. Those details often reveal that a token is too specific or a component is relying on a raw color.

Accessible Components

Accessible components work for people using keyboards, screen readers, zoom, reduced motion, and other assistive tools. They also make the interface clearer for everyone.

Start with native HTML where it fits. Then test keyboard navigation, visible focus, labels, contrast, error messages, and motion. A component is not finished until those basics work.

Component Documentation

Component documentation explains what a component is for, which props it accepts, what its variants mean, and how to use it well. It turns a pile of code into a tool other people can trust.

Keep documentation close to the component and update it with the code. A short list of good and bad examples is more useful than a long description no one can scan.

Storybook

Storybook is a tool for viewing and testing components in isolation. Each story shows a component in a specific state, such as an empty input, an error alert, or a loading button.

Use it when your library has enough components and contributors to benefit from a shared visual workspace. For a very small product, clear examples in the app may be enough at first.

Where to start with a UI library

Begin with the repeated interface problems that slow your team down. A button, input, badge, alert, and dialog are often enough for the first pass. Document the intended use for each one, then add tokens for the values you keep repeating.

Next, make accessibility checks part of the component definition. When a second screen needs the same pattern, reuse it. When a real need appears that the component cannot handle, improve the shared component or create a new one with a clear purpose.

A useful library grows from real product work. It does not need every possible component on day one. Keep it small, clear, and easy to use.