The fastest way to get better at design systems is to read good ones. The big public systems from Google, IBM, the UK government, Atlassian, Shopify and GitHub are free to study, documented in detail, and shaped by years of real product work. Each one solved a problem your block theme probably has too: how to name colours so they survive a rebrand, how to space things so pages feel calm, how to stop every team inventing its own button.

This post is a tour of design system examples worth studying, with a practical twist. For each one, we look at what it does especially well, and what a WordPress block theme can borrow from it, mapped to theme.json, block styles and block patterns. Not copying their look. Borrowing their thinking. If you only have time for one, start with GOV.UK: its reasoning is the easiest to follow and the hardest to forget.

What to look for when you read a design system

Most mature design systems are built from the same layers. Knowing them makes any system easier to read, and it maps neatly onto how a block theme is structured.

Design system layer	What it contains	Block theme equivalent
Foundations or tokens	Colour, type, spacing, radius, motion values with names	theme.json `settings` presets (palette, font sizes, spacing sizes)
Themes or modes	Light, dark, high contrast, brand variants	theme.json style variations in `styles/*.json`
Components	Buttons, cards, inputs, with variants and states	Core blocks plus block style variations
Patterns	Recurring arrangements: forms, empty states, page sections	Block patterns and template parts
Content guidelines	Voice, tone, how to write labels and errors	Pattern placeholder copy and editor documentation
Governance	Who changes what, how changes are proposed	Locked settings, curated palettes, your own rules

Keep this table in mind as you read the examples. Every good idea below lands in one of those rows.

1. Material Design 3 (Google)

Material Design 3 is probably the most widely seen design system in the world, because it runs through Android and many Google products.

What it does well: colour as a system of roles. Material does not ask designers to pick hex values for every surface. It defines roles such as primary, on-primary, primary container, surface and outline, and builds them from tonal palettes. The colour system overview is a masterclass in naming colours by what they do. Its type scale works the same way, with roles like display, headline, title, body and label instead of arbitrary sizes.

What a block theme can borrow: role-based palette slugs. Instead of “blue” and “light-blue” in theme.json, use slugs like primary, on-primary, surface and outline. The “on” pairing is especially useful: it documents which text colour is safe on which background, right in the name. Name font sizes by role too, so editors pick “Headline” or “Body” rather than “24px”.

2. Carbon (IBM)

Carbon is IBM’s open-source system, built for dense, data-heavy enterprise products.

What it does well: a spacing scale and themes that are easy to reason about. Carbon’s spacing scale is a numbered set of tokens, from $spacing-01 at 2px up to $spacing-13 at 160px, used everywhere for margin and padding. Carbon also ships four themes (White, Gray 10, Gray 90 and Gray 100) built from the same tokens, so switching between light and dark is a token swap, not a redesign.

What a block theme can borrow: a numbered spacing scale in settings.spacing.spacingSizes, and themes as style variations. A block theme can offer a “Light” and a “Dark” style variation, each a JSON file in the theme’s styles folder that changes palette values while keeping the same slugs. WordPress’s style variations documentation covers the mechanics.

"spacing": {
  "spacingSizes": [
    { "slug": "20", "name": "2X small", "size": "0.25rem" },
    { "slug": "30", "name": "X small", "size": "0.5rem" },
    { "slug": "40", "name": "Small", "size": "1rem" },
    { "slug": "50", "name": "Medium", "size": "1.5rem" },
    { "slug": "60", "name": "Large", "size": "2rem" },
    { "slug": "70", "name": "X large", "size": "3rem" },
    { "slug": "80", "name": "2X large", "size": "5rem" }
  ]
}

Seven steps is enough for most sites. Carbon needs thirteen because it serves complex software. Borrow the idea of a numbered, named scale, not the exact count.

3. GOV.UK Design System (UK government)

The GOV.UK Design System serves services that every citizen might need to use, on any device, including people with disabilities and people with slow connections.

What it does well: evidence and plain guidance. Components and patterns come with research notes, known issues and advice on when not to use them. Its spacing guidance uses two scales, a responsive one that grows on larger screens and a static one that does not, which is a practical answer to “should this padding change on mobile?”. The patterns section (“Ask users for…”) is organised around tasks people are trying to complete, not around components.

What a block theme can borrow: task-based patterns and honest guidance. Name block patterns after what the visitor is doing (“Contact us”, “Book a call”, “Compare plans”) rather than what they look like (“Two column with image”). And write a short “use this when” note for each pattern in your theme’s documentation. For responsive spacing, use clamp() values in spacing presets so section padding grows with the screen without extra breakpoints.

4. Atlassian Design System

The Atlassian Design System powers Jira, Confluence and the rest of Atlassian’s products.

What it does well: token names that carry meaning. Its design tokens are named by purpose, like color.text for default body text, with further parts of the name describing emphasis and state. Atlassian’s own advice is to choose tokens based on meaning, not on how they look. That one rule prevents most of the inconsistency that creeps into a growing product.

