Work with me
All writing

Design systems

Why your Figma file and code drift apart in production, and how to fix it

Design systems usually look fine at launch. The trouble starts afterwards, when the Figma file and the live product slowly stop matching. Users only ever see the live product, so every gap between the two is a gap your users feel, even if nobody on the team can say exactly where it came from.

Written by
Gideon Awolesi
Published
Reading time
7 min read

What drift looks like

Right now, if you open the Figma file of a product that's been live for a year and put it next to the production app, you'll usually find the same thing. The buttons look almost the same, but the padding is off by a few pixels. There are three shades of grey in the code where Figma has one. A component has a variant in production that was never designed, because a developer needed it on a Friday and there wasn't time to ask.

None of these is a big problem on its own. Together, they mean designers are designing for a product that doesn't exist anymore, and developers stop trusting the file. Once that happens, people stop checking the file before they build, and the drift speeds up.

Why it happens

  1. Hotfixes go straight into code: A bug gets fixed in production, and nobody updates the component in Figma. Do that a few dozen times and the two have diverged.
  2. Values are hard-coded instead of tokenised: If a colour or a spacing value is typed in by hand in the code instead of coming from a token, it can't follow the design system when the system changes.
  3. Names don't match: Figma calls it Button / Primary / Large, and the code calls it CTAButton with size="lg". When the names don't match, nobody can tell which one is the source of truth.
  4. The system has no owner: When the design system is everyone's side project, it slowly drifts, because keeping the file and the code in step isn't anyone's job.
  5. AI coding agents make new components: When you ask a coding agent to build a screen and it can't find the right component, it'll happily write a new one, and every component it writes is one more thing that's out of step with Figma.

How to spot it

Start with an inventory. List every component in Figma and every component in the code, and match them up. The ones that only exist on one side are your first findings. Then look for untokenised values: colours, spacing, and type sizes in the code that don't come from a token. Finally, compare the variants of your five most-used components, because that's where most of the drift lives.

This doesn't have to take long. In my experience, a day with the file and the repository open side by side is usually enough to see how far things have drifted, and where.

How to fix it

  1. Make tokens the single source of truth: Define colours, spacing, and type as tokens in Figma variables, and export them to the code, so a change in one place reaches both.
  2. Give components the same names on both sides: If a designer and a developer can't say the same name for the same thing, they can't keep it in step. Rename the side that's wrong.
  3. Connect each Figma component to its code: Link the Figma component to the real code component, so designers see what actually ships and developers can find the source in one click.
  4. Add a check to code review: Ask one question in every pull request that touches the UI: does this use an existing component and existing tokens? If not, it needs a reason.
  5. Make your coding agent a user of the system: Point the agent at your component names and your documentation, so it reaches for what exists before it writes something new.
  6. Give the system an owner: Someone has to be responsible for keeping the file and the code in step. It can be a few hours a week, as long as it's clearly one person's responsibility.

What this looked like at Syndigo

So at Syndigo, the product teams were working from a fragmented enterprise design system. I consolidated more than 70 components into one governed library, connected the design side to the production code, and set up the workflow around the UI Relay Figma plugin, so the library and the code had a way to stay in step after the project was finished.

What I took from that project is that drift usually comes from how designers and developers hand work to each other, so that's the part you have to change.

Where to start this week

Pick your five most-used components and compare them in Figma and in production. Wherever they don't match is where to start, and the number of differences will tell you if it's a job for an afternoon or for a proper audit.

AI-Ready Design System Audit

Want a second pair of eyes on your product?

If your Figma file and your product have drifted apart, I can audit both and give you a fix plan in three weeks, from €4,500. If you'd rather start small, send me one AI flow for a free review.