Design System

Cross-platform

2022 - 2025

how i

BUILT A DESIGN SYSTEM BEYOND FIGMA

ROLE

Team lead

TEAM COMPOSITION

11 Flutter dev ⸱ 3 designers ⸱ 2 PO

ORGANIZATION

Large company

PRODUCT TYPE

Internal product

In 2022, the company I was working for was acquired by Enphase Energy, the world’s leading solar company. I joined Enphase as a Lead Product Designer.

Shortly after, I started working on a new version of their main app with a small UX team.
The product was moving from React to Flutter, and design needed more structure to scale with it.

That’s where I stepped in.

I introduced the value of a design system through a concrete proof of concept, then led its creation from scratch as a foundation built to last.

How it started

Product Manager
Product Manager
10:18
Before sprint planning — are the designs ready for implementation?
Product Designer
Product Designer
10:19
Yes, mostly. To move fast, some screens were updated directly by editing existing screenshots.
Frontend Developer
Frontend Developer
10:20
That explains the mismatch. The values don’t line up with what we have in code.
Product Manager
Product Manager
10:21
Aren’t we all using the same components?
⚠️1
Frontend Developer
Frontend Developer
10:22
Not really. Each team built what they needed over time. No shared tokens, no common base.
Product Designer
Product Designer
10:23
And on design side, we don’t have a reliable way to know what actually exists in production.
Product Manager
Product Manager
10:24
So when we talk about a “primary action” or a “state”, we’re all picturing something different. That explains a lot...

How it started

Product Manager
Product Manager
10:18
Before sprint planning — are the designs ready for implementation?
Product Designer
Product Designer
10:19
Yes, mostly. To move fast, some screens were updated directly by editing existing screenshots.
Frontend Developer
Frontend Developer
10:20
That explains the mismatch. The values don’t line up with what we have in code.
Product Manager
Product Manager
10:21
Aren’t we all using the same components?
⚠️1
Frontend Developer
Frontend Developer
10:22
Not really. Each team built what they needed over time. No shared tokens, no common base.
Product Designer
Product Designer
10:23
And on design side, we don’t have a reliable way to know what actually exists in production.
Product Manager
Product Manager
10:24
So when we talk about a “primary action” or a “state”, we’re all picturing something different. That explains a lot...

How it started

Product Manager
Product Manager
10:18
Before sprint planning — are the designs ready for implementation?
Product Designer
Product Designer
10:19
Yes, mostly. To move fast, some screens were updated directly by editing existing screenshots.
Frontend Developer
Frontend Developer
10:20
That explains the mismatch. The values don’t line up with what we have in code.
Product Manager
Product Manager
10:21
Aren’t we all using the same components?
⚠️1
Frontend Developer
Frontend Developer
10:22
Not really. Each team built what they needed over time. No shared tokens, no common base.
Product Designer
Product Designer
10:23
And on design side, we don’t have a reliable way to know what actually exists in production.
Product Manager
Product Manager
10:24
So when we talk about a “primary action” or a “state”, we’re all picturing something different. That explains a lot...

How I approached it

Align Figma and Flutter 1:1

Before …

Design and development followed separate logics.

  • Component names differed.

  • Properties changed along the way.

  • A lot got lost in translation.

Handoff meant interpretation.
And interpretation meant drift.

I enforced full alignment.

  • Same names

  • Same logic

  • Same hierarchy

  • Same architecture

… after

Design and engineering shared the same mental model.

Handoff turned into inspection. Consistency held as the system scaled.

And for the first time,
Dev Mode in Figma actually became usable.

Align Figma and Flutter 1:1

Before …

Design and development followed separate logics.

  • Component names differed.

  • Properties changed along the way.

  • A lot got lost in translation.

Handoff meant interpretation.
And interpretation meant drift.

I enforced full alignment.

  • Same names

  • Same logic

  • Same hierarchy

  • Same architecture

Design and engineering shared the same mental model.

Handoff turned into inspection. Consistency held as the system scaled.

And for the first time,
Dev Mode in Figma actually became usable.

… after

Align Figma and Flutter 1:1

Before …

Design and development followed separate logics.

  • Component names differed.

  • Properties changed along the way.

  • A lot got lost in translation.

Handoff meant interpretation.
And interpretation meant drift.

I enforced full alignment.

  • Same names

  • Same logic

  • Same hierarchy

  • Same architecture

Design and engineering shared the same mental model.

Handoff turned into inspection. Consistency held as the system scaled.

And for the first time,
Dev Mode in Figma actually became usable.

… after

Define each component cross-functionally

Before …

Components were added ad hoc.

