Tokens & playbooks / Design reference library
DesignSystems.one
Compare published systems and inspect their design foundations.
Understand the resource
What it is.
DesignSystems.one indexes real design systems, guides and tools, with token and agent-oriented resources. It helps explain how systems are organized; each linked system remains the authority for its own implementation and license.
When it is useful
You need to decide how to document tokens, patterns and component ownership.
A proposed application
Put it to work.
This example illustrates a possible use. The proposed workflow and expected result are separate from the bounded checks recorded below.
Try this
Compare the documentation structure of two relevant systems, then write a smaller outline suited to your own product.
Result to aim for
A documentation plan grounded in real examples.
Before you start
What you need.
- A browser and a clear question about your own system.
The practical boundaries
What to watch for.
- A directory entry does not mean the original system can be copied or that its tokens suit your brand.
- Scanner and generator tools were not run; verify their data flow before using private inputs.
Review record
What we could establish.
- Public primary documentation reviewed. See the account-free evaluation for executed checks and remaining workflow limits.
The source-review notes describe documentation and identity. The account-free evaluation below records exactly which public interaction or local fixture was checked, what happened, and what remains untested.
Check current access, terms, licensing and data handling before using a resource with your own material.
Runtime and security evaluation
What the evaluation covers.
The IBM Carbon entry opened with origin, governance and token sections. The directory can support a public, account-free comparison of design-system structure.
Methods: Public HTTP response · Public browser sample. A completed check covers the stated sample; it is not a safety certification.
- Target
- https://www.designsystems.one/
- Version or capture
- Unversioned public page observed on 2026-10-19
- Integrity scope
- sha256:66b477afd357e18c98ea76882ad1020f86121c9fb63ce41a9bbad36aaa751ba5 — initial HTTP 200 response body only; not whole-application integrity.
Test conditions
- Chromium 155.0.8059.82, 1365×900 desktop viewport.
- Separate fresh, ephemeral browser contexts for entry and interaction; no owner profile, credentials or stored session.
- Only GET/HEAD network requests allowed; forms, downloads, WebSockets and service workers blocked. Some analytics endpoints also blocked.
- Short bounded waits; no mobile, assistive-technology, cross-browser or performance certification.
Individual checks and observations
Public HTTP response
passPublic HTTP response: Anonymous GET with redirects followed, response-body SHA-256 and selected security-header summaries; no cookies retained.
Observed: The standalone client received 200 at https://www.designsystems.one/. This establishes response delivery only.
Fresh browser entry
passPublic browser sample: Open the catalog URL in a new anonymous Chromium context with read-only network guards and no inherited profile.
Observed: The document returned 200 and identified itself as “DesignSystems.one | Design Systems, Explained — Gallery, Guides & Tools”. 18 image elements were present; no account was used.
Observed public sample or navigation
passPublic browser sample: Follow the observed Carbon link to https://www.designsystems.one/design-systems/carbon-design.
Observed: The destination returned 200; title: “IBM Carbon Design System | DesignSystems.one”. 2 page image elements had decoded during the bounded wait. This count is not a catalog size or performance benchmark.
Security findings and boundaries
Passive inspection of the initial public document’s response headers and anonymous browser request hostnames, with read-only guards. No source exploitation, account access, dependency audit or private data.
Observed · info
Public response protections
The initial browser page used HTTPS. Its response included HSTS. No enforcing Content-Security-Policy response header was observed. This records the sampled response only; meta policies, backend authorization and exploit resistance were not assessed.
Observed · info
Request surface in the anonymous visit
DesignSystems.one attempted requests to 6 additional hosts, including api.fontshare.com, datafa.st, getmayfly.com, www.google.com. Host counts include requests stopped by the test guard; they do not establish what data a service retained.
Practical advice · caution
Before using this reference
Follow the original system documentation before adopting tokens or interpreting an agent-readiness score.
Practical caveats
- Follow the original system documentation before adopting tokens or interpreting an agent-readiness score.
- A directory entry does not mean the original system can be copied or that its tokens suit your brand.
What remains untested
- No scanner, generator, agent integration or upstream design-system package was run; directory rankings were not independently reproduced.
- Results describe the observed public pages and a bounded action, not the entire product or the referenced designs.
Security limits
- No authentication, authorization, tenant separation, data retention or backend handling was tested.
- Header presence or absence is a sampled configuration observation, not a security certification or an exploit finding.
- 3 blocked-request records were retained across entry and interaction checks. Guards may alter normal page behavior; the logs do not represent unrestricted traffic.
Evaluation sources
Follow the evidence
Sources and further reading.
Keep exploring
More in tokens & playbooks.
Documentation reviewed
UI Skills
Turn broad polish requests into focused review tasks.
Documentation reviewed
Design System Checklist
Review what a design system needs beyond colors and buttons.
Documentation reviewed
Open Props
Replace repeated visual guesses with a named CSS scale.