pilot-plan

Density pilot plan

This plan restates the gated path in the PDS proposal as a practitioner checklist. Values remain intentionally undefined until the relevant audit gate is complete.

Gate 0: Recover the current system graph

• Export native Figma collections, modes, variable IDs, aliases, types, scopes, descriptions, code syntax, and publish status.
• Inventory variable and style bindings on pilot component nodes.
• Identify current code tokens, CSS variables, props, and hard-coded metrics.
• Record existing naming defects separately from density work.

Exit condition: the team can trace each pilot metric from foundation or literal through Figma and code consumption without inferring aliases from equal values.

Gate 1: Complete the component metric inventory

• Audit Button.
• Audit Text Field.
• Audit Select/Combobox.
• Audit Data Table/Grid.
• Audit List/Navigation item.
• Audit Card.
• Audit Dialog as a constrained or non-participating case.
• Classify every metric using the shared vocabulary.

Exit condition: participating, invariant, explicit-size, local, responsive, modality-driven, and constrained properties are documented for every pilot component.

Gate 2: Prototype the semantic contract

• Map standard to current behavior where possible.
• Select candidate compact aliases only from measured component needs and existing foundations.
• Document component clamps, exclusions, and target behavior.
• Prototype one shared density-semantic collection.
• Prototype component-specific collections for comparison.
• Compare inheritance clarity, author controls, synchronization, discoverability, migration, and code parity.

Exit condition: the decision record identifies a pilot structure and the evidence supporting it.

Gate 3: Build the representative pilot

• Use the same governed component identity and explicit size in both density contexts.
• Demonstrate customer-facing and information-heavy scenarios.
• Include local table/list control where proposed.
• Include the constrained/non-participating component.
• Do not combine density with light/dark into Cartesian-product modes.

Exit condition: the prototype demonstrates the intended inheritance, local-control, and non-participation boundaries.

Gate 4: Validate

• Measure visible information gained.
• Test task completion and error behavior.
• Test target overlap and pointer accuracy.
• Test keyboard and focus behavior.
• Test long content, truncation, and localization.
• Test 200% text resize and 400% zoom/reflow.
• Review touch/coarse-pointer behavior separately from visual compactness.
• Identify unresolved hard-coded dimensions.

Exit condition: evidence supports or rejects the proposed property mappings and constraints.

Gate 5: Establish Figma/code parity

• Define one semantic source for generated or mapped variables.
• Define code activation through an approved provider, attribute, class, or equivalent.
• Align explicit size vocabulary across Figma and code.
• Add visual-regression coverage for color × density × size × state.
• Publish Figma guidance for inherited mode discovery and sanctioned overrides.
• Record component/variant counts before and after the pilot.

Exit condition: the pilot can be maintained consistently in design and code.

Expansion decision

Only after the gates are complete should the team decide whether to:

• publish standard and compact
• revise or reject the hybrid structure
• add broader component participation
• consider spacious or extraCompact
• expose density as product configuration, user preference, automatic policy, or a combination