Every list of design system examples shows the same screenshots. That is the least useful part. A design system is judged after the screenshots: when a new hire ships a screen unsupervised, when a second product needs the same button, when the brand changes its primary colour. The seven systems below are publicly documented, so every claim here is checkable. Read each one for the problem it solves and the thing worth copying, not for the pretty grid.
Key takeaways
- A component library is an output. A design system is an agreement with rules attached.
- The systems that survive have an owner, a version, and a refusal policy.
- Design tokens are the part a machine can enforce. Documentation is the part a human can follow.
- Copy the governance, not the component count.
What separates a design system from a component library
A component library answers one question: what does a button look like? A design system answers the harder ones. Who decides. What changes when the brand changes. What a team is not allowed to ship.
Four tests separate the two.
An owner. A named person or team, not a Slack channel that everyone assumes is watching.
A version. A changelog and a migration path for anything breaking. A library with no version is a folder.
A refusal policy. Guidance on when not to use a design system component is worth more than a tenth variant of it.
One source of truth. If decisions live in Figma, in CSS, and in a PDF, you have three systems and no authority.
Miss those four and you have a library that rots. It rots on a schedule: one team forks a component to ship a deadline, the fork becomes the standard, and the original keeps its documentation while losing its users. By the next redesign nobody can tell which button is canonical.
The examples below are worth studying for exactly that reason. Each one is documented in public, so the governance is visible, not just the visuals.
Design system examples worth studying
Seven systems. What each one is, what it solves, what to copy.
IBM Carbon: the grid as a decision
What it is. IBM's open-source design system, published in design kits and in code across React, web components, Angular and Vue.
What it solves. Hundreds of product teams shipping enterprise software that has to feel like one company. At that density, spacing is the difference between a spreadsheet and an interface.
What to copy. Carbon's 2x Grid is built on an 8px mini unit. Every size, gap and layout dimension is a multiple of it. That single constraint removes most layout arguments, because spacing becomes arithmetic instead of taste.
Salesforce Lightning: a contract with people you cannot manage
What it is. The Lightning Design System, built for Salesforce's own products and for the partners building on the platform.
What it solves. An ecosystem problem. Third-party developers will never sit in your design review, so the system itself has to enforce the look.
What to copy. The system as a public API. Accessibility lives inside the component acceptance criteria, not in a separate appendix nobody opens. If your components can be used by strangers and still come out compliant, your documentation is doing real work.
Shopify Polaris: one screen, many authors
What it is. Polaris is the design system for Shopify surfaces, the admin above all. Documentation has moved to shopify.dev with Polaris rebuilt on web components; the older Polaris React library and the polaris.shopify.com archive are no longer maintained.
What it solves. A single constrained surface that thousands of apps inject content into. The admin cannot drift, because every app is a co-author with no design team.
What to copy. Content guidance per component. Polaris documents what to write inside the component as carefully as how it looks. Most systems stop at the box and leave the words to whoever is on shift.
Uber Base: theming as a first-class primitive
What it is. Base Web, Uber's open-source React implementation of the Base design language, with a documented theming and override layer.
What it solves. Many products, many markets, one language. Teams need to vary a surface without forking a component and orphaning it.
What to copy. The override model. Theming is a supported entry point rather than a workaround, so local variation happens inside the system instead of beside it. A design system that forbids variation gets bypassed. One that channels it survives.
GOV.UK Design System: publish the evidence
What it is. The GOV.UK Design System, used across government departments and by the suppliers they hire.
What it solves. Hundreds of services, built by different teams, used by everyone including people with low digital confidence and assistive technology.
What to copy. Two habits. First, components document when not to use them, alongside the user research behind the pattern; see the question pages pattern and its "one thing per page" starting point. Second, the contribution model: teams propose patterns with evidence, not opinion. That is how a system stays honest after the founding team leaves.
Material Design: the three-tier token model
What it is. Google's Material Design 3, documented as a token architecture rather than a stylesheet.
What it solves. One visual language across Android, web and thousands of third-party apps that ship at their own pace.
What to copy. The hierarchy: reference tokens hold raw values, system tokens assign semantic roles, component tokens style one element. Material names them md.ref, md.sys and md.comp for a reason. Skipping the semantic middle layer is the single most common design tokens mistake: it hard-codes meaning into values, and the moment dark mode or a rebrand arrives, everything breaks.
Adobe Spectrum: tokens are data
What it is. Spectrum, Adobe's cross-platform system, with tokens published as a versioned data specification.
What it solves. Several platforms and several products shipping on different cadences. The only stable contract left is the token file.
What to copy. Treat tokens as structured data with versions and aliases, not as a Figma page someone exports by hand. When tokens are data, a design decision can propagate to web, desktop and mobile in one release.
The seven systems side by side
| System | Owner | What it is | Best for |
|---|---|---|---|
| IBM Carbon | IBM | Open-source system, design kits plus multi-framework code, 2x Grid | Large product organisations, dense enterprise UI |
| Salesforce Lightning | Salesforce | Public system for internal teams and partners | Platform ecosystems you do not control |
| Shopify Polaris | Shopify | Web component system for Shopify surfaces | One constrained surface with many app authors |
| Uber Base | Uber | Open-source React library plus Base design language | Product suites needing supported theming |
| GOV.UK Design System | UK Government | Research-backed components and patterns | High-stakes services for the general public |
| Material Design | Token-driven system across platforms | Apps distributed to third parties at scale | |
| Adobe Spectrum | Adobe | Cross-platform tokens published as data | Multi-product, multi-platform releases |
Read the owner column first. Every system that holds up has a named organisation paying for it. Yours will need one too, even if that organisation is one person on Friday afternoons.
Design tokens are where a system becomes enforceable
Design tokens are the named decisions (colour, spacing, type, motion) that design and code both read from. They are what turns a document into something a build can fail against.
Three rules that pay off.
Name by role, not by value. color.text.primary, not blue-800. Roles survive a rebrand; values do not.
Keep the semantic layer. Raw values at the bottom, meaning in the middle, components on top. See Material's model above.
Own the format. The W3C Design Tokens Community Group maintains a stable specification for exactly this handoff, so tokens can travel between tools without a bespoke script per platform.
Then enforce it. If a hex code appears in a stylesheet and not in the token file, the system has already started to leak. That check is the cheapest design system audit available, and it takes an afternoon.
Documentation decides whether it survives
Documentation is not the manual. It is the shortest path from a question to a decision.
Six things a usable page contains: what the component is for, when not to use it, the exact variants that exist, the content rules, the accessibility notes, and who owns it. A seventh helps more than any of them: a real example pulled from production, not a demo with lorem ipsum.
Patterns deserve their own layer, separate from design system components. A component is a button. A pattern is a form with one question per page. Teams copy patterns more often than components, and patterns are where an organisation's actual judgement shows up.
How to start one small
You do not begin with a system. You begin with an audit and a shortlist.
- Audit what exists. Collect every button, input and heading in production. Count the variants. The count is your argument.
- Name an owner. One person who can say no.
- Define tokens first. Colour roles, type scale, spacing unit. Twenty decisions, not two hundred.
- Build five components. Button, input, select, table, alert. The ones already duplicated most.
- Write one page per component. With the when-not-to-use section filled in.
- Version it 0.1 and publish. A small system people use beats a complete system nobody can find.
Then hold the line on contributions. Anything new arrives with a use case attached, gets reviewed against the tokens, and either becomes part of the system or a documented exception. That is how a component library becomes a design system, and how it stays one when the brand eventually changes, which is where brand identity design and the interface stop being separate projects. On a website build, the same tokens and five components are what keep every page consistent; that is part of how I approach web design services.
If the underlying decisions are still unclear (is this a rebrand or a logo swap?) the brand identity vs logo breakdown is the place to start.
FAQ
What is the difference between a design system and a style guide?
A style guide describes. A design system prescribes and ships. If the guidance does not exist in code, it is a style guide with good typography.
How many design system components should we start with?
Five. The most duplicated ones. Coverage is a vanity metric; consistency in the parts you use daily is not.
What is a design system audit?
An inventory of every UI pattern in production, with variant counts, plus a check for values that bypass the tokens. It tells you what to delete before you build.
Do we need a full design system for one website?
No. You need tokens and five components. The rest is a library you will maintain for a use case you do not have.
Useful sources
- IBM Carbon: 2x Grid guidelines
- Salesforce Lightning Design System
- Shopify Polaris references, shopify.dev
- Uber Base Web
- GOV.UK Design System
- GOV.UK: Question pages pattern
- Material Design 3: Design tokens
- Adobe Spectrum: Design tokens
- W3C Design Tokens Community Group