What a block theme can borrow: meaning-first slugs for your palette and custom properties. A small, consistent naming grammar such as text, text-subtle, background, background-brand and border is easy for editors to understand and almost impossible to misuse. Add custom tokens that are not editor-facing under settings.custom, which WordPress outputs as CSS variables, so your block styles can use them too.

Here is what that looks like in theme.json. Each key under settings.custom becomes a CSS variable, so border.subtle below is output as --wp--custom--border--subtle and can be used in block styles and patterns:

"settings": {
  "custom": {
    "border": {
      "subtle": "#e4e7ec",
      "strong": "#98a2b3"
    },
    "radius": {
      "small": "6px",
      "large": "16px"
    }
  }
}

Editors never see these in a picker, but every card and callout that uses them stays consistent, and a change in one place reaches all of them.

5. Polaris (Shopify)

Polaris is Shopify’s design system for the admin and for the apps that live inside it.

What it does well: content as part of the design system. Polaris has always treated words with the same care as pixels: guidance on voice and tone, how to write button labels, how to phrase errors and empty states. For a commerce admin used all day by merchants, clear words are as important as clear layout.

What a block theme can borrow: content rules for patterns. Most block patterns ship with filler like “Lorem ipsum” or “Add your heading here”. Replace it with realistic, on-voice placeholder copy that shows editors what good looks like: a real-sounding headline length, a button label that says what happens next (“Book a call”, not “Submit”). Editors copy what they see, so show them good examples.

6. Primer (GitHub)

Primer is GitHub’s design system, used across github.com.

What it does well: functional colour and support for many themes. GitHub offers several light, dark and high-contrast themes, including colour-blind friendly options. That only works because components use functional colour tokens (foreground, background, border, and accent, success, danger and attention variants) rather than raw colour values.

What a block theme can borrow: accessibility-minded style variations. If your palette is role-based, adding a high-contrast style variation is mostly a matter of new values for the same slugs. It is a small amount of work that matters a lot to the visitors who need it, and very few themes offer it.

A high-contrast variation is a small JSON file in the theme’s styles folder that gives existing slugs new values. Nothing in your patterns or block styles needs to change:

{
  "version": 3,
  "title": "High contrast",
  "settings": {
    "color": {
      "palette": [
        { "slug": "primary", "color": "#0033cc", "name": "Primary" },
        { "slug": "on-primary", "color": "#ffffff", "name": "On primary" },
        { "slug": "surface", "color": "#ffffff", "name": "Surface" },
        { "slug": "text", "color": "#000000", "name": "Text" },
        { "slug": "text-subtle", "color": "#1f2937", "name": "Text subtle" }
      ]
    }
  }
}

The site owner picks it in Styles in the Site Editor. Check every pair with a contrast tool before you ship it; “high contrast” is a promise, so it should comfortably exceed the 4.5:1 minimum rather than scrape past it.

7. The WordPress components themselves

The block editor has its own component library, documented in the Gutenberg Storybook. It is the design system for the editor interface rather than for your site’s front end, but it is worth studying if you build anything editors interact with, such as block controls or custom settings screens.

What a block theme can borrow: consistency with the editor. Block style variations and pattern categories that feel native to the editor are easier for clients to learn. If you also design admin screens, our comparison of WordPress design tokens for admin screens versus theme.json covers where the two meet.

The design system examples, side by side

System	Study it for	Borrow into a block theme as
Material Design 3	Colour and type roles	Role-based palette and font size slugs
Carbon	Spacing scale, themes	Numbered spacing presets, style variations
GOV.UK	Task-based patterns, research-backed guidance	Patterns named by visitor task, “use this when” notes
Atlassian	Meaning-first token naming	A naming grammar for slugs and custom tokens
Polaris	Content guidelines	Realistic placeholder copy in patterns
Primer	Functional colour, many themes	High-contrast and dark style variations
WordPress components	Editor-native UI	Block styles and patterns that feel native

Borrowing in practice: a small worked example

Say you are building a block theme for a consultancy. Here is how the ideas above combine without copying anyone’s look.

Palette, Material and Atlassian style: seven role slugs (primary, on-primary, surface, text, text-subtle, border, accent), each checked for contrast against the background it will sit on.
Spacing, Carbon style: seven numbered spacing presets, with the two largest using clamp() so sections breathe more on desktop, GOV.UK style.
Themes, Carbon and Primer style: a default light look, plus “Dark” and “High contrast” style variations that reuse every slug with new values.
Components: block style variations for the group block (“Card”, “Callout”) and the button block (“Outline”), each built only from the tokens above. WordPress’s block style variations guide covers registering them.
Patterns, GOV.UK and Polaris style: “Book a call”, “Our process”, “Client results” and “Pricing”, named by task, each with realistic placeholder copy.

The result looks like your client, not like Google or IBM. But it behaves like a mature design system: consistent, accessible, easy to change in one place. For the token layer in more depth, see our posts on design tokens in theme.json for block themes and on custom block styles as a design system.

A theme.json checklist built from these examples

