decision-brief

PDS density decision brief

Decision context

PDS needs to support lower-density customer-facing experiences and higher-information application experiences while preserving one governed component system. The research shows that mature systems solve this through several mechanisms: inherited contextual scales, numeric density themes, application density policies, component sizes, local compact modifiers, and hybrids.

The decision is not whether to create a separate enterprise design system. It is where density should enter PDS’s architecture, which component metrics participate, and how product context, local overrides, component size, typography, and input modality remain governed.

What the research supports

• The same semantic component can resolve different geometry without becoming a second component library.
• Density is rarely implemented as an unrestricted multiplier across every numeric category.
• Raw foundations generally remain stable; density selects curated semantic or component outcomes.
• Component size and inherited density can coexist as separate axes.
• Data-heavy components often need a local row or size control in addition to a product default.
• Typography does not have one universal treatment: it may scale, remain independent, or change selectively.
• Visual control size and interactive target size require separate accessibility treatment.
• The ability to nest density technically does not establish a policy permitting arbitrary mixing.

See the cross-system comparison and token-model analysis for evidence and qualifications.

Current PDS proposal to test

The PDS density architecture proposal recommends testing a hybrid:

1. Keep cDLSystem foundations invariant.
2. Introduce an independent density-semantic layer with standard and compact for the first pilot.
3. Bind participating component metrics to those semantics.
4. Keep explicit component size separate.
5. Permit local density controls only for approved information-heavy patterns.
6. Keep color, responsive behavior, typography strategy, and input modality independent unless component evidence establishes a coupling.

This is a pilot hypothesis, not a finalized architecture.

Decisions that can be made now

• Treat commerce and enterprise as product-context defaults, not permanent density token names.
• Keep color and density as independent axes.
• Do not redefine raw spacing or dimension primitives by density mode.
• Do not treat compact as equivalent to component small.
• Start with a small pilot rather than defining all reserved density levels.
• Audit visible geometry and interactive target geometry separately.

Decisions blocked by missing PDS evidence

Decision	Evidence still needed
Which component properties inherit density	Component metric inventory and current bindings
Shared density collection or component-specific collections	Figma prototypes of both binding structures
Standard and compact values	Measured current components, desired information gain, and accessibility constraints
Typography participation	Semantic type-role audit, localization stress, text resize, and clipping tests
Icon participation	Component anatomy and explicit-size behavior
Allowed override scopes	Product hierarchy and composition policy
Visual and interactive target floors	Pointer/touch policy and component-level validation
User preference versus product configuration	Product and platform requirements

Required outputs from the next phase

• Native Figma variable and alias export with component bindings.
• Completed component metric inventory for the pilot set.
• Architecture comparison recorded in the decision record.
• Standard/compact Figma prototypes using the same component identity and size.
• Accessibility and localization test results.
• Approved scope and mixing policy.
• Figma/code parity plan before expansion.

Recommended pilot components

The proposal identifies one representative from each relevant anatomy family:

• Button
• Text Field
• Select/Combobox
• Data Table
• List or Navigation item
• Card
• Dialog as a constrained or deliberately non-participating case

Decision posture

Proceed with auditing and prototyping the hybrid direction. Do not publish production values or promise system-wide component participation until the audit and pilot establish the semantic contract.