Design System
What kind of design-system decision are you making?
A design system is not one large document. It is a short authority chain in which each fact has one owner:
reader job and design intent
→ portable design memory
→ tokens and component language
→ runtime implementation
→ rendered proof
→ improved design memory
The Spine
- AI Design.md File — encode intent, references, constraints, and proof for humans and AI.
- Design Language — choose tokens, component boundaries, composition, and exceptions.
- Forest and Mycelium Diagrams — show visible promises, shared capability, and the evidence-bearing connections between them.
- Tailwind v4 Tokens — configure runtime token roles.
- Tailwind v4 Monorepo — share Tailwind configuration across packages.
- How to Audit a Page — verify rendering, hierarchy, responsiveness, interaction, and access.
- Product Design — look up measurable design thresholds.
Zoom Out
Use UX Design when the question is broader than design-system authority. Use Purpose when the reader, beneficiary, or valuable change is not yet clear.
Context
- depends-on UX Design
- applies-to AI Design.md File
- pairs-with Design Language
- uses Forest and Mycelium Diagrams
- uses How to Audit a Page
- uses Tight Five
Questions
Which source rightfully owns the decision being made?
- Is this intent, runtime configuration, component behavior, or observed proof?
- Which other sources should link to the owner instead of restating it?
- Changes my mind: two independently maintained owners prove more reliable and easier to retrieve than one authority plus links.
- Next question: which duplicated design fact should be replaced by a link?