Practitioner evidence: density implementation in use
Supplemental research retrieved 2026-08-13. This file separates practitioner evidence from the seven mature-system reports because the sources have different levels of inspectability and authority.
Evidence labels
| Label | Meaning |
|---|---|
| Strong | Practitioner-authored case study or inspectable public implementation. |
| Supporting | Primary interview/demo or an official transcript/summary, but no public token/component source. |
| Unverified | Social attribution could not be independently retrieved; useful only as a lead. |
SAS: independent density, theme, and language dimensions
Evidence: strong. SAS Product Design published a detailed practitioner-authored account of its token refactor.
The demand originated in a data-intensive application whose users wanted more information visible at once. SAS then used workshops and user testing across product teams to validate broader demand. The team evaluated numeric properties including spacing, margins, padding, gaps, component dimensions, typography, icons, and radius.
The resulting public vocabulary was standard, compact, and comfortable; developers used medium, high, and low density respectively. SAS moved away from JSON organized primarily around themes and toward domain-based collections for brand, core, density, language, and theme. The collections were imported into Tokens Studio so those axes could be selected independently rather than encoded as combinations such as light-compact and dark-comfortable.
Typography exposed an important boundary. Compact moved the default from 14 px toward a 12 px minimum, but language-specific defaults complicated a uniform transform: some locales, including Chinese, required larger defaults. This is direct evidence that density, typography, and locale may be separate axes even when compact mode changes selected type roles.
The account also reports that a central repository, documentation, and workshops were necessary for adoption, and that the modular organization improved maintenance. It does not expose the production token repository or component implementation, so the exact resolver and component-level clamps cannot be inspected.
Source: SAS Product Design, “Refactoring design system tokens for a multi-dimensional future”
The full SAS implementation report records the published load order, Token Studio collections, affected categories, values, and unresolved locale precedence.
Uber: Figma modes as inherited design context
Evidence: supporting, with exact visible Figma data. Direct inspection of the density segment revealed a component-specific listitem density collection with Default, Compact, and Spacious modes. It contains parent-vertical-padding (8/4/16), child-vertical-padding (4/4/4), and parent-minHeight (64/48/64). A selected frame exposes Listitem density separately from Theme, and the density selector includes inherited Auto (Default).
This supports the architectural claim that one List Item component can resolve different geometry from an inherited frame context. It also adds a qualification: the visible collection is component-specific, not evidence of one Uber-wide density semantic collection. See the full demo report and timestamped observations.
The evidence does not support treating the tag-variant reduction as a measured outcome of density alone. The tag example concerns moving axes such as color into variables, while density is demonstrated separately. Public summaries also disagree about the final number: one social transcript says approximately 880 to 56 variants; an official Figma LinkedIn transcript describes roughly 880 components becoming 84. The defensible conclusion is that component-specific variables sharply reduced the component/variant burden, not that a particular density refactor produced one settled count.
No public Uber token source, component package, or downloadable Figma schema was linked. The exact three-variable List Item schema is visible, but aliases, other components, code activation, typography behavior, and accessibility floors remain unavailable.
Sources: Design Systems Media interview index and timestamps, YouTube interview, Figma’s published LinkedIn transcript
The cited X post could not be retrieved independently during this research pass: Jayneil Dalal on X. It is retained as an unverified attribution, not used as the sole basis for a factual claim.
Meridian: inspectable inherited density plus local controls
Evidence: strong for implementation, weak for maturity/adoption. Meridian is a small and recent public repository, so it is not a peer maturity benchmark for Spectrum, SAP, or Carbon. It is useful because the mechanism is explicit and inspectable.
The root defaults and compact overrides are:
:root {
--control-h-sm: 28px;
--control-h-md: 36px;
--control-h-lg: 44px;
--table-pad-y: 12px;
--table-pad-x: 16px;
}
[data-density="compact"] {
--control-h-sm: 24px;
--control-h-md: 30px;
--control-h-lg: 38px;
--table-pad-y: 7px;
--table-pad-x: 12px;
}The attribute may be placed on the document root or a subtree. Button and Input keep explicit sm/md/lg sizes, but their heights resolve through the inherited --control-h-* variables. Select uses the inherited medium control height. Table uses inherited table padding and also exposes a separate dense prop, whose class changes cell padding and text size. Card instead exposes a local size="sm" spacing rule and does not consume the global density variables.
This is a concrete hybrid path:
ancestor data-density
→ inherited control/table variables
→ component size chooses a semantic slot
→ selected components may add an explicit local compact controlTypography is not globally remapped by compact density. It changes only where an explicit component size or the table’s local dense modifier selects another text token. The implementation therefore avoids a universal proportional shrink.
Sources: Meridian repository, captured source provenance, captured spacing tokens, captured Button, captured Table
The full Meridian report additionally documents the incomplete density representation in tokens.json, explicit size composition, and the global-compact/local-table interaction.
The announcement post could not be retrieved independently during this pass: Meridian announcement on X. The public repository, rather than the post, supports the implementation claims above.
Spectrum-adjacent utility report
Evidence: unverified social attribution. The reported stack({density: 'spacious'}) example could not be located in official React Spectrum or Spectrum documentation during this pass, and the linked X post could not be retrieved. It should not be used as evidence for Spectrum’s supported density API without the original code or documentation context.
The existing Spectrum report remains based on official platform-scale documentation and inspectable design data. Source lead retained for later verification: Devon Govett on X.
What this evidence adds to the established models
The practitioner material corroborates, rather than replaces, the five models in the token analysis:
- SAS strengthens the case for independent mode dimensions and domain-oriented token collections. It adds locale/type interaction as a concrete reason not to couple every axis.
- Uber shows that Figma variable modes can carry inherited density context while component-specific variables reduce variant burden. It does not establish that every product should use a global mode.
- Meridian provides inspectable code for a hybrid: subtree inheritance, explicit component sizes, and a separate local table control can coexist.
- The sources repeatedly expose governance as the hard part: which scopes may override density, which properties participate, and which accessibility or locale floors prevent compression.
Together they strengthen the PDS proposal’s sequence: recover the alias/binding graph, classify every component metric, define a small independent semantic density contract, and then validate scoped inheritance plus approved local controls. They do not justify generating PDS values before that inventory.