Summary: This Design System Glossary breaks down key design system terms from A to Z in a clear, human-friendly way—so you can work smarter, not just faster. Whether you’re a designer, developer, or somewhere in between, it helps everyone speak the same language.
Before you dive into building a design system—or using one—it helps to speak the same language.
From tokens and templates to molecules and motion, there’s a whole vocabulary that keeps designers, developers, and product folks aligned.
But let’s be honest: sometimes these terms can feel a bit abstract or overly technical.
That’s where this glossary comes in. It’s not just a list of definitions—it’s a straightforward, conversational guide to the terms and ideas that make design systems work.
Whether you’re just getting started or you’re deep in the weeds, this resource is here to demystify the jargon and make the process feel, well… a little more human.
💡 What is a Design System?
A design system is more than just a collection of buttons and color swatches. It’s like the operating manual for building consistent, scalable digital experiences. It includes components, styles, documentation, code snippets, and even the design philosophy behind a product—all bundled together.
But here’s the real magic: it’s not just for designers. Developers, product managers, writers—everyone uses it to stay aligned. So instead of reinventing the wheel every time someone builds a new screen, they pull from the system and—boom—consistency, speed, and collaboration happen almost automatically.
Think of it as the shared language that helps a team build great products together… without stepping on each other’s toes.
1. Material Design by Google
- What it is:
Material Design is Google’s comprehensive design system for building beautiful, accessible, and intuitive digital products—especially on Android. It was introduced in 2014 but has undergone significant evolution, with Material You being the latest iteration. - Why it’s loved:
It’s comprehensive. It gives you everything: detailed guidelines for layout, typography, color, motion, components, accessibility, and code. It’s like a masterclass in UI design, complete with ready-to-use tools and even component libraries in Figma. - Use it when:
You’re building Android apps, or you want a reliable and tested foundation to start with. It’s also a great learning tool if you’re trying to understand how all the pieces of a UI system fit together. - 🔗 Explore Material Design
2. Carbon Design System by IBM
- What it is:
Carbon is IBM’s open-source design system, built for enterprise-level applications. It’s robust, accessible, and comes with both design kits and production-ready code (React, Vue, Web Components). - Why it’s loved:
Carbon is built with accessibility at its core and is very developer-friendly. It handles complex layouts and interactions effectively—perfect for large-scale SaaS applications or data-intensive platforms. - Use it when:
You’re working on complex enterprise apps or need a system that’s rock-solid, flexible, and built to scale. It’s ideal if you’re designing dashboards, admin panels, or any interface with a lot of data. - 🔗 Explore Carbon Design System
3. Polaris by Shopify
- What it is:
Polaris is Shopify’s design system, built specifically to help developers and designers build for Shopify’s ecosystem (merchants, admin dashboards, storefront tools). - Why it’s loved:
Polaris shines in clarity and friendliness. The documentation reads like a conversation—very human and approachable. It’s also opinionated, which can be helpful when you’re designing for commerce: it nudges you toward best practices, fast. - Use it when:
You’re working in the e-commerce space, particularly if you’re building Shopify apps or themes. Even if you’re not, it’s an excellent reference for how to structure helpful, user-first documentation. - 🔗 Explore Polaris
Design systems aren’t just about speeding up work. They’re about scaling design thinking. When done right, they empower teams to move faster and build better, more cohesive products. Whether you’re just starting or knee-deep in enterprise UI, these systems are worth studying—and borrowing from.
🅰️
Adaptive Design
Adaptive design is when a layout is crafted to respond to specific device types—like phone, tablet, or desktop—using fixed breakpoints.
Instead of a single fluid layout that stretches or squeezes, adaptive design employs a few carefully chosen layouts that “snap” into place based on the screen size.
It’s like giving each device its own tailored outfit, rather than a one-size-fits-all approach.
It works well when you know exactly which devices your users are on—but it can feel a bit rigid when new ones emerge.
Adoption Rate
This represents the percentage of teams, products, or individual designers and developers who are utilizing the design system—and using it as intended.
It’s not just a feel-good metric; it shows how well your system is being received within the organization.
High adoption typically indicates that your system is helpful, trusted, and not a burden to use.
Low adoption? That often means friction—either in how it’s built or how it’s communicated.
Tracking this helps you know when to nudge, improve, or even let go of things that aren’t working.
Accessibility
It’s about ensuring that no one is left out, whether they’re navigating with a screen reader, using a keyboard instead of a mouse, or facing visual, hearing, or motor challenges.
Annotation
Annotations are the little notes you drop on mockups—not just for fun, but to explain what something does, why it’s there, or how it should behave.
They’re the whispered guidance from the designer to everyone else involved in the project. “This dropdown expands on hover.” “This error message appears after three failed attempts.” That kind of thing.
Annotations turn flat designs into living documents with context. Without them, things get misinterpreted, delayed, or worse—shipped wrong.
Atomic Design
Coined by Brad Frost, Atomic Design breaks interfaces down into their smallest possible components—such as buttons, inputs, or labels (also known as atoms).
These atoms combine into slightly larger patterns (molecules), which then become more complex components (organisms), templates, and finally full pages. It’s a way of thinking, not just a method of organization.
The idea is to build interfaces like you’d create with LEGO blocks—one small, reusable chunk at a time.
It brings structure to the chaos of designing at scale, particularly in systems that require ongoing evolution.
🅱️
Brand Guidelines
Brand guidelines are the rulebook that keeps your visual identity from drifting into chaos. It covers the basics—logos, colors, typography—but also tone of voice, image style, iconography, and even how not to use things.
Think of it as the foundation that keeps your product instantly recognizable, even when different people are working on it.
Without brand guidelines, your UI can gradually become a patchwork of styles that feels confusing, or worse—untrustworthy.
Breakpoint
A breakpoint is a specific screen width where your layout changes. Not randomly, but intentionally.
For example, at 768px, your navigation bar may collapse. At 1024px, the side panel may become visible again.
Breakpoints help the interface adapt to the screen, ensuring it remains usable regardless of the viewing context. You define these points so that things shift with purpose—not panic.
Button
A button is one of the most familiar, everyday parts of any interface—it’s what users click, tap, or press to make something happen.
Whether it’s submitting a form, saving changes, or opening a menu, buttons are action triggers.
However, behind their simplicity lies a great deal of careful thought.
They need to appear clickable, respond to interactions (hover, focus, and disabled states), and guide users toward the next step—without overwhelming the screen.
Good buttons are consistent in size, shape, and behavior across your product.
Great buttons also consider things like accessibility (can it be triggered with a keyboard?), hierarchy (is this the primary action?), and feedback (does it show loading or success?).
So while a button might seem like “just a button,” it plays a key role in shaping how intuitive and usable your entire interface feels.
🅲
Component
A component is a reusable piece of UI, such as a button, form field, modal, or card. It’s not just how it looks, but how it behaves, interacts, and fits into a larger layout.
Components save time, reduce errors, and make design feel less like guesswork and more like assembling a well-planned kit.
In a way, components are the heroes of design systems—they hold everything together while making it look easy.
Component Library
A component library is the place where all your coded components live—ready to be reused, shared, and scaled.
These are the actual, working building blocks in frameworks like React or Vue.
Developers plug them into their projects to build interfaces that match the design system, pixel for pixel.
And when the design or behavior of one component changes in the library? Everything using it gets updated too. That’s the real magic.
Content Guidelines
These are the rules for how your brand speaks. What tone do you use? What words do you avoid? How to write a button label. Or a tooltip. Or an error message. Clear, consistent language makes your product more straightforward to use—and more trustworthy.
Content guidelines also ensure that multiple writers, designers, or developers can write UI text that sounds like it came from the same source.
Contribution Model
A contribution model is the system that governs how your design system evolves. Who can suggest changes? How are those changes reviewed? Who approves them? Without a model, the system either grows chaotically or fails to grow.
A good contribution model makes people feel involved—without compromising quality or consistency. It’s how the system stays alive and valuable, instead of becoming a frozen artifact.
Cross-functional Team
A cross-functional team brings together different roles—designers, developers, product managers, content strategists—to build and evolve the design system together.
It’s not a handoff from one group to another. It’s collaboration from the start.
This kind of team ensures the system works for everyone and doesn’t become overly design-driven or too dev-heavy. Balance is the key.
🅳
Design Debt
Design debt occurs when minor inconsistencies or shortcuts accumulate over time, resulting in a cumulative effect.
A button here that’s a bit too wide. A slightly different blue there. A layout pattern no one followed.
Each decision seems harmless in the moment—but together? They slow things down, confuse users, and make future work harder.
Cleaning up design debt is like tidying your workspace: boring maybe, but freeing once it’s done.
DesignOps
DesignOps (short for Design Operations) is all about enhancing the effectiveness of design work.
It’s not about the pixels—it’s about the people, processes, and tools behind them.
DesignOps helps teams scale smoothly, stay organized, and stay sane.
Whether it’s managing Figma libraries, onboarding new designers, or aligning design and dev workflows, DesignOps keeps things moving without chaos.
Design Language
Your design language is the visual vocabulary that defines your product’s personality.
It’s the colors, typography, spacing, motion, icon style—everything that makes your interface feel like “you.”
A strong design language creates familiarity. It’s what makes users feel like they’re still in the same product, even as they explore different parts of it.
🅴
Elevation
Elevation is how we add depth to flat screens. It’s the subtle shadow beneath a card, the slight lift on a button when you hover, the way one layer feels closer than another—without actually moving in 3D space.
It helps users understand hierarchy at a glance: what’s clickable, what’s floating above something else, what deserves focus.
But it’s a delicate balance. Too much shadow, and everything looks heavy or noisy. Too little, and things blur into each other.
When done well, elevation quietly guides attention without shouting. You probably don’t even notice it—unless it’s missing.
🅵
Framework
A framework, in design or development, is a structured approach. It’s the set of guidelines, tools, and reusable bits that help teams build products more efficiently and more consistently.
It’s not a rigid rulebook, but more like scaffolding—it supports your work while giving you room to shape and create.
In dev terms, it might be React, Angular, or Vue. In design, it could be your component architecture or page templates.
Either way, frameworks keep teams aligned, reduce guesswork, and allow ideas to scale without getting messy. Without one, progress tends to slow or scatter.
🅶
Grid System
A grid system is the invisible structure behind the layout. It’s rows and columns that help content fall into place—aligned, readable, and balanced.
You might not see the grid lines, but you feel their presence when everything falls into place just right.
They help designers make spacing decisions faster and create visual harmony across screens.
Grids also guide hierarchy: what’s more important, where does the eye go first, and how much white space is too much?
Without a grid, layouts start to feel chaotic, even if you can’t explain why.
🅷
Hand-off
Hand-off is the point where design transitions into development.
It’s not just exporting assets—it’s about passing along the context, intention, and technical details needed to bring the design to life.
Sometimes it’s smooth—other times… not so much.
Perhaps a developer receives a Figma file with no guidance. Or the design doesn’t account for edge cases.
A good hand-off feels like a conversation, not a one-way drop. It involves notes, specs, responsive behaviors, and ideally, a bit of patience on both sides.
When the hand-off is thoughtful, things build faster—and closer to what was intended. When it’s rushed, alignment breaks, and frustration builds.
Hue, Saturation, and Luminosity (HSL)
Hue, saturation, and luminosity are what shape a color into what we see and feel.
Hue is the base color—red, blue, green—the position on the color wheel.
Saturation refers to the intensity or dullness of a color. A fully saturated red screams. A desaturated red? It’s more of a dusty rose.
Luminosity (or lightness) is about brightness—how close it is to black or white.
Together, these properties give color its personality. They affect everything from readability to emotional tone.
Shift just one of them, and the whole mood changes.
Designers often tweak HSL values to fine-tune color schemes that feel accessible, intentional, and balanced—not just “pretty.”
🅸
Iconography
Iconography is the set of small visuals—icons—that help communicate meaning quickly.
A trash can means delete. A magnifying glass means search. We barely think about them when they’re done right, but inconsistent or confusing icons can derail an experience.
The key is maintaining consistency and clarity in style. They should feel like they all belong in the same world—and they should never make a user guess.
Additionally, accessibility is crucial here: they should be legible at small sizes and always include a text alternative, just in case.
Inclusion
Inclusion in design isn’t just about accessibility checklists—it’s a mindset. It’s about asking: “Who might be excluded by this decision?”
That could be someone using a screen reader, someone with color blindness, or someone who processes information differently.
Inclusive design welcomes different perspectives, abilities, and experiences.
And the result? Products that work better for everyone. It’s not an afterthought—it should be baked in from the beginning.
🅹
JSON Tokens
JSON tokens are little pieces of design data—like colors, spacing, fonts—stored in a format that machines (and humans) can read.
Instead of hardcoding values like #007AFF, you define it once in a JSON file as "primary-blue": "#007AFF".
Then developers and designers pull from that same source, ensuring consistency across platforms.
They’re like the connective tissue between design and code.
Not glamorous, but essential for scalable design systems.
🅺
Kerning
Kerning is the space between individual letters in a word. Not the whole word spacing—that’s tracking—but letter by letter. It’s subtle.
Most people won’t even notice it… until it’s off. And then suddenly, it’s all you can see.
When kerning is done well, the letters appear to belong together. Like they’re in a quiet, balanced conversation.
But when it’s too tight or too loose—especially in logos or headlines—it creates visual tension.
Letters might feel like they’re crashing into each other or drifting apart, and that can make even the best design feel amateur or uncomfortable.
What’s tricky is that kerning isn’t equal spacing—it’s optical spacing because letters have different shapes.
A “T” next to an “o” needs different spacing than an “A” next to a “V.” That’s why good designers often adjust kerning manually, especially in logos or titles, where every pixel counts.
So, while kerning may seem like a minor detail, it plays a significant role in how polished and intentional your typography appears.
And once your eye is trained to notice it… Well, you’ll start spotting awkward kerning everywhere. It’s both a gift and a curse.
🅻
Layout
Layout refers to the placement of elements on a screen. Simple as that—and also not.
A good layout guides the eye, supports hierarchy, and gives breathing room where it’s needed.
It involves grids, spacing, alignment, and sometimes even invisible constraints.
You don’t always notice a great layout—but you feel it. A poor one, though? That sticks out.
Feels cramped or messy like walking into a room where all the furniture is just… off.
Linting
Linting is a bit like spell-check, but for your design system code—or even your Figma files if you’ve got the right plugins.
It scans for inconsistencies, like non-token values or incorrect class names, and flags them.
It’s not always exciting, but it’s beneficial for maintaining cleanliness, scalability, and alignment with your design standards.
Think of it as a quiet, behind-the-scenes teammate with a sharp eye for detail.
🅼
Modularity
Modularity refers to the practice of building things in parts that can stand alone or be integrated into a larger system.
It’s like LEGO—each block works on its own, but also contributes to a larger model. In design systems, modularity enables components to be reused, rearranged, and reconfigured without compromising their integrity.
It helps teams move quickly and stay consistent, even as products become more complex.
You don’t need to reinvent a page layout every time—rearrange the modules you’ve already got.
Motion Design
Motion design adds life and meaning to your UI. It’s the animation that tells users something is happening, or about to happen.
A fade-in here, a bounce there—it’s not just visual flair. Motion helps guide attention, offer feedback, and make interactions feel more natural.
But it’s tricky. Too much motion feels distracting. Too little, and the interface feels flat. Great motion design is almost invisible—it just feels right.
Molecule
In Atomic Design, a molecule is a simple group of atoms (think: label + input + help text) working together to serve a clear function.
They’re not full-blown components yet, but they’re meaningful chunks of UI.
The idea is to build complexity gradually, so you can reuse parts of parts without breaking everything apart.
Molecules bring a touch of structure to what would otherwise be just floating pieces.
Maintenance Plan
A maintenance plan is how you keep your design system from getting dusty. Because honestly, every system starts to drift over time—new needs, new people, forgotten documentation.
A good plan includes regular audits, feedback loops, and a transparent process for updating or retiring components.
Without one, you’re just hoping for the best. With one, you’re actively investing in the system’s long-term health.
Material Design
Material Design is Google’s design system—and it’s more than just a style guide.
It’s a complete set of rules, components, and tools built to help teams create clean, consistent, and user-friendly experiences—especially for Android apps.
It covers everything from how buttons should behave to how shadows, color, motion, and typography work together to create meaning.
Think of it as Google’s way of bringing logic and beauty into one cohesive visual language.
And the best part? It’s all documented, supported with code, and constantly evolving, so designers and developers can stay in sync as they build.
🅽
Naming Conventions
Naming conventions are how you avoid chaos in your component library. Is it PrimaryButton_Large or btn-primary-lg? Pick a pattern and stick to it.
Effective naming makes components easy to locate, comprehend, and reuse.
Insufficient naming… well, you end up with three different buttons that do the same thing but look slightly different and are impossible to search. Naming might not be exciting, but it’s critical to sanity.
🅾️
Organism
In Atomic Design terms, an organism is a group of molecules that work together as a larger, functional unit.
Think of a header that includes your logo, navigation links, and search bar—all stitched together into a reusable pattern.
Organisms are like self-contained sections of a page. Not quite full templates yet, but closer to what users would see.
They bring real structure to your system, and they’re where you start seeing the design system in action.
Overriding
Overriding occurs when you take a component from your design system—such as a button or a card—and modify it for a specific use case.
Perhaps you can change the color, adjust the padding, or replace the icon.
It’s kind of like borrowing someone’s outfit and then tailoring it slightly to fit your mood for the day.
Now, in moderation, overriding is incredibly useful. It provides designers and developers with flexibility without requiring them to reinvent the wheel.
You can solve unique problems while still leaning on the structure the design system provides. And that’s great—until it isn’t.
Because the moment overriding becomes the norm instead of the exception, things start to fall apart.
That perfectly aligned, consistent experience your design system promised? Yeah, it starts to fray at the edges.
One team adds a shadow. Another shifts the font size. Suddenly, you’ve got five versions of what’s supposed to be the same component. And users? They notice—even if they can’t articulate why it feels inconsistent.
So, overriding should be used like seasoning. Just enough to add flavor where it’s needed, but not so much that it overpowers the whole dish.
Always ask: is this override solving a real user problem—or just making something look slightly cooler? Balance is everything.
🅿️
Pattern Library
A pattern library is like a curated toolbox of design solutions you can rely on—especially for recurring challenges.
Think of things like how you handle form validation, error messages, empty states, or modal confirmations.
These aren’t just one-off designs; they’re tested, refined patterns that help users succeed.
Having a pattern library means teams don’t need to solve the same problem again and again—they plug in what already works.
It also helps create a sense of predictability, which is comforting in a product.
Pixel Perfect
Pixel-perfect design is exactly what it sounds like: layouts that are aligned so precisely that every element sits where it should, right down to the last pixel.
It’s about visual sharpness and polish. It matters a great deal in high-fidelity UI work—especially when you’re building for Retina displays or launching a polished product to users who notice the details.
That said, it’s not about obsessing over perfection for perfection’s sake. It’s about delivering a clean, intentional, high-quality experience.
Principles
Design principles are the big-picture ideas that quietly guide your day-to-day decisions.
They’re not rules—they’re values. Things like “clarity over cleverness” or “make it feel familiar before it feels smart.”
When a team agrees on its principles, it becomes easier to say no to ideas that appear attractive but don’t align with the brand’s values.
These principles give your system its character and keep it grounded when things start to scale fast or get a little messy.
Product Surface
This is the visible, touchable part of your product that users interact with.
Buttons, input fields, menus—this is where all your design system decisions finally show up and do something.
It’s where consistency (or inconsistency) becomes immediately apparent.
So, when someone says, “We need to improve the product surface,” they’re usually referring to the aspects that users can see, click, or feel directly.
Pattern
A pattern is a solution to a design problem that occurs repeatedly. It’s not a visual component—it’s a repeatable approach.
For example, how do you onboard new users? Or help them recover from an error? Those are design problems, and patterns help solve them.
Patterns aren’t static—they evolve as your product grows. But having them documented means you can scale design decisions with less guesswork.
Properties
Properties are the individual traits that define how an element looks or behaves.
Things like color, size, spacing, border radius, and font weight. In coded systems, these are often controlled by tokens or variables.
On the surface, they seem small—but properties are what give components flexibility, reusability, and personality.
They enable the global update of styles without requiring manual updates for every screen. That’s powerful.
Pilot
A pilot is your design system’s trial run—its debut performance, if you will. It’s a product or feature intentionally built to test how well the system performs in the real world.
It helps expose gaps, friction points, or misunderstandings. It’s not just about showing that the system works; it’s about proving that it works under pressure.
The best pilots are carefully selected and thoroughly documented.
Prototyping
Prototyping is about bringing ideas to life—before they’re fully built.
It’s the process of creating an early version of a product (or just a part of it) to see how it works, how it feels, and how real people might interact with it.
Sometimes it’s just a few connected screens to test a flow. At other times, it’s a more detailed and interactive model that simulates the final experience.
Either way, prototyping helps teams identify problems early, gather feedback, and make more informed decisions—without writing a single line of production code.
It’s where ideas go from “what if…” to “let’s see what happens.”
🆀
QA (Quality Assurance)
Quality Assurance—often referred to as QA—is the part of the process where things become more tangible and measurable.
It’s where we pause, take a deep breath, and double-check that everything works the way it’s supposed to. And looks like it’s supposed to. And feels like it’s supposed to.
It’s not the most glamorous phase, but it’s essential. This is when someone—usually with a very keen eye—goes through the product with a fine-tooth comb.
Is the spacing precisely as defined in the design spec? Does that button do something when you click it?
Does the hover state show up… or blink into the void and vanish? QA is where all those tiny, easily missed details get their moment in the spotlight.
Sometimes, QA catches issues such as inconsistent font sizes, buttons that are misaligned by a pixel, or a dropdown that behaves correctly on desktop but breaks completely on mobile.
At other times, it catches the instances that feel off—like interactions that technically work but don’t quite align with what the user expects.
The goal isn’t perfection (though we strive for it)—it’s refinement. It’s ensuring that your beautiful design doesn’t get lost in translation during development.
So while it might feel tedious, a solid QA pass can be the difference between a product that frustrates and one that feels quietly delightful.
🆁
Repository
A repository (or repo, if you’re feeling casual) is the storage space where all your design system’s code, documentation, or assets live.
Typically hosted on platforms like GitHub or GitLab, it serves as the technical home of your system.
A well-maintained repo makes collaboration easy, versioning clear, and rollbacks painless.
A messy one? Well, you’ll know it when you’re in it.
Responsive
Responsive design is about making your interface adapt to different screen sizes and devices.
It’s not just about things looking okay—it’s about things working well on a phone, tablet, desktop, or even a giant monitor.
That means fluid grids, smart breakpoints, and flexible components.
It’s what makes your product feel professional across devices—and, frankly, expected in today’s world.
Reference Site
This is the live, often public-facing version of your design system.
It’s where your team—and sometimes your community—goes to explore components, patterns, tokens, and usage guidelines.
Think of it as the storefront of your design system: part documentation hub, part brand showcase, and part playground.
When done well, it becomes an internal source of truth and an external source of inspiration.
🆂
Spacing Scale
A spacing scale is a predefined set of numbers you use to manage space in your UI—usually based on a simple, consistent unit like 4 or 8 pixels.
Instead of eyeballing margins and padding, you use values from the scale: 4, 8, 16, 32… and so on.
This makes layout decisions faster and more predictable, and keeps your product from looking like ten different people designed it in a rush.
Style Guide
A style guide is your brand’s playbook for how things should look and feel. It encompasses typography, colors, logos, spacing, interactions, even tone of voice, and imagery.
It’s the thing you share with new teammates, partners, or vendors when you want to say, “Here’s how we do things.”
It creates alignment across different contributors and keeps your product experience feeling intentional and polished.
System Health
System health is like a pulse check for your design system. How widely is it adopted? Is the documentation up to date? Are components consistent across products? Are teams happy using it—or quietly avoiding it?
Healthy systems are maintained, trusted, and actively evolving. Unhealthy ones… well, they gather dust and cause friction.
Measuring health helps you determine when to invest, make repairs, or reassess.
Single Source of Truth (SSOT)
Your SSOT is the master reference—the one place where the most accurate and up-to-date version of your design system resides.
It combines design, code, and documentation in one shared hub. Without a clear SSOT, teams often end up working with outdated files or making guesses.
With one, everyone pulls from the same page—literally and metaphorically.
System Governance Roles
These are the roles that keep your design system from descending into chaos.
You have Maintainers (who manage updates), Contributors (who propose new ideas), Reviewers (who check quality), and Consumers (who use the system in their work).
Governance isn’t about red tape—it’s about clarity. When everyone knows their role, the system evolves without drama.
Storybook
Storybook is an open-source tool that helps you build and test UI components in isolation.
It’s where designers and developers can explore, tweak, and review components without the noise of the whole product environment.
It’s like a workshop, not the showroom. Storybook is especially useful for documenting states, checking accessibility, and getting early feedback—before anything goes live.
🆃
Theming
Theming is what lets your product feel uniquely yours—even if it’s built on the same design system as someone else’s.
It’s about customizing specific visual aspects—colors, fonts, and possibly corner radius—without altering the structure of the components themselves.
It’s how a white-labeled SaaS dashboard looks different for Brand A and Brand B, even though they’re both using the same underlying buttons, cards, and nav bars.
Good theming keeps the bones intact while allowing the skin to change—flexibly, but safely.
Tokens
Tokens are like the atoms of a design system. Tiny named values—like color-primary, spacing-lg, or font-heading—that live behind the scenes but power everything.
Instead of hardcoding styles, you reference tokens. It’s what allows you to change your brand blue in one place and have it update everywhere.
They bridge the gap between design and development, making the system scalable, themeable, and consistent across platforms.
Tooling
Tooling is all the behind-the-scenes machinery that keeps your design system running smoothly.
Think automation scripts, Figma plugins, Storybook setups, or CI pipelines that lint your components. Most of it lives under the hood—but it’s essential.
Without proper tooling, things break quietly or become painful to maintain. With it, your system evolves faster, cleaner, and with far less human error.
Typography Scale
Typography scale is the structure behind your font sizes. It’s what gives a headline its presence, a subhead its contrast, and body text its comfort. Usually, it’s based on a mathematical ratio (like 1.25x) or a set of predefined steps (e.g., xs, sm, md, lg, xl).
The goal isn’t just to have a bunch of type sizes—it’s to create rhythm, hierarchy, and a sense of harmony in how content is read. It’s subtle, but when it’s off, everything feels… wrong.
🆄
UI Kit
A UI kit is like a ready-to-go toolkit for designers. It includes prebuilt components—buttons, modals, inputs, cards—already styled and laid out in Figma (or your tool of choice).
You drag and drop, adjust a few labels, and suddenly you’ve got a working mockup.
It’s perfect for prototyping, onboarding new teammates, or staying aligned with your design system without having to build from scratch each time.
Usage Analytics
Usage analytics tell you what parts of your design system are being used—and, maybe more importantly, what’s being ignored.
It tracks things like how often a component is applied, whether teams are overriding tokens, or which patterns are popping up in real products.
This insight helps you prioritize maintenance, flag inconsistencies, and decide what to improve—or retire. Without it, you’re flying blind.
Usability
Usability, in the context of a design system, isn’t just about the end product—it’s also about how easy the system itself is to use.
Can designers find what they need? Are components documented clearly? Is it flexible without being overwhelming? If your system is too complex or too vague, people will stop using it—no matter how beautifully designed it is.
Usability is what keeps adoption high and frustration low.
🆅
Variants
Variants are like the neat, organized closet of your design system. Imagine you’ve got one basic shirt—same cut, exact fit—but it comes in different colors, patterns, and sleeve lengths. That’s what variants do for components.
Let’s say you have a button. Now, this button may appear slightly different depending on its function or location.
There’s the primary button—the bold one that gets all the attention. Then there’s the secondary—a bit quieter, more supportive.
Sometimes it’s disabled (grayed out and unclickable). Other times it’s in a hover state, or it’s been clicked, or maybe it has a little icon next to the text.
Without variants, you’d have to create and manage each of those versions separately. That means more components, more mess, and a higher chance of inconsistency.
However, with variants—especially in tools like Figma—you group all those styles into a single parent component.
Same name, one tidy place, just different states or options. Like flipping through styles on a menu.
It’s cleaner. More scalable. And when you need to update that button later? You fix it once, and all the versions update automatically.
No more hunting down rogue duplicates. So, yeah—variants are a quiet little powerhouse.
They help keep your design system flexible without letting it spiral into chaos.
Versioning
Versioning is the process of tracking changes to your design system, mainly when other teams rely on it.
It’s typically done with semantic versioning (like 2.1.0), and each release comes with a changelog that says what’s new, what’s improved, and what’s breaking.
Without versioning, updates feel chaotic. With it, teams can plan, upgrade, or even roll back changes with clarity and confidence.
Visual Hierarchy
Visual hierarchy is the art of guiding someone’s eye through a screen—whether it’s a landing page or a dense product dashboard.
It’s not just about making text bigger or bolder. It’s about layering contrast, spacing, color, and typography to say: “Start here, then go there.” A strong hierarchy makes scanning easy.
A weak one forces users to hunt for what they need—or worse, give up entirely.
🆆
White Space
The oxygen of your design. Not “wasted space,” but breathing room. It allows the eyes to rest and makes content more digestible. Ignore it, and everything looks… stuffed.
🆇
Cross-Platform
Your design system should support web, mobile, tablet—and ideally, not feel like it’s forcing one solution onto everything. Some things do need platform-specific treatment.
🆈
YAML
A format (like JSON) often used in tokens, themes, or config files. Developers like it because it’s clean and readable. Designers… well, they rarely see it.
🆉
Zero States
What users see when there’s nothing to show yet—no messages, no tasks, no data. Often ignored, but it’s a key emotional moment in UX. Can feel inviting or… just blank.
Zero-height Component
A zero-height component is something like a drawer, an accordion, or an inline error message—it takes up no visible space when inactive but expands when triggered.
It’s dynamic, responsive, and beneficial. But it can also cause layout shifts or accessibility challenges if not handled properly.
Designing these requires a little extra care—because they’re invisible… until they’re not.
Free Design System Resources Hub
💡 If you’re building—or even just exploring—design systems, don’t start from scratch.
I’ve curated a growing list of free design systems, Figma UI kits, and design system directories over at UIUXshowcase.com.
Whether you’re a solo designer trying to learn the ropes or a SaaS team building a system from the ground up, this directory brings you ready-to-use, professionally crafted resources.
It’s like having a design system toolbox at your fingertips—free, practical, and constantly updated.
Dive in, grab what fits your workflow, and don’t forget to share it with someone else who’s deep in the trenches of design system work.