Glossary · 16 concepts
Terms you can use in practice.
Definitions are connected to product consequences, examples, related concepts, and a place to continue learning.
01Design system
A maintained set of shared decisions, guidance, assets, and practices for creating coherent product experiences.
- Why it matters
- It connects how an organization decides, designs, builds, documents, and changes interfaces.
- Example
Foundations + components + patterns + content + accessibility + governance- Related
- Component library · Governance · Foundations
- Explore
- Fundamentals
Component library
A collection of reusable interface implementations with defined APIs.
- Why it matters
- It accelerates delivery, but does not supply every rule, pattern, or governance process a design system needs.
- Example
A React package containing Button, Dialog, and DataTable- Related
- Design system · Component API · Composition
- Explore
- Components module
UI kit
A set of reusable design assets, often maintained in a design tool.
- Why it matters
- A kit improves production speed but may not document behavior, code, accessibility, contribution, or release status.
- Example
A Figma library of foundations and component variants- Related
- Component library · Design system · Design-to-code
- Explore
- Fundamentals
Foundation
A shared visual, behavioral, or content decision that supports many components and patterns.
- Why it matters
- Foundations make recurring choices—such as color roles, spacing, type, motion, and voice—intentional and governable.
- Example
A focus indicator role used by every interactive component- Related
- Token · Theme · Design language
- Explore
- Foundations
Primitive token
A named raw value with little or no contextual meaning.
- Why it matters
- Primitives centralize the available palette, but components that reference them directly become difficult to retheme safely.
- Example
blue.600 → #2864D7- Related
- Semantic token · Alias · Token hierarchy
- Explore
- Design tokens
Semantic token
A named design value tied to purpose rather than raw appearance.
- Why it matters
- A stable role can point to different values across themes without changing component code.
- Example
color.text.muted → neutral.600- Related
- Primitive token · Component token · Theme
- Explore
- Token Lab
Component token
A design token scoped to a component, property, variant, or state.
- Why it matters
- It exposes precise control when a shared semantic role is too broad, but too many component tokens create maintenance overhead.
- Example
button.background.danger.hover- Related
- Semantic token · Component API · State
- Explore
- Design tokens
Alias
A reference from one token to another rather than a duplicated literal value.
- Why it matters
- References preserve meaning and allow a change to flow through the system without editing every consumer.
- Example
button.background.default → color.action.primary → blue.600- Related
- Token hierarchy · Theme · Semantic token
- Explore
- Token Lab
Theme
A coordinated mapping of design roles for a brand, mode, platform, density, or accessibility context.
- Why it matters
- Themes let the same component contract adapt without scattering local overrides through product code.
- Example
surface.primary maps to white in light mode and neutral.950 in dark mode- Related
- Mode · Semantic token · Contrast
- Explore
- Design tokens
Component API
The controlled properties, events, slots, and states through which a component can be configured.
- Why it matters
- A good API exposes meaningful product choices while preventing unsupported or inaccessible combinations.
- Example
Button: emphasis, size, disabled, loading, icon, onPress- Related
- Variant · Slot · State
- Explore
- Components
Variant
A supported form of a component that represents a meaningful use case or hierarchy choice.
- Why it matters
- Variants turn recurring differences into documented decisions instead of one-off styling.
- Example
Primary, secondary, and destructive action emphasis- Related
- Component API · State · Property
- Explore
- Button
Pattern
A reusable decision model that combines components, content, behavior, and policy to solve a recurring user problem.
- Why it matters
- Patterns preserve task logic and recovery across layouts rather than standardizing a single screenshot.
- Example
Destructive action: trigger → consequence → confirmation → result or undo- Related
- Component · Flow · Policy
- Explore
- Patterns
Governance
The responsibilities and decision mechanisms that control how a system evolves.
- Why it matters
- Without ownership, contribution, release, and deprecation practices, consistency decays even when component code is good.
- Example
Proposal → review → testing → release → adoption → deprecation- Related
- Contribution · Ownership · Versioning
- Explore
- Governance module
Deprecation
A managed period in which a system capability remains available but is scheduled for retirement.
- Why it matters
- Consumers need rationale, alternatives, migration support, and time to change without breaking products.
- Example
OldButton remains for two releases while teams migrate to Button- Related
- Versioning · Migration · Governance
- Explore
- Governance
Design-code parity
Alignment between the intent, choices, states, and outcomes represented in design tools and implementation.
- Why it matters
- Parity reduces contradictory specifications, but does not require Figma and code to expose identical APIs.
- Example
A Figma loading property maps to busy semantics, code state, and a tested visual treatment- Related
- Component API · Token · Documentation
- Explore
- Design to code
Focus management
The intentional placement and restoration of keyboard focus as content, routes, and overlays change.
- Why it matters
- Without it, keyboard and screen-reader users can lose their location even when every control is individually operable.
- Example
Opening a dialog moves focus inside; closing returns focus to the logical trigger- Related
- Keyboard · Dialog · Focus order
- Explore
- Accessibility