Adele: an open source dataset of design systems, not a component library

The contribution is a comparison layer over public design systems

Adele is described as an open source repository of publicly available design systems and pattern libraries, and its mission is to collect all the data about them and present it to the community in human and computer readable formats, the first through a website and the second through JSON.

The reasoning in the README is worth reading, because it explains why a dataset like this exists. Creating a design system is a long process that requires a lot of decisions, some of them about structure and technology, and all of them complex with a big impact on the future of design and development in an organisation. The project exists to serve as a reference point for those decisions, so a team can check what others did and make better decisions about its own system.

That framing sets a limit on the expectation. Adele is not a component library you install, and it is not a template you copy. It is metadata about other people's systems, which means the output of a query is a set of pointers: does a given system ship TypeScript, does it have design tokens, does it document its voice and tone, is it deprecated. From there you go and read the original system yourself.

The project is MIT licensed, written in JavaScript, developed on the master branch, and the browser front end lives at adele.uxpin.com rather than in the repository listing. The repository has no GitHub releases and the only topic is hacktoberfest, which is a hint that the roadmap depends on outside contributions rather than on a published version stream.

Three ways to consume the same data

The README offers three routes to the data, and the choice between them is really a choice about how you will use it.

The first is the website at adele.uxpin.com, where you browse the systems with multiple filters to get to the right ones quickly. The second is the individual JSON files under src/data/systems in the repository, one per system, which is what you want if you are reading a couple of records in full or checking the raw shape of the data. The third is a single common JSON file at src/data/data.json, which is the one to reach for when you are loading everything into a script.

The reason a common file exists is stated in the README as a question and an answer: Adele is an open source project, so you are free to take the data and use it in your own projects, and contributing back to the design systems community is encouraged.

That framing is important for how you should treat the dataset. It is explicitly a shared resource rather than an internal artefact, so a script that compares a dozen systems against your own requirements is a legitimate use, and a tool that ranks systems by, say, how many ship a colour palette with a contrast analysis is exactly the kind of thing the mission anticipates.

The caveat that follows from the third option is that you are consuming a snapshot of a moving world. Design systems get renamed, deprecated, replaced or quietly abandoned, and a dataset that is refreshed by hand will always be a little behind. The JSON records carry a deprecated field precisely because that state changes, but a value in a file is only as fresh as the last edit.

The per-system schema is where the real content sits

The README shows a complete example record for the Shopify Polaris system, and the schema is the interesting part of the project, because it is the list of decisions a design system actually makes.

The record starts with identity: company, with a data value and a label, then system, which carries the data, the deprecated flag, a URL and a label, then repository, with a data value naming GitHub and a link to the source. From there the record walks through the stack and then through the design itself. There is codeDepth, components, the JS library or framework, ts for TypeScript, webComponents, tests, linter, css, cssInjs, designTokens and bundleManager.

Then come the design fields: uiKit, brandGuidelines, colorPalette, colorNaming, contrastAnalysis, typography, icons, space/Grid, illustrations, dataVisualization, animation, voiceTone, accessabilityGuidelines and designPrinciples. The last group is about the documentation itself, with websiteDocumentation, codeDocumentation and storybook, and the record ends with distribution, which for Polaris is npm.

Two things stand out. The fields are mostly yes or no answers with an optional URL, so a record is a checklist rather than a description, which is what makes filtering and comparison possible. And the field list encodes a viewpoint: it treats voice and tone, illustrations, brand guidelines and accessibility guidelines as first-class attributes of a design system, alongside the tokens and the tooling. A system that omits those is marked down, and that is an opinion the dataset is making explicit.

Running the site locally is two commands and a chain of build steps

The installation section is short, which is a good sign for a project whose real content is data rather than code.

npm install
npm run serve

After that you open http://localhost:8080/ and the app is there. The serve script is a webpack dev server in development mode with the open, progress and hot flags set, so the site reloads as you work on it.

The install step is doing more than it looks, though. The postinstall script chains three tasks: it builds the data, it builds the production client bundle, and it builds the server bundle. The data build is a separate step because the data is generated, and the package scripts give it a name of its own:

node tools/data-builder.js
node tools/data-rebuilder.js
node tools/template-builder

The first is the build data task, the second is the re-build data task, and the third is the generate template task. There is a posttemplate-build hook that runs the data build again, so the order in which you run them matters.

The application itself is a React front end bundled by webpack, with a separate server configuration, and it runs on Node 22.x as declared in the package engines field. The start script runs the built server with node dist/server.js, and the repository carries both now.json and a Procfile, which are the usual deployment descriptors for a Node service on a platform that expects a start command. The build script is a shell file, build.sh, sitting next to the webpack configuration.

The test setup is Jest with Enzyme and jest-styled-components, and the linting is ESLint with the Airbnb config, plus a separate stylelint configuration and a csscomb configuration for the stylesheets.

One maintainer, a lot of manual entries, and a mission that outgrows the README

Two admissions in the README shape how much weight to put on the data.

The first is about scale. The project says it was started by a single human being and a single machine, and that the author is hoping to welcome contributors because what is impossible for one person might be quite an easy task for a team. The second is about ambition: the mission is to collect all the data about publicly available design systems and pattern libraries, and the introduction describes the ambition as dozens, hopefully soon hundreds, of systems analysed.

So this is a crowdsourced dataset in practice. Each record is a file with a fixed schema, and the contribution guide is built around that: how to add a new system, how to change the data about an existing system, and how to add a new category, each with its own section, plus the file format and formatting rules, including the rules for category names and for the data inside categories. The existence of a data-builder and a re-builder suggests the site reads the individual files and generates its own structures from them, so a new record becomes visible through the same pipeline as an edited one.

The consequence for a reader is that coverage is uneven and freshness is uneven too. The repository's last push was on 2026-09-30, and since there are no GitHub releases, the dataset has no version to compare against. If a record matters to a decision, open the URL it points to, because the record tells you that a system publishes a contrast analysis, and the system itself tells you whether it still does.

One small inconsistency is worth noting for anyone reading the repository rather than the data: the MIT licence badge in the README points at an unrelated repository, while the package metadata and the LICENSE.md file at the root both say MIT. The file is the reliable one.

Editorial conclusion

Adopt Adele when your team is at the stage of choosing or designing a component library and wants evidence about what others picked, such as whether they ship TypeScript, whether they publish a colour palette, which linter and test stack they chose, and whether the system is marked deprecated. Do not adopt it as a source of code or of a maintained dependency, because what it publishes is metadata about design systems rather than the systems themselves, and the entries are edited by hand rather than released on a schedule. Before you cite a specific entry, open the original design system documentation that the record links to, and check the repository itself for a newer value, since the last push was on 2026-09-30 and individual records change without a version number of their own.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. UXPin/adele on GitHub