Context
Between November 2024 and May 2025, I initiated and led a design system consolidation as Head of Product Design. The core team included two senior designers and a design system engineer. Multiple product teams with their own designers, developers, product managers, and QA were involved.
Starting point
ClimatePartner operated several software products. Each product team built its user interface independently. This produced inconsistent interfaces across products, duplicated development work, and no shared standard for how things should look or behave.
No documentation, no version control, no defined process, no regular review cadence — and no owner. Design and engineering worked in parallel rather than together. Developers referenced generic framework documentation instead of a shared system. Designers used the existing component library selectively. Teams created their own solutions without coordination.
One developer summarised the dynamic: "I don't have time to go to DS and create a new component."
These problems reinforced each other. Without governance, inconsistencies grew. Without shared components, teams built their own. Without synchronisation between design tools and production code, design decisions did not reach the product. The result was a system that could not scale with the organisation.
Approach
Process Audit (October 2024). A structured audit examined roles, workflows, tools, documentation, and adoption across three participants. It confirmed the absence of governance, documentation, version control, and synchronised workflows.
Roadmap definition. A five-phase roadmap was developed: from analysis and inventory through harmonisation, training, monitoring, to scaling.
Component analysis. Figma Design System Analytics and Omlet were used to map actual component usage in both design files and production code. The Material UI Sync Plugin was evaluated for synchronisation between design and code.
Architecture and governance. A target architecture was defined: central design library, tokenised components, unified theme, synchronisation tooling, documentation, and monitoring. A governance model assigned responsibilities across designers, developers, the design system engineer, product managers, QA, and team leads.
Phase 1 (analysis) and Phase 2 (harmonisation) were initiated. Phases 3–5 were conceived and documented but not completed within the project period.
Decisions
MUI retained as technical foundation. The team evaluated building a custom design system from scratch versus building on MUI. A custom system would offer full control and a unique visual identity but required resources the organisation did not have. MUI provided established accessibility standards, a large developer community, and faster development. The trade-off: design flexibility was constrained by the Material Design paradigm, and overrides would require close coordination with engineering.
Cleaning over rebuilding. The decision was made to restructure the existing Figma file rather than start from scratch. This preserved existing work and reduced transition risk but proved more labour-intensive than anticipated.
Scope included process, not just artefacts. The initiative addressed governance, workflows, and adoption — not only components and tokens. This expanded the scope beyond what was formally expected of a design system project, but the audit had shown that artefacts without process would not stick.
Results
Delivered: Process audit with documented findings (evidence: high). Five-phase roadmap (evidence: high). Component usage analysis across Figma and code (evidence: high). Target architecture and governance model (evidence: high). Central MUI theme initiated (evidence: medium — in progress). Central Figma library restructuring initiated (evidence: medium — in progress).
In progress at project end: Token definition, training rollout, monitoring setup, and full synchronisation between Figma and code.
Not achieved: Measurable KPI outcomes (e.g., reduction in development time, reduction in UI bugs). No post-implementation data is available. User feedback or adoption surveys were not conducted within the documented period.
The deliverables established a structural foundation. Whether they translated into measurable efficiency gains or quality improvements cannot be determined from available evidence.
Learnings
Cleaning a historically grown design system was more complex than anticipated. Components that had been copied, modified independently, or named inconsistently created hidden dependencies. In hindsight, a parallel build with gradual migration might have been more efficient than in-place refactoring.
Token-based workflows required a larger shift in team habits than expected. Assumptions about the team's familiarity with design tokens needed explicit validation. Training should have started earlier, not after the architecture was defined.
The bidirectional relationship between design and engineering was the harder problem. Synchronising artefacts is a tooling challenge. Synchronising workflows is an organisational one. The governance model addressed this in theory; whether it held in practice is not documented.
Adoption cannot be mandated through structure alone. Without visible, immediate benefits for individual team members, process compliance remains fragile. The developer's statement about not having time for the design system was not a resource problem — it was a prioritisation signal that the system had not yet demonstrated its value.