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.