Figma to React with one shared model behind both.
Figma and React do different jobs. The problem begins when they encode different decisions and the team has to guess which one is right.
A shared model
The goal is a shared model. The same foundations, names, patterns, and states stay recognisable in both places.
That makes the work easier to review. A design decision can be traced into code, and an implementation constraint can change the design while staying part of the system.
Signs you need this
Handoff has a meeting attached to it. An engineer opens a file and asks which of three similar components is the current one. A design change lands in code as a near miss, and nobody can tell whether the difference was a decision or an accident. The Figma library carries a version number and the code carries a different one.
Often the same screen exists twice: once as a frame that was signed off, and once as the thing that shipped a month later, with no record of what changed in between.
The tell is a simple question with no cheap answer: which of these two is right? Once that is hard to settle, the two sides have stopped being views of one system and become two systems that resemble each other.
Where the bridge usually breaks
The most expensive gaps sit under the surface.
- Tokens named for how they look
- Components whose variants drift from real product states
- Screens designed as single happy paths
- Responsive and loading behaviour left to inference
How Nordlean works
We build Figma and React as two views of the same system, beginning with the few foundations and patterns that recur through the product. The handoff becomes a shared workflow that runs the whole way through.
What you get
Two views of one model, and the working habits that keep them that way.
- One set of foundations, named the same way in both places
- Components whose variants map to real product states rather than to visual options
- Documented behaviour for responsive, loading, empty, and error states
- A working React and StyleX system, with the rules made explicit enough to survive the next feature cycle
- A review habit: a change is proposed once and lands in both views
The point is not that the two stay identical. Figma will always show intent more cheaply, and React will always know things about the runtime that a frame cannot. The point is that where they differ, the difference is a decision somebody made rather than a gap nobody noticed.
What we need from you
The current library and the current code, and someone on each side who can settle a disagreement.
- The Figma library, including the components people have stopped using
- The front-end code, and whatever wrapper layer has grown around it
- An active feature to migrate first, so the model proves itself under real work
- A designer and an engineer who can agree on a name and make it stick
Nothing needs rebuilding before we start. What is in use tells us more than what was intended, and the components people quietly abandoned are usually the clearest evidence of where the model was wrong.
Naming is the slow part of this work. It is also the part that decides whether the model still holds a year from now. A name that only makes sense to the person who chose it will be quietly worked around, and the model starts drifting again from there.
Questions
Should Figma and React be identical?
No. Figma shows intent more cheaply, and React knows things about the runtime that a frame cannot. Where the two differ, the difference should be a decision somebody made rather than a gap nobody noticed.
Where do these projects usually break?
Under the surface. Tokens named for how they look, component variants that drift from real product states, screens designed as single happy paths, and responsive and loading behaviour left to inference.
Do we need to tidy the Figma library first?
No. What is in use tells us more than what was intended, and the components people quietly abandoned are usually the clearest evidence of where the model was wrong.
What does handoff become?
A shared workflow that runs the whole way through. A design decision can be traced into code, and an implementation constraint can change the design while staying part of the system.
Related guides
Make the next part of the product easier to build.
Bring the thing your team is repeatedly working around. We will work out whether a system intervention is the right move.
Let's chat ↗