Interface density research
This repository examines how public design systems support different levels of interface density within one governed system. It records the evidence at token, component, design-tool, code, typography, and accessibility levels. The research distinguishes inherited density modes from component sizes, local compact variants, responsive behavior, input modality, and product policy.
The research does not prescribe final PDS token values. The separate PDS density architecture proposal applies the evidence to the supplied PDS token snapshot and identifies a possible path forward.
Practitioners preparing an architecture decision or pilot should use the density decision handoff. It separates supported findings, the current proposal, blocked decisions, audit templates, and validation gates.
Systems covered
Seven systems form the mature-system comparison. Three supplemental systems add practitioner or implementation evidence with different levels of public inspectability.
| System | Evidence role | Report | Source record | Token evidence |
|---|---|---|---|---|
| Adobe Spectrum | Mature-system comparison | Report | Sources | View · JSON |
| Angular Material | Mature-system comparison | Report | Sources | View · JSON |
| IBM Carbon | Mature-system comparison | Report | Sources | View · JSON |
| Microsoft Fluent 2 | Mature-system comparison | Report | Sources | View · JSON |
| PatternFly | Mature-system comparison | Report | Sources | View · JSON |
| Salesforce Lightning | Mature-system comparison | Report | Sources | View · JSON |
| SAP Fiori / UI5 | Mature-system comparison | Report | Sources | View · JSON |
| Meridian | Supplemental inspectable implementation | Report | Sources | View · JSON |
| SAS | Supplemental practitioner case study | Report | Sources | View · JSON |
| Uber density demo | Supplemental design-tool demonstration | Report | Sources | View · JSON |
Every system has a report, a source/provenance record, and a machine-readable token extract. Where source or token data is not public, the corresponding file records the limitation instead of reconstructing missing values.
How to read this research
- Start with the cross-system comparison for the normalized evidence and recurring patterns.
- Read the token-model analysis for the underlying architectural models.
- Use the individual reports in
systems/to inspect claims, implementation details, limitations, and public links for a specific system. - Audit the evidence through
sources/, which contains pinned narrow snapshots or provenance-only records where downloadable source is unavailable. - Use
token-library/for normalized, machine-readable density values, aliases, activation mechanisms, and coverage gaps. - Use the practitioner token views when the JSON needs to be examined in a readable Markdown format.
- Read the practitioner evidence assessment for SAS, Uber, Meridian, and unverified social-source leads.
- Read the PDS density architecture proposal only after the research, because it applies the evidence to PDS rather than documenting an external system.
- Use the density decision handoff to run the PDS audit, workshop, pilot, and decision record.
Repository contents
| Path | Role |
|---|---|
index.md | Concise navigation entry point for the research. |
systems/ | One factual report per system. |
sources/ | Pinned upstream files and source provenance. Deep upstream paths remain unchanged. |
token-library/ | One normalized JSON extract per system plus a manifest and coverage guide. |
token-library/markdown/ | Generated practitioner-readable token views with embedded raw JSON. |
handoff/ | Decision brief, option worksheet, component inventory, workshop guide, pilot plan, and decision record. |
_comparison.md | Cross-system synthesis table and common patterns. |
_token-analysis.md | Cross-cutting density architecture models. |
_practitioner-evidence.md | Evidence-strength assessment for supplemental practitioner material. |
_implementation-data.json | Earlier normalized exact-value dataset for Spectrum, Uber, Meridian, and SAS; retained because synthesis documents cite it. The all-system index is token-library/manifest.json. |
PDS-density-proposal.md | PDS-specific application of the research; it does not define final token values. |
STRUCTURE.md | File conventions, completeness rules, and maintenance guidance. |
Root files beginning with _ are synthesis or cross-cutting artifacts, not individual system reports.
Method and evidence boundaries
Claims were checked against official guidance and, where available, pinned public source. Repository snapshots record commit hashes; documentation, interviews, and case studies record publication and retrieval details when known. Only the files needed to inspect density foundations, tokens, activation, and representative components are retained.
“Density” is used only where a system uses that term or implements an equivalent mechanism. Component size, responsive layout, typography strategy, input modality, and color theme remain separate concepts unless a source explicitly connects them.
Meridian, SAS, and the Uber demo are fully integrated into the file structure, but they remain supplemental evidence: Meridian has limited maturity evidence, SAS does not publish its production package, and Uber exposes only the variables visible in a public demo.
Accessibility baseline
WCAG 2.2 SC 2.5.8 (AA) requires a 24 × 24 CSS px target or sufficient target spacing, subject to defined exceptions; 44 × 44 CSS px is the stronger SC 2.5.5 (AAA) threshold. These standards are a floor, while several systems impose stronger touch guidance. W3C: Target Size (Minimum) W3C: Target Size (Enhanced)
Known coverage gaps
- Exact Figma density implementation remains private or insufficiently documented for most systems.
- SAS does not publish its production token JSON, component bindings, or runtime activation API.
- Uber does not publish the demonstrated Figma collection or a corresponding code implementation; only three visible List Item variables can be recorded exactly.
- Salesforce does not expose the full preference-to-runtime-token resolver.
- SAP global theme parameters are external to the captured UI5 Web Components repository.
- Carbon’s captured layout forwarding source does not include every generated padding map, although exact component heights are public.
_implementation-data.jsoncovers four deeply inspected implementations; usetoken-library/manifest.jsonfor complete ten-system coverage.