Design System Alignment

Restoring design and development alignment to improve consistency and delivery efficiency.

Project summary

Led the restoration and adoption of a unified design system after design and engineering tools fell out of sync. Rebuilt the implemented component library in Figma, re established a shared source of truth, and introduced processes that improved consistency, development accuracy, and cross team efficiency.

Overview

As Cinch scaled, design and development environments drifted apart. Designers were working in a Figma library that did not match the components used in production, while engineers relied on a separate implementation. There was no reliable shared source of truth. This disconnect created inconsistencies between design and shipped UI, increased handoff friction, extended QA cycles, and caused avoidable rework. The work supported a broader organisational goal of improving delivery efficiency as product squads scaled.

The problem

Without alignment between design tools and implementation, teams were repeatedly solving the same problems. Components behaved differently across squads, design decisions were harder to validate, and engineering time was spent reconciling visual differences instead of building new value. Confidence in the design system also declined, making adoption harder over time.

Project summary

Led the restoration and adoption of a unified design system after design and engineering tools fell out of sync. Rebuilt the implemented component library in Figma, re established a shared source of truth, and introduced processes that improved consistency, development accuracy, and cross team efficiency.

Overview

As Cinch scaled, design and development environments drifted apart. Designers were working in a Figma library that did not match the components used in production, while engineers relied on a separate implementation. There was no reliable shared source of truth. This disconnect created inconsistencies between design and shipped UI, increased handoff friction, extended QA cycles, and caused avoidable rework. The work supported a broader organisational goal of improving delivery efficiency as product squads scaled.

The problem

Without alignment between design tools and implementation, teams were repeatedly solving the same problems. Components behaved differently across squads, design decisions were harder to validate, and engineering time was spent reconciling visual differences instead of building new value. Confidence in the design system also declined, making adoption harder over time.

Foundational elements, including color and naming, differed between Figma and the web.

My role

Alongside another senior designer, I helped re establish design system ownership while continuing product squad responsibilities. We acted as a design operations working group responsible for restoring system stability and making it practical for day to day use.

My responsibilities included:

  • Auditing gaps between design assets and implemented components

  • Rebuilding a reliable component library in Figma based on production UI

  • Aligning designers and engineers around a shared source of truth

  • Onboarding teams to the refreshed system

  • Creating feedback loops to support ongoing evolution

I acted as a bridge between design and engineering, translating system constraints and needs across both groups.

An archived Storybook helped shape alignment with components in Figma.

Approach

Identifying the root cause

The issue was not a lack of components but a tooling and alignment problem. Designers and engineers were working from different references, creating delivery friction. We focused on restoring alignment and trust before expanding the system further.

Rebuilding a shared source of truth

I located an archived Storybook repository containing the components used in production. This became the foundation for rebuilding the system in Figma.

Starting with foundations such as colour, typography, and spacing, I reconstructed core components so the design library accurately reflected real implementation. We deliberately focused on alignment with live components rather than future facing redesigns to restore trust and stability first. This reduced risk, improved predictability for engineering, and made adoption easier for product squads.

Approach

Identifying the root cause

The issue was not a lack of components but a tooling and alignment problem. Designers and engineers were working from different references, creating delivery friction. We focused on restoring alignment and trust before expanding the system further.

Rebuilding a shared source of truth

I located an archived Storybook repository containing the components used in production. This became the foundation for rebuilding the system in Figma.

Starting with foundations such as colour, typography, and spacing, I reconstructed core components so the design library accurately reflected real implementation. We deliberately focused on alignment with live components rather than future facing redesigns to restore trust and stability first. This reduced risk, improved predictability for engineering, and made adoption easier for product squads.

I defined color, spacing, and typography first, then built core components.

Driving adoption through practical rollout

Rather than releasing everything at once, we introduced the system in stages. Designers were onboarded through real product work and I partnered directly with engineers to validate component behaviour during implementation.

Some designers preferred pushing a new visual direction. I worked to align the group around operational stability as the immediate priority, with evolution planned once the foundation was reliable.

Establishing feedback and iteration

We tracked usage and gathered feedback to understand how components were being applied across squads and where gaps remained. This helped the system evolve based on real product needs rather than assumptions.

Driving adoption through practical rollout

Rather than releasing everything at once, we introduced the system in stages. Designers were onboarded through real product work and I partnered directly with engineers to validate component behaviour during implementation.

Some designers preferred pushing a new visual direction. I worked to align the group around operational stability as the immediate priority, with evolution planned once the foundation was reliable.

Establishing feedback and iteration

We tracked usage and gathered feedback to understand how components were being applied across squads and where gaps remained. This helped the system evolve based on real product needs rather than assumptions.

I set up tasks for the design team to evaluate how easily they adapted to the Design System changes, while capturing feedback throughout the process.

Outcome

Design and engineering began working from the same reference, reducing ambiguity during handoff and making component behaviour more predictable.

Teams experienced fewer UI clarification loops during implementation, and the library became the default starting point for new product work across multiple squads. Confidence in the system improved, and repeated component level decisions reduced as teams reused shared patterns rather than recreating them.

Visual QA issues caused by mismatches between design and implementation were reduced by 35% based on internal QA reporting trends, helping streamline release cycles and reduce rework across squads.

Key learnings

  • A design system’s value depends on alignment with real implementation, not just visual polish

  • Stability and trust are often more important than introducing new patterns

  • Adoption comes from integration into daily workflows, not just documentation

What I would do next

With alignment restored, the next step would be evolving the system into a more fully documented and versioned resource. This would include clearer usage guidelines, component rationale, and templates for common patterns. The foundation now enables a structured roadmap toward tokenisation, documentation, and governance.


Outcome

Design and engineering began working from the same reference, reducing ambiguity during handoff and making component behaviour more predictable.

Teams experienced fewer UI clarification loops during implementation, and the library became the default starting point for new product work across multiple squads. Confidence in the system improved, and repeated component level decisions reduced as teams reused shared patterns rather than recreating them.

Visual QA issues caused by mismatches between design and implementation were reduced by 35% based on internal QA reporting trends, helping streamline release cycles and reduce rework across squads.

Key learnings

  • A design system’s value depends on alignment with real implementation, not just visual polish

  • Stability and trust are often more important than introducing new patterns

  • Adoption comes from integration into daily workflows, not just documentation

What I would do next

With alignment restored, the next step would be evolving the system into a more fully documented and versioned resource. This would include clearer usage guidelines, component rationale, and templates for common patterns. The foundation now enables a structured roadmap toward tokenisation, documentation, and governance.


Examples of newly rebuilt components in Figma.

Usage of the new design system was monitored to evaluate adoption across the design team.

After establishing the foundations, focus could then shift to usage guidelines and scaling the design system.

Other projects

Luxury Platform Launch

Launching a premium car buying experience within platform constraints and brand expectations.

Product Page Optimisation

Improving purchase intent through clearer hierarchy, stronger decision cues, and experimentation.

EV Experience Optimisation

Reducing EV buyer uncertainty through clearer information, contextual education, and structure.

Lorenzo Rodia

Open to new opportunities and always happy to chat.

hello@lorenzorodia.com

Lorenzo Rodia

Open to new opportunities and always happy to chat.

hello@lorenzorodia.com

Lorenzo Rodia

Open to new opportunities and always happy to chat.

hello@lorenzorodia.com