Syndigo: Design System and Design-to-Code

Design Process

The audit determined what needed to change and in what order.

1. Audit: I inventoried every component across the products, mapped Figma against production, and flagged every duplicate and inconsistency.
2. Consolidation: I reduced each set of duplicates to one canonical component and documented its anatomy, variants and version history. Design frames also showed whether work was in ideation, in progress or complete, with the relevant ticket attached.
3. Code Connect and Storybook: I authored the Code Connect and component files for more than 70 components. Storybook showed the design and coded component side by side.
4. Repository work: Engineering gave me access to the codebase, where I maintained the component and Code Connect files directly.
5. Coded prototypes: I introduced Figma MCP to turn designs into clickable prototypes before development. I also configured Lovable and Claude Design to use the approved components, so generated work stayed within the system.
6. Accessibility: I built semantic structure, labels and implementation guidance into the component work so accessibility requirements stayed reviewable during design and delivery.

Accessibility

The component work used semantic structure, ARIA roles and clear labels, with representative screen-reader checks and written guidance for teams extending the system. Information did not rely on colour alone. This case study does not claim a universal conformance level.

Impact Metrics

70+ components consolidated into a single, code-connected source of truth.

Syndigo’s first design-to-engineering pipeline, with coded prototypes used to test designs before development.

Product and design teams adopted component-based prototyping through Lovable and Claude Design.

Code-connected components reduced repeated design and frontend work.

Context & Problem Statement

The design system had no structure and little governance. The same component often existed in several inconsistent versions across products, and nothing connected design to shipped code: no Storybook, no code-connected components, and no UX presence in GitHub.

Designers, engineers and product managers interpreted the system differently. Delivery slowed because engineers had to rebuild interface patterns from inconsistent specifications.

Stakeholder Analysis

1. Frontend engineers: Needed components that matched the approved design and could be used in production without another round of interpretation.
2. Product designers: Needed one governed component kit so they could focus on product problems instead of recreating common interface elements.
3. Product managers: Needed to test ideas quickly with prototypes that still matched the real product.

System Audit

I started by checking how teams used the existing system in Figma and production.

1. Component inventory: I catalogued the components in use and identified duplicates.
2. Figma-to-production mapping: I compared the design libraries with shipped interfaces to find where they had diverged.
3. Team interviews: I spoke with designers and engineers about where the system helped and where they had to work around it.
4. UI Relay Figma plugin: I built a Figma plugin that maps components to code, tracks coverage and code health, generates and syncs component code, manages tokens and templates, and flags gaps. It made system maintenance part of the team’s normal workflow.

Challenges and Solutions

Design and code were not connected. I secured repository access and maintained the Code Connect and component files, so approved design decisions could reach production without another interpretation step.

The library was also fragmented. I consolidated duplicate patterns and built the UI Relay plugin to catch drift as new work entered the system.

For adoption, I connected the system to coded prototypes, Lovable and Claude Design. Teams could use their preferred tools without leaving the approved components behind.