Naresh Shan Logo

Service

Program Management for Design Systems

Program Management for Design Systems

Governing scalable component architecture. Coordinating cross-team adoption and delivery cadence.

What This Means

Most design systems stall because they're treated as component libraries rather than products. I run them as managed programmes with governance models, adoption strategies, versioning policies, and delivery cadences that keep pace with organisational growth instead of creating technical debt.

How I Approach It

  • Establish governance that balances centralised consistency with team-level autonomy over implementation
  • Define contribution models that let teams extend the system without fragmenting it
  • Build adoption roadmaps prioritising high-impact components, with usage metrics tracked across products
  • Coordinate cross-functional delivery so design, engineering, and product stay aligned on system priorities
  • Implement versioning and deprecation policies that prevent breaking changes while allowing controlled evolution
  • Set up review gates and quality thresholds that catch drift before it compounds

Common Challenges

  • Teams treat the design system as optional, building custom components instead of adopting shared ones
  • No clear ownership model, so the system degrades as priorities shift
  • Engineering and design operate on different release cadences, creating sync gaps in component delivery
  • Legacy products can't easily migrate to new system versions without dedicated transition planning
  • Contribution processes are either too rigid (killing adoption) or too loose (fragmenting the system)
  • Measuring adoption and impact is difficult without instrumentation baked into the workflow

When You Need This

  • Your design system exists but adoption is inconsistent across teams
  • Components are built in isolation with no cross-team coordination
  • You're scaling rapidly and the system isn't keeping pace
  • Multiple product teams are duplicating patterns, increasing maintenance overhead
  • Ownership, governance, or delivery structure is unclear or absent

Expected Outcomes

  • A governed design system with defined ownership, contribution guidelines, and adoption metrics
  • Reduced duplication across product teams, lowering maintenance costs and technical debt
  • Faster product delivery through reusable, well-documented components
  • Cross-team alignment on design standards and delivery priorities
  • A system that evolves sustainably without requiring periodic rewrites

What I Bring To This

At Johnson Controls, I directed 39 designers across regions delivering into a shared design system for the OpenBlue platform. I built the governance model, established contribution workflows, and coordinated delivery cadence across product teams operating in 17+ countries. The result was an 85% reduction in operational costs and 90% improvement in user satisfaction through standardised, reusable components.

At SwissRe, I architected the design system from scratch and led change adoption across a 14-member EMEA team. I implemented structured review gates that eliminated 47% of UI bugs and 70% of design defects, while reducing support tickets by 30%. The system became the foundation for cross-team collaboration and accelerated component delivery across product lines.

I hold PRINCE2 Agile and PMI-ACP certifications, and I apply programme management discipline to design system delivery. This isn't design system advocacy. It's operational infrastructure.