Logic and design were often duplicated.
There was no shared definition of value or properties.

I made component definition a shared responsibility.

  • Each component went through joint sessions with product, engineering, and design

  • Need, logic, and feasibility were validated together

I also introduced recurring reviews and alignment with the system’s philosophy.

… After

Each component had a clear purpose.
And a shared set of rules.

Redundancy dropped. And contribution stopped being individual work.

It became collaborative by default.

Define each component cross-functionally

Before …

Components were added ad hoc.

Logic and design were often duplicated.
There was no shared definition of value or properties.

I made component definition a shared responsibility.

  • Each component went through joint sessions with product, engineering, and design

  • Need, logic, and feasibility were validated together

I also introduced recurring reviews and alignment with the system’s philosophy.

Each component had a clear purpose.
And a shared set of rules.

Redundancy dropped. And contribution stopped being individual work.

It became collaborative by default.

… After

Define each component cross-functionally

Before …

Components were added ad hoc.

Logic and design were often duplicated.
There was no shared definition of value or properties.

I made component definition a shared responsibility.

  • Each component went through joint sessions with product, engineering, and design

  • Need, logic, and feasibility were validated together

I also introduced recurring reviews and alignment with the system’s philosophy.

Each component had a clear purpose.
And a shared set of rules.

Redundancy dropped. And contribution stopped being individual work.

It became collaborative by default.

… After

Focus on adoption

Before …

Teams were working in silos and without a system mindset.
Components were often treated as detached instances.

It worked short term.

I treated adoption as a product problem.

I trained teams, mainly engineering and design, on design system thinking and mindset.
And set up weekly workshops with designers and developers.

… After

Design and engineering started speaking the same language.

Adoption didn’t spike overnight.
It settled in, gradually.

And it lasted.

Focus on adoption

Before …

Teams were working in silos and without a system mindset.
Components were often treated as detached instances.

It worked short term.

I treated adoption as a product problem.

I trained teams, mainly engineering and design, on design system thinking and mindset.
And set up weekly workshops with designers and developers.

Design and engineering started speaking the same language.

Adoption didn’t spike overnight.
It settled in, gradually.

And it lasted.

… After

Focus on adoption

Before …

Teams were working in silos and without a system mindset.
Components were often treated as detached instances.

It worked short term.

I treated adoption as a product problem.

I trained teams, mainly engineering and design, on design system thinking and mindset.
And set up weekly workshops with designers and developers.

Design and engineering started speaking the same language.

Adoption didn’t spike overnight.
It settled in, gradually.

And it lasted.

… After

What it actually changed

MAJOR IMPACTS

Before

After

Screens designed case by case

Screens assembled from a system

Mockups ≠ final output

Figma / Flutter parity

Decisions driven by individuals

Decisions driven by the system

Screenshots hacked together to communicate

Components as a shared language

Each screen is a one-off

Each screen strengthens the system

Before

After

Screens designed case by case

Screens assembled from a system

Mockups ≠ final output

Figma / Flutter parity

Decisions driven by individuals

Decisions driven by the system

Screenshots hacked together to communicate

Components as a shared language

Each screen is a one-off

Each screen strengthens the system

Before

After

Screens designed case by case

Screens assembled from a system

Mockups ≠ final output

Figma / Flutter parity

Decisions driven by individuals

Decisions driven by the system

Screenshots hacked together to communicate

Components as a shared language

Each screen is a one-off

Each screen strengthens the system

x0

x0

Prototyping speed

x0

x0

Front dev speed

Organizational impacts

The impact showed up first in day-to-day work.

Designers moved faster
With fewer compromises and less rework.

Developers gained autonomy
Less back-and-forth.
Clearer boundaries.
More confidence shipping components on their own.

Product discussions became simpler
Decisions were clearer.
Friction dropped.

But the biggest shift was elsewhere.

The system started replacing subjective debates.
Conversations moved away from “how should we do this?”
And focused on “why does this exist?”

That’s when the system stopped being a tool and became a shared reference.

Retrospective

Looking back, I wouldn’t launch a design system as an abstract initiative.

It needs a real product or technical constraint.
Something teams actively struggle with.

That’s what makes adoption stick.

TL;DR

A UX Platform is born

A single system shared across design, product, and front-end teams

Productivity skyrocketed

Prototyping ×8 · UI Dev ×24

System as truth

Less reliance on individuals, more on the system

TL;DR

A UX Platform is born

A single system shared across design, product, and front-end teams

Productivity skyrocketed

Prototyping ×8 · UI Dev ×24

System as truth

Less reliance on individuals, more on the system