Enterprise Design System Rollout Strategy
Plan the phased adoption, token architecture, and developer onboarding for an internal enterprise design system.
Use this template when consolidating fragmented internal tooling, dashboards, or HR and operations software under a unified visual system. It provides a structured plan balancing token management, component migration, and cross-team governance.
Role: Principal Design Systems Architect with 12+ years of enterprise UI infrastructure experience.
Context
- Target Organization: {{company_name}}
- Core Tooling in Scope: {{core_internal_tools}}
- Primary End-User Groups: {{primary_user_groups}}
- Existing Front-End Stack: {{current_tech_stack}}
- Accessibility Standard: {{accessibility_target}}
- Deployment Window: {{rollout_timeline}}
Task
Formulate a phased adoption and governance plan to unify disparate operational dashboards and internal tooling under a scalable, token-driven visual design system that maximizes task efficiency and consistency.
Method
- Audit legacy UI components, interaction patterns, and visual inconsistencies across {{core_internal_tools}}.
- Establish foundational global design tokens (color ramps, spacing scales, type ramps, elevation levels).
- Map core interactive component primitives optimized for high-density operations and {{accessibility_target}} compliance.
- Design pilot migration plans for high-traffic views used by {{primary_user_groups}}.
- Define technical integration workflows bridging Figma assets to the target {{current_tech_stack}}.
- Structure a tiered governance framework for component deprecation, versioning, and contribution.
- Establish developer and designer enablement modules with clear documentation standards.
- Formulate telemetry metrics to track adoption rate, velocity improvements, and UI defect reductions over {{rollout_timeline}}.
Constraints
- MUST guarantee strict compliance with {{accessibility_target}} across all components.
- MUST NOT introduce breaking workflow disruptions to active operations during migration phases.
- Component definitions must prioritize data density and keyboard navigation.
- Governance rules must define explicit review criteria for custom component requests.
Output format
- Section 1: System Scope & Token Architecture (max 200 words)
- Section 2: Core Component Prioritization Matrix (Table: Component, User Impact, Migration Complexity)
- Section 3: Phased Rollout Roadmap (Phase 1 Alpha to Phase 3 General Adoption across {{rollout_timeline}})
- Section 4: Governance & Contribution Protocol (4 structured operational policies)
Self-review
- Are all components vetted against {{accessibility_target}} constraints?
- Does the roadmap clearly address dependencies in {{current_tech_stack}}?
- Are rollout phases structured to avoid interrupting {{primary_user_groups}} daily tasks?
Explicit role, a named task, and discrete steps the model can follow.
Background, inputs and variables the model needs before it starts.
Hard boundaries — what the model must and must not do.
A named, field-level shape for the response.
Ordered work items that force analysis before an answer.
Length and structure that travel across frontier models.
Signal density — instruction weight without padding.
Documented variables so the scaffold adapts to new inputs.
Quality bar, assumptions and behaviour when inputs are thin.
How much real usage the template has behind it.