You’re about to redesign your website with your team or an agency. Within the first week, everyone is talking about the design system. The designer means a Figma library. The developer means code. Your agency means a set of rules it will hand over at launch.
Everyone uses the same words, and nobody means quite the same thing. Before you approve a scope or review a single page, agree what those words mean for your project. These are the short answers to bring to that conversation:
- A design system is the set of shared decisions, reusable parts, and usage guidance a team maintains, plus the people who maintain it. It is more than one file.
- Foundations and styles are the basic choices, such as color, type, shape, spacing, and layout. They decide how the site looks and feels before any button exists.
- Tokens are named design decisions. A name such as “primary color” stands in for a raw value such as a hex code, so one change can reach every place that uses it.
- Primitives is the most confusing word on the list. Some teams mean basic token values. Others mean basic layout components. Ask which one your team means.
- Components are the interactive building blocks, such as buttons, menus, cards, and text fields.
- Patterns are reusable answers to a common task, such as entering an address or signing in. They usually combine several components.
- Documentation tells people when and how to use each of these. Without it, a library of parts gets used in different ways on every page.
The rest of this guide explains each answer. It uses Google’s Material Design 3 as a running example and points out where Apple’s Human Interface Guidelines organize things differently.
Why Teams Mean Different Things
A design system grows out of a team’s own work, so each one organizes and names its parts in its own way. Two well-known systems show this clearly.
Material says its documentation is organized into three main parts: foundations, styles, and components. Apple’s guidelines use different groups: Getting started, Foundations, Patterns, Components, Inputs, and Technologies.
Neither structure is wrong. They were built for different jobs. That is why your project needs its own short glossary instead of assuming everyone learned the same one.
Foundations and Styles
Material’s Foundations section covers the basis of the interface, from accessibility and content design to layout, interaction states, and design tokens. Its Styles section covers “the visual aspects of a UI that give it a distinct look and feel”: color, elevation, icons, motion, shape, and typography.
Apple places color and typography in its Foundations section instead. So if your agency says “foundations,” ask whether it means visual styles only, or also layout, accessibility, and writing rules.
For a website redesign, this is where your brand becomes concrete. Which colors carry which meaning? Which type sizes exist, and what is each one for? How rounded are the corners? These choices affect every page, so they are worth agreeing early.
Tokens
Material describes design tokens as “small, reusable design decisions.” A token gives a value a name. Instead of repeating one exact blue on every button, the team refers to a name, and the name points to the value.
Material uses three classes of tokens. Reference tokens hold the available options, such as each shade in a palette. System tokens give those options a purpose, such as the main brand color in light mode. Component tokens apply a decision to a part of one component, such as a button’s fill.
Many teams describe the same idea as primitive, semantic, and component tokens. That is a helpful translation, but it is not Material’s own wording, and not every system uses three levels. The detail, including what changes when someone edits a token at each level, is in our guide to design tokens and primitive versus semantic tokens.
Apple’s guidelines describe system colors that are defined by their purpose rather than their exact appearance, and text styles that scale with each person’s settings. The pages we reviewed do not publish a token structure like Material’s. If your team borrows ideas from Apple, borrow the principle of naming colors and type by their job.
Primitives
“Primitive” causes more confusion than any other word on the list. In token discussions, a primitive usually means a raw value, such as a specific shade of blue with no stated purpose.
Other systems use the word for something else. Atlassian’s design system calls primitives “components that create layouts, add styling, make up other components,” such as boxes and stacks. Those are building blocks you place on a page, not color values.
When someone on your project says “primitives,” ask for an example. The answer tells you whether the conversation is about values or about layout parts.
Components
Material defines components as “interactive building blocks for creating a user interface.” It groups them by purpose, such as action, navigation, selection, and text input. Buttons, dialogs, cards, and text fields are examples.
Apple’s Components section is about system-defined parts that people already know from their devices. An agency building your website will usually mean something broader: any reusable block it designs and builds for you, such as a product card or a newsletter sign-up.
For your project, a useful component entry has a name, a purpose, its variations, and its states. States show how a part changes as people use it: when a pointer hovers over it, when it has keyboard focus, when it is selected, and when something goes wrong. Keyboard focus is the highlight that shows which control a keyboard user is on. If the library only shows the default look, ask where the states are.
Patterns
Patterns are reusable answers to a common task. Apple describes its Patterns section as guidance for “common user actions, tasks, and experiences.” The IBM Carbon design system calls patterns reusable combinations of components, templates, flows, and sequences.
Material does not have a separate Patterns section. Guidance that works like patterns appears inside its other sections, such as its layout guidance for arranging screens.
The line between a component and a pattern also moves between systems. Carbon lists dialogs as a pattern, while Material lists dialogs as a component. For your redesign, the useful question is whether the system explains how to handle the tasks your visitors do, such as booking, checkout, or contacting you.
How to Agree on One Version of the Truth
Turn the definitions into a short project glossary before design work speeds up. Ask your team or agency to fill it in with examples from your own site.
- List the terms your team uses: design system, foundations, styles, tokens, primitives, components, patterns, and documentation.
- Write one sentence for each term that says what it means on this project.
- Add one example from your site for each term, such as the main button or the product card.
- Note which reference system, if any, the team follows, such as Material.
- Name who decides when a term or rule changes.
Keep the glossary with the project brief and the design files. When a disagreement comes up in a review, you can point to the agreed meaning instead of debating the word again.
What to Ask Your Team or Agency
Use these questions when you review a proposal or a first delivery:
- What will we actually receive: design files, code, written guidance, or all three?
- Which reference system are you starting from, and where will ours differ?
- How are colors and type sizes named, by appearance or by purpose?
- Do components include their states, not only their default look?
- Which common tasks on our site have pattern guidance?
- Who maintains the system after launch?
A short, shared vocabulary will not design the site for you. It does make every later review faster, because everyone is finally describing the same thing.
