Most lists of design system examples are a gallery. Ten famous names, a paragraph each, a screenshot of a colour ramp. That is a list of documentation sites, and a documentation site is not a design system.
How these were picked
A design system example is only worth your time if you can tell which part of it is real. These seven were picked on four questions: can you install the code today, is it maintained this year, is it enforced on a product with real users, and does it teach something a small team can copy. Anything that was documentation with no implementation behind it was left out.
They are not ranked. Google's system exists to hold an operating system together and yours does not, so a ranking would be comparing a bridge to a staircase. Each entry below says who it is actually for.
| System | What you can install | Stacks | Where it stands in 2026 |
|---|---|---|---|
| Material 3 | Jetpack Compose Material 3, Material Web | Android, web, Flutter | Compose is the reference implementation, the others trail it |
| Apple HIG | Nothing. Guidance plus the system frameworks | Apple platforms | Liquid Glass adoption is optional, not an App Store gate |
| Shopify Polaris | Web components from Shopify's CDN | Any framework | The React library is deprecated and archived |
| IBM Carbon | React, web components, Sass, tokens, icons | Web | v11, releasing continuously |
| Adobe Spectrum 2 | React Spectrum v1, plus token data as its own repo | React, web | Stable |
| GitHub Primer | CSS, React, ViewComponents for Rails | Web, including server-rendered | 40+ components across three stacks |
| Atlassian | React components, Figma and illustration libraries | Web | Product-tied, documents the non-component half |
Material 3, and the version problem nobody mentions
Google introduced Material 3 Expressive in May 2025 and spent the year after that rolling it through its own apps. The visual work is the half everyone writes about. The half that matters if you are building on it: at I/O 2026 Google declared Android UI development Compose first, with Jetpack Compose Material 3 as the reference implementation and the older View-based library in maintenance. Material Web and Flutter trail Compose on Expressive coverage.
So the design site and the library you actually import are describing different products, and the gap moves. Check the component you need inside the implementation you use, not on the design site.
Who it is for: teams on Android. Adopting it wholesale on a marketing site buys you Google's constraints and none of Google's problems.
Apple's HIG is guidance, not a library
There is nothing to install. Apple gives you the Human Interface Guidelines plus the system frameworks, and Liquid Glass, introduced at WWDC 2025, is a material and a set of behaviours rather than a component set you drop in. Hierarchy moved from colour and size to depth: translucency and refraction decide what sits above what.
Adoption is not mandatory and does not affect App Store review, which is worth knowing before a redesign gets panicked onto a roadmap.
The unresolved part is accessibility. Translucent chrome over moving content is a contrast problem by construction, and the reduced-transparency path has to be designed as a real layout rather than kept as a fallback nobody looks at.
Shopify Polaris, the most useful example here, because it is a migration
Polaris shows what happens when a design system has a platform behind it. Shopify released Polaris web components on 1 October 2025 and deprecated the React library, which now sits in an archive repository. Apps on API version 2026-01 have to use the web components, and the legacy path has a hard cutoff rather than a long tail.
The reasoning is size and control. The React package ran to roughly 800KB to 1.2MB while extensions have a 64KB ceiling, and components served from Shopify's own CDN can be updated underneath running apps without every developer redeploying.
The honest part of the story is in Shopify's developer forum, where the recurring complaint is that the web components arrived missing things the React library had. A platform can force a migration. It cannot make the replacement complete on day one. Anyone planning the same move internally should read that thread before promising their team a clean swap.
IBM Carbon is the one most teams should copy
Carbon is the least exciting system on this list and the most instructive. One repository carries the React and web component libraries, Sass, tokens, icons and pictograms together. v11 has been out for years and is still releasing continuously, into the v11.111.x range, with routine work like the July 2026 icon and pictogram additions.
The product is the release cadence and the governance, not the visual language. A system nobody trusts to still be maintained next quarter gets forked inside a month, and the fork is the end of the system.
Adobe Spectrum 2 separates the data from the implementation
Spectrum 2 was announced in December 2023 and has since reached a stable v1.0 in React Spectrum. The part worth studying is not the components, it is spectrum-design-data: token data, component schemas and tooling published as a repository of its own, separate from any one implementation.
That separation is the practical lesson. Tokens as data, implementations downstream, is what lets one system serve React, native and internal tools without the three quietly drifting apart.
GitHub Primer is the example for teams that are not a React app
Primer covers more than 40 components across three stacks: CSS, React, and ViewComponents for Rails. The Rails part is the unusual one. Most public systems assume a client-rendered React app and leave the server-rendered path to whatever falls out of it.
If your product renders on the server, Primer is the system to read, because it is the rare case where that path is maintained as a first-class citizen instead of a port.
Atlassian documents the half that usually goes missing
Atlassian publishes an end-to-end language: components and patterns, plus Figma, logo and illustration libraries. Most internal systems die in exactly that gap, where the buttons are documented and nothing says what an illustration is allowed to look like or which logo lockup is legal.
The numbers that should temper all of this
zeroheight's Design Systems Report 2026, from 147 practitioners, found only 38 percent of systems reach moderate to wide adoption. 44 percent describe their foundations as unstable. 61 percent of teams say they are understaffed for the goals they were given. Design tokens are in 86 percent of systems, but only 40 percent have an automated pipeline connecting design, code and documentation.
Read the seven above against those numbers. They are survivors with funding, and they are not the normal case. The usual failure is not a bad colour ramp, it is a system that gets published, admired, and quietly not used.
The same report has buy-in satisfaction falling from 42 percent to 32 percent. A system that cannot show anyone the time it saved gets a shorter budget conversation every year.
What a small team should take from this
- Carbon's release discipline, not Google's scope.
- Spectrum's split between token data and implementation, even if your token file is 40 lines.
- Primer's honesty about serving more than one stack, if you have more than one.
- Shopify's willingness to delete the old library, but only once the new one is genuinely complete.
- Atlassian's habit of documenting the parts that are not components.
None of that needs a dedicated team. It needs a decision about what is enforced and what is merely suggested, written down where the code is.
What we do
On client work we build the smallest system the product can survive on: tokens first, a component set covering what the product actually renders, documentation next to the code rather than in a separate tool nobody opens. This site runs on CSS variables and a locked type scale, which is right for a marketing site and would be wrong for an admin product with forty screens. The size of the system is a decision, not a maturity score.