design-system-governancelisted

# Design System Governance Use when a product needs coherent reusable design decisions, not merely a prettier component library. A design system is an operating model for consistency, accessibility, quality, and product speed. ## Decision Layers Separate: 1. Principles: what the system optimizes for. 2. Patterns: reusable solutions to recurring product problems. 3. Components: reusable interface objects. 4. Content rules: labels, messages, empty states, help, tone. 5. Accessibility rules: keyboard, focus, semantics, contrast, motion, target size, cognitive support. 6. Usage guidance: when to use, when not, examples, anti-patterns. 7. Contribution process: proposal, review, validation, release, retirement. 8. Maturity/adoption: ownership, use, quality proof. Tokens and component APIs can preserve decisions, but they are not the decisions themselves. Record evidence classes: product use cases, accessibility obligations, adoption/drift signals, platform constraints, owner/review proof. ## Common Pattern Families Govern recurring UI patterns as reusable decisions: - forms and validation; - search, filters, sorting, and no-results recovery; - lists, tables, cards, dashboards, and detail pages; - empty, loading, disabled, error, success, and partial-success states; - onboarding, permissions, consent, account setup, and first-run education; - notifications, progress, activity, alerts, and system status; - destructive actions, bulk actions, undo, confirmation, and escalation