Here is the whole tour condensed into checks you can run against your own theme.json today:

Palette slugs describe a job, not a colour. No blue, light-gray or color-1.
Every text colour has a known safe background, recorded in the name (an “on” pairing) or in your docs.
defaultPalette is off unless you have a reason for editors to see WordPress’s colours next to yours.
Font sizes are named by role and limited to what the design uses, with fluid values for the larger ones.
Spacing is a short numbered scale used by patterns and offered to editors, so both pick from the same steps.
Dark and high-contrast looks are style variations that reuse every slug, not separate sets of classes.
Component variants are block style variations built only from presets and custom tokens.
Non-editor tokens live in settings.custom, so the editor controls stay short.
Patterns are named after visitor tasks and ship with realistic copy.

Most themes pass three or four of these. Each one you add makes the theme easier to hand over, easier to rebrand and harder to break.

Documenting your own system inside the theme

The examples in this post are useful because they are written down. A block theme can be documented the same way, at a scale that fits.

A token table in the README: every palette slug, font size and spacing step, with what it is for. Ten minutes to write, and it answers most “which colour do I use?” questions forever.
A style guide pattern: one block pattern that shows every colour role, every heading size, every button style and every block style variation on one page. Insert it on a private page and you have a living reference that updates itself when theme.json changes.
Pattern notes: one line per pattern saying when to use it, borrowed straight from GOV.UK’s habit of explaining “when to use this” and “when not to”.
Three rules, written plainly at the top of the README, such as “tokens live in theme.json”, “no hex values in patterns” and “new colours need a role”.

That is the whole of governance for most themes. It is small, but it is the difference between a theme and a design system.

What not to copy

The scale of a huge system. Carbon and Material serve thousands of screens. A brochure site needs a fraction of their tokens. Copying every step creates choices nobody needs.
Their visual identity. A site that looks like Material reads as “Google-ish”, not as your client’s brand. Borrow structure, not style.
Their component list. Most of a product design system’s components (data tables, date pickers, side navigation) are not things a marketing or content site needs. Core blocks plus a few style variations go a long way.
Their governance overhead. Contribution models and versioning policies exist for large teams. For a single theme, one short rule (“tokens live in theme.json, nowhere else”) is usually enough.

Design systems and AI agents

One more reason to study these systems: they are written so that many people can follow the same rules without asking. That is exactly what an AI coding assistant needs too. A theme with role-named tokens, a short spacing scale and documented patterns is far easier for an agent to extend correctly than one held together by memory and habit. We wrote about this in a design system an AI agent can follow, and the same qualities that make Atlassian’s or GOV.UK’s systems easy for humans make yours easy for tools.

How to study a design system in one afternoon

Pick one system from the list that is closest to your kind of work.
Read the foundations first: colour, type and spacing. Note how tokens are named.
Read one component in full, such as the button, including its variants, states and “do and don’t” guidance.
Read one pattern, ideally a form or an empty state.
Write down three ideas you could apply to your theme this week, and which theme.json key or block feature each one maps to.

Three ideas a week, applied, beat a month of reading. Our post on how field types can drive layout in a design system is a good companion once you start applying them.

Questions designers ask

What is a good design system example for a small team?

GOV.UK is a great start, because its guidance is plain and explains why each decision was made. Carbon is good for learning spacing and themes. Material is the reference for colour roles.

Which one should I study if I build shop themes?

Polaris, for its content guidance and commerce-focused thinking, then Material for colour roles. Shop pages live or die on clear labels, prices and buttons, so the words matter as much as the layout. Our teardown of WooCommerce’s Purple block theme shows how one commerce block theme structures its tokens.

Can a WordPress block theme really be a design system?

Yes. theme.json holds the tokens, style variations hold the themes, block style variations hold component variants, and patterns hold recurring layouts. What most themes lack is naming discipline and documentation, not features.

Should I base my theme on Material or another system directly?

Usually not. Borrow how they structure and name things, then give the theme its own visual identity.

How many tokens does a block theme need?

Typically eight to twelve colour roles, five to seven font sizes and six to eight spacing steps. Fewer, well-named tokens beat many vague ones.

Are these design systems free to study and learn from?

Their documentation is public and written to be read. Several, including Carbon and Primer, are open source. Learning from how they structure and name things is exactly what they are there for; copying their brand assets or visual identity into a client theme is not.

Where do custom tokens that editors should not see go?

Under settings.custom in theme.json. WordPress outputs them as CSS variables your block styles can use, without adding them to the editor’s controls.

Start with one borrowed idea

You do not need to rebuild your theme to learn from these systems. Pick one idea this week: rename your palette slugs by role, add a numbered spacing scale, or rewrite one pattern around a visitor task with real placeholder copy. Each one makes your block theme a little more like a design system, and a lot easier to keep consistent. When you are ready to go further, our guide to design tokens that outlive your CSS framework explains why the token layer is the part worth getting right first.

Design System Examples Worth Studying, and What a WordPress Block Theme Can Borrow