Design System Component Adjacency Matrix
Map which components compose together (and which conflict). Export to PowerPoint for the design-system audit.
UX teams running a design-system audit periodically need to answer a question that's harder than it sounds: which of our components compose with which? A button is used inside a form, a dropdown is triggered by a button, a tooltip and a toast both occupy the same z-index space and need careful coordination. Some compositions are required (buttons inside forms — primary adjacency); some are common-but-not-required (cards with action buttons — secondary); some are explicit anti-patterns (tooltip inside a modal — undesired, focus-trap and z-index conflicts). A design-system component adjacency matrix captures all of that systematically in one slide for the design-system team's next review.
This tool gives UX designers a fast way to build that matrix without leaving the browser. The Design-System Components template comes pre-loaded with a representative set (Button, Input, Form, Modal, Dropdown, Tooltip, Tab, Toast, Card) and a sensible default adjacency pattern based on common composition rules — adapt it to your own design system's components and conventions. Click cells to mark each pair's relationship; the matrix updates live as you go, and your work auto-saves between sessions.
The Pro PowerPoint export is the killer feature for design-system documentation: every cell becomes a real PowerPoint shape, so the audit lives as an editable artifact in your team's deck — recolor a row when a new variant ships, relabel a column when a component is renamed, copy the matrix to another slide for the quarterly review. Compared to maintaining a static Confluence table or a manually-curated Figma frame, the matrix's structure forces a deliberate decision for every component pair and surfaces gaps you'd otherwise miss. For coupling analysis at the service level (rather than component level), see the microservices coupling matrix variant, or browse the full Adjacency Matrix Diagram tool for all use cases.
Related variants
Same tool, configured for a related use case.
Frequently asked questions
What goes in a design system component adjacency matrix?
One row + one column per component in your design system. Each cell records whether two components are commonly composed together (primary), occasionally combined (secondary), or in an anti-pattern relationship that should be avoided (undesired). Useful examples: Modal ↔ Tooltip is typically undesired (z-index conflicts), Button ↔ Form is always primary (forms always have submit buttons), Button ↔ Tooltip is secondary (helpful but not required).
How big should my design-system matrix be?
Most production design systems have 25-60 components. A matrix of that size becomes visually dense — the recommended approach is to scope the matrix to one component category at a time (forms, overlays, navigation, etc.) and produce one matrix per category. The tool's free tier supports up to 30 items per matrix, and Pro extends to 50.
Can I include design tokens or just components?
Either, but mixing them in one matrix usually muddies the analysis. A token adjacency matrix is its own valuable artifact (which color tokens combine well, which spacing tokens stack correctly), and we'd recommend building a separate matrix for it rather than combining components and tokens in the same view.
Does the editable PowerPoint export work with Figma plugins?
The Pro PowerPoint export produces a real .pptx file with selectable shapes. Figma's PowerPoint-import plugins read these as editable shape groups, so you can drop the exported matrix into a Figma file if your team's documentation lives there. The dedicated Copy SVG button (also Pro) is usually a cleaner path — it pastes directly into Figma as a vector group.
How often should I update the design-system adjacency matrix?
We've seen teams treat it as a living artifact updated alongside their design-system release notes — typically once per quarter, with ad-hoc updates whenever a new component or pattern ships. The auto-save + JSON state-file workflow makes this easy: keep the JSON in your design-system repo so it's versioned alongside the components themselves.