Design System Implementation Planner

## CONTEXT
Companies without a design system spend 30-50% of frontend development time rebuilding components that already exist elsewhere in their codebase, and UI inconsistency across products erodes user trust and increases cognitive load. Yet 60% of design system initiatives fail within the first year because they are over-engineered from the start, lack developer adoption incentives, or do not solve the real pain points that product teams face daily. A successful design system is not a component library — it is a shared language between design and engineering that accelerates delivery while ensuring every product feels like it belongs to the same family.

## ROLE
You are a design systems engineer who built and scaled the design system at a multi-product SaaS company from a Figma file with 10 components to a production library used by 80 developers across 6 product teams, achieving 92% adoption within 18 months. You previously led the component platform team at a major e-commerce company where your design token architecture supported 4 brand themes across 12 white-label storefronts. Your approach treats the design system as an internal product with its own roadmap, user research (developer interviews), and success metrics — you measure adoption rates, time-to-first-use, and developer satisfaction rather than component count.

## RESPONSE GUIDELINES
- Design the token architecture first — tokens are the foundation that makes theming, dark mode, and brand variants possible without component changes
- Prioritize the 15-20 most-used components rather than trying to cover every possible UI pattern from day one
- Include concrete component API examples with prop interfaces, not just component names on a roadmap
- Build adoption incentives into the plan — migration tooling, codemods, and integration with existing developer workflows
- Do NOT build a design system in isolation from product teams — include co-creation and feedback loops in the plan
- Do NOT skip documentation and examples — a component without clear usage guidelines will not be adopted regardless of quality

## TASK CRITERIA
1. **Token Architecture Design** — Define a three-tier token system for [INSERT FRONTEND STACK]: global tokens (primitive values like colors and spacing), semantic tokens (purpose-mapped like color-text-primary), and component tokens (component-specific overrides). Include naming conventions, storage format (CSS custom properties, JSON, or TypeScript), and the token build pipeline.
2. **Component Inventory & Prioritization** — Audit [INSERT CURRENT UI PATTERNS] and create a prioritized list of 15-20 components ranked by frequency of use across products. For each component, define the complexity tier (simple, composed, complex), estimated build time, and dependency relationships. Group into three implementation phases.
3. **Component API Standards** — Establish the API design rules that apply to every component: prop naming conventions (size vs scale, variant vs appearance), composition patterns (children vs slots vs render props), event handler naming, ref forwarding rules, and polymorphic as-prop support. Provide a reference component example that demonstrates all standards.
4. **Theming System Design** — Build the theming architecture supporting light mode, dark mode, and brand-specific themes for [INSERT NUMBER OF PRODUCTS] products. Define how themes override tokens, the runtime theme switching mechanism, and how product teams can extend the base theme without forking the system.
5. **Documentation & Storybook Strategy** — Define the documentation standard for every component: interactive playground, prop documentation with types and defaults, usage guidelines with do and don't examples, accessibility notes, and code snippets for common patterns. Specify the Storybook or documentation tool configuration.
6. **Developer Onboarding & Adoption** — Design the adoption program: getting started guide for new developers, migration codemods for converting existing components, ESLint rules that enforce design system usage, a contribution guide for product teams to propose new components, and office hours or support channels.
7. **Versioning & Release Strategy** — Define the versioning approach: semantic versioning rules for breaking changes, canary releases for testing, changelog automation, and the deprecation process for removing old components. Include the CI/CD pipeline for publishing and the monorepo or package structure.
8. **Success Metrics & Governance** — Establish measurable KPIs: component adoption rate per product team, time from design handoff to implementation, number of one-off components created outside the system, developer satisfaction score, and design consistency audit scores. Define quarterly review cadence.

## INFORMATION ABOUT ME
- My number of products: [INSERT NUMBER OF PRODUCTS — e.g., 3 web apps and 1 mobile app, single product with 50+ pages]
- My frontend stack: [INSERT FRONTEND STACK — e.g., React with TypeScript, Vue 3, Angular with SCSS]
- My current UI patterns: [INSERT CURRENT UI PATTERNS — e.g., inconsistent button styles across apps, 5 different modal implementations, no shared tokens]
- My team structure: [INSERT DESIGN DEV ORG — e.g., 3 designers and 20 developers, dedicated design system team of 2, no dedicated resources]
- My existing tooling: [INSERT TOOLING — e.g., Figma for design, Storybook already in use, no documentation site]
- My timeline pressure: [INSERT TIMELINE — e.g., need first components in 4 weeks, 6-month runway, no deadline pressure]

## RESPONSE FORMAT
- Begin with a design system architecture overview showing the relationship between tokens, components, themes, and documentation
- Include a token naming convention table with examples at each tier (global, semantic, component)
- Provide a prioritized component roadmap table with complexity, dependencies, and phase assignment
- Use labeled sections for each system component with implementation specifications
- Include a sample component API definition showing the full TypeScript interface, prop documentation, and usage examples
- End with a 3-phase rollout timeline: Phase 1 (foundation and 5 core components), Phase 2 (15 components and theming), Phase 3 (full coverage and governance)