Glossary

Building so the widest range of people can actually use what you ship, including someone on a keyboard, a screen reader, or a phone in bright sun. In a system it pays off twice: get a component right once and every team that uses it inherits the work.

How much of your organization actually reaches for the system day to day. A beautiful library sitting untouched still counts as zero here. Adoption is the number that tells you whether any of the work landed.

A packaged set of instructions that teaches a coding agent how to work with your system: which components to reach for, which rules not to break, how to migrate from an old version. Think of it as onboarding for a new teammate who reads very fast and forgets everything between sessions.

How well a design system can be understood and used correctly by AI tools as well as people. Clear names, documented props, machine-readable docs and explicit rules all help. Most of it turns out to be the same work that makes a system easier for humans, done a little more consistently.

The named parts a component is made of: the container, the label, the icon, the helper text underneath. Naming them gives designers and engineers the same words for the same pieces, which makes specs easier to read and arguments shorter.

Attributes that tell assistive technology what a custom control is and what state it's in: this div is a tab, this menu is open. The first rule of ARIA is to use a native element if one exists. The second is that bad ARIA is worse than none, because it tells a screen reader something untrue.

Any update that forces the people using your system to change their code: a renamed prop, a removed component, a token pointing somewhere new. It's not always avoidable, but it should never be a surprise. Major versions, migration guides and deprecation windows all exist so it isn't.

One dedicated team owns the system and builds it for everyone else. Quality and consistency are easier to hold. The risk is becoming a bottleneck, with product teams stuck in a queue they can't see. Plenty of systems land somewhere between this and a federated model.

A script that rewrites the code using your system during a migration: renaming props, swapping imports, moving old patterns to new ones. One good codemod can turn a month of find-and-replace across fifty repos into an afternoon of reviewing pull requests.

A set of color values the whole interface can switch between, usually light and dark, often with a high-contrast option too. Components shouldn't need to know which mode they're in. If they do, somebody hardcoded a color, and dark mode is where you'll find it.

A reusable piece of interface, built once and used everywhere: a button, an input, a card. What you're really shipping is the decisions baked into it, the padding, the states, the focus behavior. Get those right once and the next person doesn't rebuild them (or get them wrong without noticing).

The named stages a component moves through, from proposal to experimental to stable, and eventually to deprecated. Publishing them tells teams how much to trust what they're picking up. An experimental component carries no promise it'll look the same next month, and that's fine, as long as everyone knows it.

A token scoped to one component, like button-background, that points at a semantic token underneath. It gives a component room to differ without touching the shared layer. Useful in moderation. Make one for every property and you've rebuilt the hardcoded values you were escaping, just with longer names.

Treating interface words as part of the system, not whatever got typed in at the end. Button labels, error messages, empty states, the tone when something goes wrong. Write the rules down once and a confirmation dialog reads the same whether it was built in London or Lisbon.

A number for how distinguishable two colors are, from 1:1 (identical) to 21:1 (black on white). WCAG asks for 4.5:1 for body text and 3:1 for large text and interface parts. Some systems build it into the color scale, so you can spot a safe pair from the token names.

The agreed path for getting something new into the system. Who proposes, who reviews, how it gets built and documented. Without one, people either stop asking and build their own thing, or everything funnels through one exhausted person.

How much of the system exists and is available to use. A different question from adoption, and an easy one to confuse. You can have ninety percent coverage and barely any adoption, which usually means the parts are there but something's making them hard to pick up.

Guidance for charts and the other ways a product shows numbers: which chart fits which question, the colors each data series gets, how labels and axes behave. It's the corner of a system that gets skipped until the first dashboard ships with a legend nobody can match to its lines.

How tightly an interface packs its content, often a setting like comfortable or compact. Same components, different spacing. Someone scanning five hundred rows wants compact; someone filling in a form once a year wants room to breathe. Build density into the spacing tokens and both get what they need.

Retiring something without ripping it out overnight. You mark it as on the way out, point people to what replaces it, and give teams a real window to migrate. Done well, nobody wakes up to a broken build.

The shared set of decisions a team keeps reaching for so nobody makes them from scratch every time. Colors, type, spacing, the components built from them, and the guidance for when to use what. There's a library of files in there somewhere, but the useful part is the agreement underneath it: this is how we build things here.

A named value that stands in for a raw one. Instead of writing #0B5FFF in fifty places, you write color-primary and point it at the blue. Change the token and everywhere that used it updates at once. Small idea, enormous payoff the first time a brand color changes the week before launch.

The route a decision takes from a design file to shipped code, and how the two stay in step afterward. Tokens synced between Figma and the repo, components that map one to one, specs an engineer can read without a meeting. When it breaks down, you get drift.

