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
Establish governance that balances centralised consistency with team-level autonomy over implementation
Define contribution models
Define contribution models that let teams extend the system without fragmenting it
Build adoption roadmaps
Build adoption roadmaps prioritising high-impact components, with usage metrics tracked across products
Coordinate cross-functional delivery
Coordinate cross-functional delivery so design, engineering, and product stay aligned on system priorities
Version and deprecate safely
Implement versioning and deprecation policies that prevent breaking changes while allowing controlled evolution
Catch drift early
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 a 28% 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.