This design glossary offers clear UI/UX terminology and definitions to help designers and non-designers speak the same language.
Getting design right in a company isn’t just about pretty screens — it’s about processes, systems, and teamwork. But all the terms around DesignOps, design systems, and product design can get confusing, and there isn’t always a clear definition in a regular dictionary.
This design glossary gives you simple, clear explanations for common DesignOps terms, from UI and UX to tokens, workflows, and accessibility — everything you need to talk about design like a pro and keep your team on the same page.
Accessibility (a11y) is a principle of making a product easy to use for everyone, including people with disabilities. In DesignOps, accessibility is embedded into every step of product development — from UI design through to development. In simple words, designers check it in Figma using the appropriate plugins.
Adoption is the process where teams actually use the documentation and component library in their projects and follow the rules of the system.
Affinity diagram is a method that helps a team organize large amounts of information — ideas, notes, research results — into groups to see patterns and common themes. The team jots down their thoughts on sticky notes or in a digital tool. The notes are then sorted by meaning, and similar ones are grouped together. The result is key patterns, priorities, and focal points for further work.
Agile is an approach where a team works in stages, tries out ideas, and implements product improvements, such as design systems, in parts, with the ability to immediately test how it works in practice. The authors of the Agile Manifesto chose “Agile” as the label for this whole idea to emphasize the importance of adaptability and responsiveness to change. Designers, developers, and managers constantly exchange feedback, priorities can change, and the team quickly adapts to new challenges.
API (application programming interface) is a tool that allows the team to plug ready-made components, styles, and layouts into the product automatically, without manual copying. For example, there is a library of UI components in Figma or Storybook, and developers use the API to pull up-to-date versions of buttons, shapes, and colors straight into the code.
Atomic design is a way to build interfaces step by step. Start with tiny pieces like buttons and icons (atoms), combine them into small functional blocks (molecules), then group those into bigger sections like headers or cards (organisms), and finally assemble full pages or templates.
Backend is the “invisible engine” of the design system. It stores and returns components, tokens, content, and other artifacts that designers and developers use. Through the API, this data can be delivered to the web, mobile apps, widgets, and other platforms. It automates the synchronization of changes — update a component in the code, and it is immediately available to everyone. The backend supports CI/CD, testing, and versioning, and provides a stable source of data for the frontend and design system. This ensures all teams work with the same rules and elements. It also facilitates the headless approach, makes processes repeatable and scalable, stores logic and data, allowing designers to focus on creativity, and developers on implementation.
Branching is the creation of separate lanes for your code so different people can work on features or fixes at the same time without crashing into each other. It helps teams keep the design system and components in sync while everyone works in parallel.
Brand rules are the guidelines that define how a brand shows up in a product. They are expressed through tokens — colors, fonts, spacing — and behavior patterns that keep everything consistent.
CD (continuous delivery / continuous deployment) is a practice where changes are ready for release at any time, but their actual release can happen manually on a specific day (continuous delivery) or automatically rolled out to users immediately after verification (continuous deployment).
CI (continuous integration) is a practice where design changes (layouts, components, styles) are regularly merged into a common project, and the system immediately checks that everything works together.
Component library is a range of ready-to-use UI pieces that can be reused and make building interfaces way easier. Among these elements are a Web Component, a simple UI kit with HTML/CSS/JS files, or a framework-specific package like npm for React/Vue/Angular. To design a full page, you just need to pick the components from the library and combine them.
Content guide is a set of best practices and rules for writing clear, consistent, and on-brand text across a product.
Consistency is a principle where everything in the product is done the same way, so that it is clear to the user and easy for the teams to work with. Buttons are the same color and size everywhere. The registration form and the payment form work the same way. All teams use the same components from the design system.
CX (customer experience) is the overall experience people have when they interact with your product or brand. In DesignOps, it’s not just about designing nice screens — it’s about making sure every touchpoint works together: the interface, the content, the performance, the accessibility. DesignOps here helps to embed CX into processes so that designers, developers, and product teams work not for the sake of “pixels”, but for the sake of the holistic experience: from the usability of the interface to accessibility, responsiveness, and even the tone of the text.
Design crit (design critique) is a meeting not about nitpicking but about discussing ideas, looking for improvements, and agreeing on solutions.
Design debt is the kind of “debt” in design that accumulates when a team makes quick decisions but does not adhere to the overall system. As a result, old and new components can be mixed, layout margins may not match, and buttons may look different on different pages. Everything works, but over time, it becomes more difficult to maintain the product and make new features. DesignOps helps to see and gradually close such “design debt” so that the system remains clean and convenient.
Design documentation is all the materials that explain how to use the design system and its components; in other words, what buttons, colors, indents, and patterns are in the system, why they are needed, and how to use them.
Design maturity is the level of “maturity” of design in the company, in other words, how much design is integrated into the processes and impacts of the product. At a low level, design is done “by eye” and with no real system. At a medium level, there are rules and a component library, but they are not always applied. At a high level, design is managed through processes, metrics, and DesignOps, and really helps the business grow.
DesignOps (design operations) is the set of systems and workflows that keep design work consistent, scalable, and impactful from idea to launch. In practice, it pulls everyone onto the same page — designers, developers, product folks, researchers, marketers — so they’re not working in silos. One of its biggest jobs is connecting design with development and the rest of the business, making sure everyone speaks the same language and moves toward the same goals.
Design QA (quality assurance) is a quality check of a design before it goes into production. Designers and developers check that what’s built in the code looks and works the same as it did in the mockups.
Design system is a set of definitions and rules that organize the elements that make up an ecosystem. It is not the components themselves, but what ties them together. Design system development defines the rules that specify how patterns work together and when it’s appropriate to use each one.
Design system component is a reusable piece of the interface, like a button, a form field, or a card. In DesignOps, it’s not just a visual element — it’s a managed asset. Components are stored in a library, associated with tokens (colors, fonts, indents), versioned, and tested. Update it once, and the changes roll out everywhere it’s used.
Design tokens are the most important part of a multi-brand design system. They are all the values needed to construct and maintain a design system — spacing, color, typography, object styles, animation — represented as data. These can include anything defined by design, for example, a color as a HEX value, an opacity as a number, or an animation as an ease function. Even component names can be a token: btn-[variant]-[type]-[size]-[modifiers]. They’re used in place of hard-coded values in order to ensure flexibility and unity across all product experiences. Design tokens can be split into two groups:
Design system component is a reusable piece of the interface, like a button, a form field, or a card. In DesignOps, it’s not just a visual element — it’s a managed asset. Components are stored in a library, associated with tokens (colors, fonts, indents), versioned, and tested. Update it once, and the changes roll out everywhere it’s used.
Design tooling is a set of tools that help designers and teams work faster and stay in sync. It’s not just Figma or Sketch, but also plugins, component libraries, handoff tools for devs, Jira integrations, and style check automations.
Design-to-dev handoff is the process of handing off designers’ work to developers so they can quickly and accurately turn the design into code. Designers prepare mockups, specs, and components, and then give developers everything they need so no one has to guess how a button or form should look or behave.
DevOps (development operations) is a methodology for interaction between developers, testers, and other IT specialists.
DMO (design management office) is a team or function that coordinates and manages all design processes within a company. The DMO ensures that the design system is used correctly, the workflows of designers and teams are aligned, design metrics and standards are followed, and new tools and practices are rolled out smoothly.
DoD (definition of done) is a clear checklist that shows the team when the design work is really finished. And it is important to remember: “done” is not just drawing a layout or preparing files. A real DoD takes into account the JTBD (Job to be done). That is, the design is considered completely ready when it is technically completed and really helps the user achieve their goal.
DoR (definition of ready) is a checklist that shows when a task or design feature is ready for the team to start working on. DoR helps ensure that designers and developers don’t start working on it until the goals, requirements, and context are clear.
DPM (design program manager) is a person who coordinates the work of design teams and processes to ensure that design works effectively and produces results. The DPM ensures that projects are on schedule and on time, the design system is used correctly, teams share knowledge and experience, and DesignOps processes run smoothly.
Drupal is a platform that allows designers and developers to implement, maintain, and scale a design system in a real product. Teams can work faster and more accurately because Drupal supports component reuse and design standards.
Figma is an online design collaboration tool. It’s designed for teams that want to keep everything in order: uniform, easy to scale, and fast. It brings everything together in one place: components, variants, themes, brands, and different platforms. No confusion with duplicates or extra versions. It’s also easier to work with: designers, developers, and managers all sit in the same space, and everything updates in real time. Change a component — and it’s immediately reflected in all layouts. No need for additional tools or endless approvals. Figma has version control, a bunch of plugins, and easy dev integrations.
Framework is a set of rules, tools, and structures that help teams understand how to build pages and components, what standards and patterns to use, and how the design system interacts with code.
Frontend is “the face” of the product, what the user sees and interacts with. It’s the pages, buttons, forms, menus, animations — everything on the screen. This is the code that turns the design into a working interface. Frontend connects the design and the user so that everything looks and works as intended.
Generative UI is the creation of interfaces or design elements partially or fully automatically using AI or algorithms. Designers set the rules, context, or examples, and the system generates options for buttons, forms, layouts, or even entire pages.
Generative UX is the creation of user experiences or interactions with a product that are partially automated using AI or algorithms. The system generates variations of user flows, prompts, messages, or interface scenarios based on the data, goals, and context set by the designer.
Governance is the rulebook for how the design system works. It defines who makes decisions, how new components get added, and what standards everyone has to follow. Without governance, things quickly get messy as the system grows. With it, the process stays clear, consistent, and manageable — from versioning and documentation to accessibility checks and brand alignment.
Handoff — See: Design-to-dev handoff
Headless is an approach where the design system lives separately from the interface. It stores components and rules, and the products themselves connect them via an API or library and assemble them for any platform, be it a website or an application.
Inclusive design is an approach to design that takes into account the different needs of all users, including people with disabilities, different cultures, ages, and experience levels.
JTBD (job to be done) is the goal the user wants to achieve with the product or service. Not just “click a button” or “open a page,” but achieve their goal. In design, this helps the team understand what tasks need to be solved for the user and build the interface so that it actually works and brings benefits.
Linting is the automatic checking of code or design for errors, non-compliance with standards and design system rules.
Merge/Pull request is the process of suggesting and approving changes to the design system. A pull request (PR) proposes a new component, an updated token, or a tweak in the docs. A merge happens when the change is approved and becomes part of the official system.
PRs and merges keep the design system clean, consistent, and transparent. Nothing sneaks in without a check, and everyone knows what’s changing and why. It’s not just about code — it’s about managing the whole design workflow in an organized way.
Metrics & KPIs are indicators that help the team understand how effectively the design and the processes around it are working. Metrics — any measurable data about the design: how many components are used, how many errors, how much time is spent on tasks. KPIs — key success indicators that show whether the goals have been achieved: if the team’s work speed has improved, if user satisfaction or the design consistency has increased.
Motion design is the use of animations and movement rules that make the interface feel natural: buttons that smoothly fade, menus that slide in, or subtle transitions that guide the user. Motion tokens set the speed, easing, and timing so everything feels consistent across the app.
Pattern is a reusable solution that designers utilize over and over again so they don’t have to come up with something new each time (buttons, forms, navigation, product cards, and pop-ups).
Pattern library is a part of a design system that is focused specifically on reusable interaction and UI solutions. This is not just a set of buttons and cards, but rather a cookbook of ready-made design recipes: how to design forms, how to build navigation, how to show errors or notifications. The idea is simple: instead of reinventing the wheel, you grab a proven pattern from the library and adapt it.
Pixel-perfect is the state where the final product matches the design exactly, down to the very last pixel. No “almost the same,” no buttons sliding a bit off, no weird spacing. In DesignOps, it’s also about the process: how to set things up so developers can match the designs exactly, and designers can actually trust the outcome. Design tokens, components, automated checks, and uniform rules help here.
Prototyping is the process of creating interactive mockups of a product so that a team can test ideas, check flows, and interactions before writing code. Prototypes often use the same components and tokens as the design system to maintain consistency. They show fast what’s working and what’s not, without wasting a ton of time or resources.
Repo (repository) is a place where all the elements of the design system, components, tokens, documentation, and sometimes prototypes are stored. This can be a codebase, cloud storage, or any managed repository where the team uploads and pulls artifacts.
Responsive design is an approach to creating interfaces that ensures that the product looks and works great on any device, from phones to large screens. The process is built so that designers and developers see the result in the same way, and changes are scaled automatically.
RFP (request for proposal) is a document provided by stakeholders to a design or design system team that defines goals, requirements, and constraints for a project/task, enabling designers to propose solutions, assess the reuse of existing components, or plan new component development.
Service design is a design not just of interfaces, but of the whole product ecosystem and the user’s interaction with it. Specialists look at the entire user journey — from the first contact to support. Their goal is to make the user experience seamless and keep internal teams aligned.
Scalability is the ability of a design system and processes to grow with the product and the company, to scale easily, and to continue to work stably as it grows. New pages, products, and teams can be added without pain or rework. Components and patterns work for both small tasks and huge projects. Processes remain clear and manageable, even if the number of designers and developers grows.
SSOT (single source of truth) is “the main hub”, where the most up-to-date and accurate version of the design is stored - colors, fonts, components, guides, and documentation. The goal is to make sure everyone works from the same version of reality, with no duplicates or confusion.
Storybook is a workspace for documenting and testing your design system’s components. You don’t need to spin up the whole app, you can try out every component on its own, which makes life a lot easier. It builds a clean, shareable component library right on top of your actual codebase. That way, you can show tricky states and edge cases to your team without recreating them in the app itself.
Style guides are the basics that keep your product looking and feeling consistent: grids that line everything up, fonts that match your brand, and colors that always feel right. It’s the foundation designers and developers rely on, so everything fits together nicely.
Tailwind CSS (cascading style sheets) is a framework that lets you style your app with utility classes. Each class applies a design — a key-value pair that defines a design spec. Because of that, integrating design tokens into Tailwind is a natural fit. You can override or extend its utility classes to build your own token system or adjust values on the brand level. It’s easy to update, easy to scale, and you can even keep the same names you use in Figma. Plus, it opens the door for future automation.
UI (user interface) is the visual part of a product that the user interacts with — buttons, forms, menus, icons, colors, and fonts. UI makes the product clear, easy to use, and visually appealing, and together with UX creates an overall user experience.
UI Kit is a set of ready-made interface elements: buttons, forms, icons, colors, fonts, and all the little things needed for layouts and prototypes. It makes it easier to do everything quickly and in one style, new employees in the team get involved faster, and it is easier for developers to put everything together in code, because the elements are already standardized.
Usability is the ease and intuitiveness of a product for users. In DesignOps, usability is baked into the process: components, tokens, and the design system are built to make the product predictable and user-friendly.
Usability testing is the process of checking a product with real users or the team to see what works and what is problematic. In DesignOps, testing helps catch problems early and fix components or patterns before they go live.
User flow is a step-by-step map of user actions in a product. It shows how a person moves from point A to point B, for example, from logging on to a website to making a purchase. The goal is to help the team spot potential pain points and make the process more convenient. This step-by-step map is often drawn as a diagram with screens, buttons, and possible user actions.
User journey is the steps a user takes from first discovering a product to reaching their goal, like signing up, purchasing, or using a service. Designers map out what a person does, sees, and feels at each stage. The goal is to understand where the pain points are and how to make the experience smoother and easier.
UX (user experience) is not just the interface, but how convenient, understandable, and enjoyable it is for the user to use the product. In DesignOps, UX is linked to processes so that the experience is equally high-quality at all levels and touchpoints.
Versioning is a system that helps track and manage different versions of designs and components. You can see which version of a button or layout is currently relevant. You can keep a history of changes to roll back if needed. Teams understand that they are working with the same version, without confusion.
Version control is a system that helps a team see who changed what, keep a history of changes, roll back if something goes wrong, and work as a team on the same files without conflicts and confusion.
WCAG (Web Content Accessibility Guidelines) is a comprehensive set of guidelines developed by the World Wide Web Consortium (W3C) and experts from around the world to make websites accessible for everyone, including people with disabilities. Today, WCAG includes versions 2.0 to 2.2, while WCAG 3.0 is currently in development as a successor to WCAG 2.x.
Wireframe is a draft of the interface that shows the structure — where the headings, buttons, forms, and images will be — and helps quickly agree on the logic and layout of elements before designers spend time on details and styles.
Workflow is a step-by-step process that shows who does what at each stage, how tasks flow from one person to another, and what tools and rules help move the work forward.