The part everyone underrates until they're the new person trying to use a component with no idea how. Good docs answer the questions people were about to ask: when to use this, when not to, and what happens at the edges.

What happens when the real product and the system slowly stop matching. A color gets tweaked on one screen, a component gets forked "just for this page," and six months later there are fourteen blues and nobody remembers why. Drift is normal. Catching it early is the job.

The standard file format for design tokens, from the W3C Design Tokens Community Group. It sets out how a token file describes values, types and references, so one tool can read what another exported. Before it settled, every tool had its own flavor of JSON and moving between them meant glue code.

A way of running a system where the teams who use it also build and maintain it, with no dedicated central team. It spreads ownership and keeps the system close to real product work. It also tends to stall whenever everyone's own roadmap comes first, which is most of the time.

The base layer everything sits on: color, typography, spacing, elevation, motion. Get these consistent and the rest tends to fall into place. Get them wrong and you feel it in every component downstream.

The rules for how the system changes and who gets a say. Sounds heavier than it needs to be. At its best it's just enough structure to keep things coherent without turning every small change into a committee meeting.

A component that handles the behavior (keyboard support, focus, ARIA state) and ships with no styling at all. You bring the look. Plenty of systems build on a headless library so the fiddly parts come already done, and the team can spend its time on tokens instead of focus traps.

Building a product so it works in any language and region without being rebuilt each time. Text that grows by a third in German, dates written day first, layouts that mirror for Arabic. Handle it once in the components and no team finds out the hard way in a new market.

An automated check that flags off-system code before it ships, like a raw hex value where a token should be. Lint rules turn guidance people might skim into feedback they can't miss. They won't catch everything, but they catch the boring things every time.

A set of stages for describing how far along a system, or a team's use of it, has come. The useful ones count partial progress. A team that follows the principles but can't use the code yet is still further along than one that's never heard of the system.

A standard way for AI tools to query an outside source while they work. Give a design system an MCP server and an assistant can look up real components, props and tokens instead of guessing from its training. You notice the first time it reaches for a prop that exists.

How things move on screen: how long a transition takes, how it eases, and what moves first when several things change at once. Good motion explains what just happened. Bad motion makes people wait, or feel slightly seasick, so the best systems pair every animation with a reduced-motion version.

One set of components serving several brands, each with its own colors, type and personality. The components stay put; the tokens underneath change per brand. Done well, a new brand is mostly a new set of values. Done badly, it's a fork of the library with a different logo on the front.

The agreed pattern for what things are called. Boring to decide, painful to skip. Consistent names are how someone finds color-text-muted on the first guess instead of grepping the whole library.

A repeatable way of solving a common problem, usually several components working together. A form, an empty state, the way you confirm something destructive. Components are the parts; patterns are how you assemble them into something that behaves.

Also called a raw or global token. The actual values, named for what they are: blue-500, space-8, font-size-16. This is the raw material, the full paint set. You rarely point a design straight at these.

The options a component exposes: its size, its label, whether it's disabled. Together they're the component's public contract. Adding a prop is easy. Taking one away is a breaking change for everyone using it, so good systems think twice before letting a new one in.

A token named for its job rather than its value, so color-text-danger instead of red-600. It points at a primitive underneath, but the name tells you where it belongs, so a teammate reading color-background-raised knows what it's for without hunting for the hex. This is the layer that makes theming and rebrands survivable.

The one place a decision officially lives, so people stop keeping their own slightly different copies. The hard part is rarely the tooling. It's getting everyone to check the same spot before inventing a new answer.

A placeholder inside a component where other content goes, like the body of a dialog. Slots let a component stay flexible without growing a prop for every possible use. Figma supports them now too, so fewer people detach an instance just to squeeze something in.

Swapping one set of values for another without rebuilding anything. Light mode and dark mode are the obvious case. It only works if your components lean on semantic tokens instead of hardcoded values, which is the whole reason that layer exists.

A version of a component that changes with the situation. A button that's primary or secondary, small or large, with an icon or without. Same component, different clothes for different jobs.

A shared way of numbering releases so people know what a change will do to them. Major for breaking changes, minor for new things, patch for fixes. The number is really a promise: bump the major and you're telling everyone to read the notes before they update.

The Web Content Accessibility Guidelines, the standard most accessibility work is measured against. Its criteria sit at three levels, A, AA and AAA, and AA is the one most teams and most laws aim for. Passing doesn't make something pleasant to use. Failing is a reliable sign someone can't use it at all.

Components built on browser standards instead of a particular framework, so the same button works in React, Vue, Angular or a plain HTML page. Big organizations running lots of different stacks like them for exactly that reason. The trade-off is that some framework conveniences take more work to recreate.