Methodology

What the benchmark measures

Patterns observable in publicly accessible frontend code and rendered pages — primarily the CSS a site actually ships to every visitor's browser. That includes color values, font sizes, spacing, and whether design tokens (CSS custom properties) are used instead of hardcoded values. Nothing here requires logging in, bypassing access controls, or accessing anything that isn't already served to any anonymous visitor. Dsign Systems independently benchmarks this public data — a domain can appear on the leaderboard without its owner having submitted, participated in, verified, endorsed, or approved the benchmark.

Best suited to, and less suited to

This benchmark works best on publicly accessible marketing sites, documentation, and other crawlable frontend surfaces, where the shipped CSS is a reasonably direct reflection of what's rendered. It's less reliable on JavaScript-heavy applications (where styling can be generated or injected at runtime) and can't reach authenticated product areas at all — an app's real design-system discipline may live entirely behind a login this benchmark never sees.

How the score is calculated

The Observable Frontend Consistency Score (0–100) is a weighted sum of four categories, computed only from what's publicly observable in the page's shipped CSS:

Whether a prefers-color-scheme, .dark selector, or data-theme hook was detected is shown separately as a "Theme support" signal and does not affect this score — not offering dark mode can be a deliberate product decision, not a design-system gap. Each result also shows a benchmark version (currently v1.1), so a future change to these weights won't silently reinterpret an older score.

Confidence levels

Every result shows how much was actually available to analyze, not just the score itself:

• High — a substantial, largely complete set of the site's shipped CSS was gathered.
• Medium — a reasonable sample was gathered, but some linked stylesheets couldn't be fetched, or the sample was moderate in size.
• Low — only a small amount of CSS could be gathered, or most linked stylesheets failed to fetch. Treat these results as a rough signal, not a firm conclusion.
• Insufficient observable data — too little CSS was observable to say anything meaningful at all. Rather than show a low number that would look like a real finding, no score is shown.

These levels describe the completeness of the observable CSS sample a scan could gather — not the maturity of the organisation's full design system.

What the benchmark cannot measure

Internal tooling, private source code that isn't publicly shipped, design-system governance, team structure or process, internal Figma libraries, unpublished components, or internal documentation. CSS-in-JS, Tailwind-style utility classes, and hashed/generated class names can also obscure what's really there, and JavaScript-rendered states that only appear after interaction aren't captured by a static scan. A low score describes what's observable in the public bundle — it isn't a claim about a team's internal design-system maturity, which this benchmark has no visibility into.

Limitations of evaluating a design system from a public website

A site can score low here while having excellent internal tooling that just doesn't happen to reduce to fewer hardcoded values in the shipped bundle — and vice versa. The scan also can't distinguish first-party CSS from third-party widgets or vendor stylesheets loaded on the page, which can inflate findings. And a public marketing site's CSS isn't necessarily representative of the authenticated product experience behind it. Treat the score as a signal worth investigating, not a verdict.

When the benchmark data was last updated

The public leaderboard's seed dataset was last refreshed on September 7, 2026, under benchmark v1.1. Individual results are timestamped at scan time and shown with their own "Scanned" date on the leaderboard and result page — a score is a snapshot of a site's public CSS at that moment, not an ongoing measurement, since that CSS can change at any time.

Corrections & profile claims

If you own or manage a listed domain, you can claim the profile, request a rescan, report a factual issue with a result, or request removal from the public leaderboard. Start a request. We review these individually rather than acting automatically on an unverified request — you'll hear back by email within 2 business days. Submitting a request doesn't add you to a mailing list, and claiming a profile doesn't imply you've endorsed or verified the underlying analysis unless we confirm that with you directly.