Worked Answer: Enterprise Design System

Prompt

Design a frontend architecture for an enterprise design system used by multiple product teams, brands, and accessibility-sensitive workflows.

Clarify

Ask:

• How many apps and teams consume it?
• Is multi-brand or white-label required?
• Which components are highest-risk?
• What accessibility standard and verification process apply?
• How are breaking changes shipped?
• What migration support exists?

Architecture overview

Package strategy

Package	Owns
tokens	semantic design decisions and theme mappings
primitives	behavior, keyboard, ARIA, state machines
components	styled accessible components
recipes	recommended compositions for common workflows
product wrappers	domain-specific data and naming

API principles

• component APIs expose product intent, not CSS internals
• accessibility behavior is enforced through API and tests
• async/loading/error/disabled/invalid states are first-class
• product-specific behavior lives in wrappers
• breaking changes include migration path

Governance

Concern	Control
adoption	scorecard by app/team
contribution	triage process and API review
accessibility	component contracts and manual checks
versioning	semver, migration guides, codemods where possible
exceptions	owner, reason, expiry, replacement path

Failure modes

Failure	Prevention
teams fork components	missing pattern triage and recipes
tokens become raw brand aliases	semantic taxonomy review
dialog focus regresses	primitive keyboard/focus fixtures
migration stalls	codemods, office hours, deprecation window
GenUI produces invalid combinations	registry-safe schemas

Strong close

I would launch the platform around a few high-leverage primitives, not a huge visual catalog. Success is measured by adoption, reduced forks, fewer accessibility regressions, faster migrations, and product teams choosing the design system because it makes correct work easier.