Design system roundups are usually organised by company, which is the least useful axis — you already know who Airbnb is, and that fact does not tell you whether their system will help you. Here is the same set organised by what you are trying to figure out.

The rest of this walks through each, with what is available and what is worth taking.

Reading Carbon, Polaris and Lightning together turns up something none of them is discussed for individually. All three restructured recently, in different ways, on the same premise: the code consuming a design system is increasingly not written by a human reading the documentation.

Salesforce is the most explicit about it, describing SLDS 2 as the foundation for its agentic design system and referring to dynamically generated user experiences. IBM's stated reason for the MCP server includes higher-fidelity generated code. Shopify's framing is about apps looking native to the admin, but the effect is the same: components that render identically regardless of what assembled them.

Nobody coordinated this. Three companies with different products, different constraints and no reason to agree arrived at compatible conclusions in the same window — which is usually the sign that the underlying change is real rather than fashionable.

Open source, funded and built by IBM, built on the IBM Design Language as a separate brand-foundation layer, with domain systems (IBM Products, Cloud, IBM.com) above the core. React, Web Components and Elements are maintained by the Carbon team; Angular, Vue and Svelte are community-maintained, and the documentation says so — which is the honest disclosure most systems skip.

Take: the three-layer separation, and the practice of publishing who maintains each implementation. Skip: adopting it wholesale if visual differentiation matters to your product, because the density and interaction idioms carry IBM's identity even after you retheme the colours. Full read.

Foundations, tokens, components and over 400 commerce-focused icons. The React library is now labelled deprecated; web components load from a Shopify CDN and are added automatically by Shopify CLI.

Take: the commerce icon set if you build in that space, the token naming approach, and the delivery-model reasoning. Skip: the components outside a Shopify app — they will make your product look like Shopify. Full read.

SLDS 1 launched in 2015 as a CSS framework with the appearance baked in. SLDS 2 rebuilt it around CSS custom properties, added a Figma library whose token names match the code exactly, and shipped linting tools that validate markup against the rules.

Take: the Figma-code naming parity, and the linter as the enforcement mechanism. Both are copyable without adopting a line of Salesforce CSS. Skip: the framework itself unless you build on the Lightning Platform. Full read.

The strongest example of a system built around a constraint nobody else takes as seriously: it has to work for everyone, including people on old devices, poor connections, screen readers and under stress. Components come with published research on how they were tested and why they look the way they do.

Take: the practice of publishing the evidence behind each component. Almost nobody does this, and it is the difference between a system you follow and one you argue with. Skip: the aesthetic, which is deliberately institutional.

Long-running, thoroughly documented, and unusually strong on content and voice guidance rather than only visual specification — the part of a design system that most teams never write.

Take: the writing and content standards. If your system has no section on how things are worded, this is the model. Skip: nothing in particular; it is a reasonable general reference.

This category confuses people, so it is worth stating plainly: several of the most-cited design systems cannot be downloaded. What exists is the team's published writing about them, which is often more useful than the code would have been.

There is a pattern in that table worth noticing: the systems with the strongest visual identities publish the least. That is not a coincidence or a competitive secret. A system that exists to make one product feel like itself has nothing to gain from being installable, and a system built to be adopted by thousands of teams has to be neutral enough to survive that. Neutrality and identity trade against each other.

The systems above are the ones worth reading closely. These are worth knowing exist, with the one thing each is actually good for.

Both matter for a reason that is easy to miss: they set the conventions your users have already learned. Even if you build nothing with them, they define what "the back button behaves normally" means. Airbnb's DLS drew its platform-divergence line precisely around what these two own.

Cloudscape is the underrated one. Most published systems are optimised for marketing and general application UI; very few take dense operational interfaces seriously, and the ones that do rarely publish. If you build admin or console software, it is closer to your problem than Material or Polaris.

This row deserves emphasis because it is where most teams actually are. Adopting Radix plus shadcn plus Tailwind gives you excellent accessible behaviour, a token layer and a distribution story — and no decisions about density, composition, motifs or what is forbidden. That combination produces the consistent, competent, entirely interchangeable interface that people then describe as looking AI-generated. The distinction, in full.

Several large catalogues index public design systems, and they answer a narrow question well: has anyone in my sector solved this, and what did they call it? A component gallery is genuinely useful for seeing eleven takes on a date picker side by side before you design a twelfth.

What they do not do is tell you which system is worth studying. A directory entry is a link and a screenshot; the reasoning lives in the team's writing, not in the catalogue. Use them for breadth and go to the source for depth.

Every example above is documentation you read. That is the format's built-in limitation: a design system is only judgeable once the same decisions are carried across screens that have nothing to do with each other. A landing page proves a system can look good once. A landing page, a dashboard and a component sheet built from one token set prove it holds.

These are complete systems rendered live, not screenshots. Each is one token set applied across three unrelated surfaces — so what you are checking is not whether you like the colours, but whether the *same* decisions survive a marketing hero and a dense table.

The most valuable version of this exercise is one nobody has published, on a product in your own sector. It takes about an hour.

1. 1

   Capture three screens, not one

   One screen shows you the palette. Three show you which decisions repeat, and repetition is what distinguishes a system from a page.

2. 2

   Read computed values, do not eyeball

   Open dev tools and write down font-weight, letter-spacing, border-width, border-radius and padding. "Tight tracking" is an impression; -0.022em above 48px is a rule.

3. 3

   Look for the range, not the value

   The finding is rarely one number. It is that every weight falls between 400 and 510, or that radius is only ever 6 or 12. Ranges are rules; single values are samples.

4. 4

   Write down what is absent

   No shadows. No gradients. No second accent. No weight above 510. Absences are the highest-value output of a teardown and the first thing lost in any automated extraction.

5. 5

   Convert each observation into an instruction

   "Elevation is a surface step plus a 1px border, never a box-shadow" is executable. "Minimal and precise" is not. This step is where a teardown becomes a design system.

Step four is the one to insist on. We sampled 299 DESIGN.md files written to give AI agents design guidance and found that 76% contain no prohibitions at all, alongside 86% specifying colours as raw hex with no semantic role and 57% defining no distinctive motifs. Those files describe a palette. The identity they were trying to capture was in the absences.

There is a version of studying design systems that produces something worse than starting from nothing. It happens when the exercise becomes acquisitive: assemble the best parts of nine systems and you get a competent interface with no argument behind it.

Every system above is downstream of a decision about a reader. Linear's density is an argument that a power user in a tool all day wants quiet and information. GOV.UK's plainness is an argument that the reader may be stressed, on a bad connection, and cannot be assumed to have anything. Carbon's neutrality is an argument that thousands of teams will adopt it and none of them are IBM's brand team.

Use these to calibrate rigour — how specific the numbers get, how many things get forbidden, how narrow the ranges are. Then make your own argument about your own reader, and let the rules follow from it.