Speaking the Same Language

Bridging Design and Development in Figma

TL;DR

I created a Figma library for our new design system — one that was already live in code but didn’t yet exist in design.

By translating our MUI-based component architecture into a thoughtful, scalable Figma library, I helped designers and developers speak the same language from the very beginning. The result? Less friction, faster work, and a stronger foundation for building consistent product UI.

The Opportunity

Our engineering team had already built much of the design system in code, using MUI as a foundation. But the design team didn’t yet have a corresponding Figma library.

This meant:

Designers were re-creating components by eye
Developers couldn’t trust what they saw in Figma
There was no shared language for tokens, components, or behavior

I saw this as a rare chance to build alignment from the start — not by reinventing the system in Figma, but by translating it directly from code.

The Goal

Build a Figma component library that:

Reflects the code system already in place (built on MUI)
Uses the same naming conventions, logic, and behavior
Helps designers work quickly and confidently
Makes implementation easier for developers
Establishes a shared source of truth for both sides

My Role

I led the creation of the Figma library from the ground up.

Defined structure, naming, and organization
Created variables for color, spacing, and typography tokens
Built components with real behavior and states
Collaborated with engineers to ensure alignment with the codebase
Worked with product designers to ensure usability in real workflows

The Process

Starting with Code- Not UI

I didn’t start with old design files or visual explorations. I started with the actual code.

Reviewed our MUI-based component APIs
Studied how props were used (variant, size, disabled, etc.)
Understood what behaviors and edge cases needed to be represented in design

From there, I mapped those elements directly into Figma components.

Naming Like a Developer

Naming wasn’t just for organization — it was for alignment.

Component names mirrored the code (e.g., Button, TextField, Snackbar)
Properties in Figma reflected actual props
States like hover, focused, and disabled were built into variants

This made it easier for devs to trust what they saw — and easier for designers to speak dev when handing off.

Tokenizing for Consistency

I created Figma variables that reflected our design tokens in code:

Colors (e.g. color.primary.500)
Spacing (e.g. spacing.sm)
Typography (e.g. font.body.md)

Variables weren’t just decorative — they were functional building blocks used across the system.

Building Components

I designed each component to be:

Flexible (supporting different content and slot logic)
Reliable (built with real states and behavior)
Aligned (structured and labeled for developers)

The Impact

Creating this library wasn’t just about building components in Figma — it was about creating trust. Designers now had tools they could use confidently, knowing they reflected the actual system. Developers no longer had to translate design intentions or ask what a “primary button” really meant.

The library reduced ambiguity during handoff, minimized one-off design decisions, and gave both sides a shared reference point. Most importantly, it laid the groundwork for a healthier design–engineering relationship, built on clarity and shared language.

What I Learned

This project taught me how powerful a shared language can be — and how much that language starts with naming, structure, and clarity.

I learned that starting from code doesn’t limit design creativity — it enables it. With the constraints of MUI as a guide, I was able to focus on designing components that worked, scaled, and made sense in real product environments.

I also realized that designers and developers often want the same things: predictability, flexibility, and clarity. When a system gives them that, collaboration becomes a lot easier.