workshop-guide

Density architecture workshop guide

Purpose

Use this working session to agree on the decisions to investigate, assign the PDS audit, and select the architecture structures to prototype. Do not use the session to invent compact values without component evidence.

Suggested participants

• design-system product designer
• design-system engineer
• Figma library owner
• accessibility partner
• representatives from customer-facing and information-heavy products
• content/localization partner when typography participation is in scope

Preparation

Participants should review:

• Decision brief
• Cross-system comparison
• Current PDS proposal
• Relevant practitioner token views

Bring examples of current PDS components in both customer-facing and information-heavy product contexts. Bring native Figma variable and binding exports if available.

Working sequence

1. Align on the problem

• Which workflows are currently too dense or not dense enough?
• What outcome is required: information visibility, task efficiency, touch comfort, visual tone, or another measurable need?
• Which needs are density, and which belong to typography, responsive layout, content strategy, or component size?

Output: agreed problem statement and product scenarios.

2. Review research guardrails

• One governed component can support different geometry.
• Density should not redefine raw foundations.
• Component size, density, and modality require explicit separation.
• Global inheritance and local control require a mixing policy.

Output: accepted guardrails and disputed assumptions requiring evidence.

3. Compare architecture structures

Complete the working table in architecture-options.md. Compare at least the shared semantic collection, component-specific collection, and explicit-controls-only structures.

Output: structures to prototype and evaluation criteria.

4. Scope the component audit

Assign owners and priority components using component-metric-inventory.md.

Output: audit owners, source locations, and completion criteria.

5. Define pilot boundaries

• Which components participate?
• Which component represents a constrained or non-participating case?
• Which product scenarios and modalities must be demonstrated?
• Which accessibility and localization checks are required?

Output: bounded pilot plan.

6. Record decisions

Use decision-record.md. Mark each item as proposed, accepted, rejected, or blocked by evidence.

Output: decision record, unresolved questions, owners, and review date.

Facilitation rules

• Keep external-system evidence separate from PDS decisions.
• Record unknown where the Figma or code graph is unavailable.
• Do not choose values because another system uses them.
• Treat commerce and enterprise as scenarios or defaults, not density-mode names.
• Capture dissent and invalidation conditions, not only consensus.