Design to code: why I take my designs into the build

Years ago I was designing animations for the iOS app at one of Australia’s big banks. We’d made beautiful demos in motion design software. The developer was trying to recreate them in Swift, and it was never right. The timing was off, then the scale, then the feel.

So I learned Swift. I animated the thing by hand, in code, to show the exact timing and behaviour. The engineer could see it running and replicated it in the build.

That’s one of the few times in my career the handover went well. In 20+ years, at basically every company I’ve worked at, going from design to build has been one of the biggest barriers to a great product. It’s also where a lot of the clashes and frustration came from. Some teams expected everything redlined. On others, engineers took liberties with the design. A smooth process was rare.

That frustration is fading. I can now show how every design should function, feel and behave, in something as good as the finished build. So that’s how I work.

Why do designs get lost between Figma and the build?

A Figma file is a picture of a product. A product is behaviour: what happens when you tap, how long it takes, what shows up when the network drops.

Every handover asks an engineer to turn the picture into behaviour. They fill the gaps with their best guess, usually late in a sprint. Each guess is reasonable. Added up, they make a different product from the one that was approved.

AI coding tools have made this sharper. A team can build a screen in an afternoon now, so the file falls behind the product within weeks. After that the code is the truth and the design is a memory.

What does a product design engineer do?

A product design engineer designs the product and builds the interface in code. For me that runs in three steps, and each one leaves your engineers with something they can use that day.

Discover and define. I work out what to build and how it fits together. Flows, priorities and the few things people come to do, tested quickly before anyone writes production code.

Design. High-fidelity design with interaction prototypes that show how the product moves and responds. Your engineers see the timing, the states and the edge cases on a real screen, so there’s nothing left to guess from a static frame.

Deliver. Components in code, in your stack, with a Figma library that matches. I’ll do front-end where it moves things faster. The heavy engineering stays with your team.

Whether my code ends up in your codebase matters less than you’d think. Some engineers pull the components straight in. Others rebuild them their own way. Both work, because they can see exactly how it should behave and match it with precision.

It’s how I’m working on YouSpot right now, a new product I’m designing with Dharmesh Shah, co-founder of HubSpot. My team and I build the interactive prototypes in code, so everyone can see how each flow behaves before it’s built for real.

I still work in Figma. Some decisions are quicker there, and some teams live there. I use whichever one gets you to a decision sooner.

How do Figma and the code stay in sync?

One system, kept in both places. The same token names and values sit in the Figma variables and in your codebase. Each Figma component points to its coded version, so nobody hunts for the right one. A change gets made once and checked in both.

It’s also what your AI tools need. An agent asked to build a screen uses whatever system it can read. If there isn’t one, it makes one up, and it makes up a new one each time. I’ve written more about that under agentic systems.

Which states does nobody design?

The ones after the happy path. Rushed sprints and AI tools both design the screen where everything works.

Take an action card for an AI agent. It needs a state for waiting on approval, one for running, one for failing halfway and one for done. That’s four designs for one component, and most files hold one.

I design and build all four, and they match across the prototype, the file and the code.

<ActionCard
  state="needs-approval"
  title="Send 3 follow-up emails"
  detail="To the leads from Tuesday's demo."
  onApprove={approve}
  onEdit={edit}
/>

<ActionCard
  state="running"
  title="Sending 2 of 3"
  detail="You can stop at any time."
  onStop={stop}
/>

<ActionCard
  state="failed"
  title="1 email didn't send"
  detail="The address bounced. The other 2 went out."
  onRetry={retry}
  onSkip={skip}
/>

<ActionCard
  state="done"
  title="3 emails sent"
  detail="Replies will show up in your inbox."
  onView={view}
/>

Do you have to start from scratch?

No. Most teams I work with already have a product.

I audit the Figma files and the live build, and find every button, colour and pattern in use. Duplicates get merged and the strongest version stays. Then the result goes into Figma and your code, linked, so the team builds from it straight away.

Check your own product

• Open your live product next to the Figma file. Do they match?
• Pick one component. Can you find its loading, empty and error states in the file?
• Change your primary colour. How many places do you have to touch?
• Ask two engineers where they get a button from. Do you get the same answer?

Work with me

If your product never quite matches the designs, this is the work I do. See design engineering or get in touch.

FAQ

What is design to code? Design to code is the step where an approved design becomes a working interface. It usually happens through a handover file, and it’s where most of the detail gets lost.

Why doesn’t our product match the designs? A static file can’t show behaviour. Timing, states and edge cases get decided during the build, usually under deadline and without the designer in the room.

Do designers need to code? Not every designer, but someone has to own the gap between the file and the build. I’d rather it was the person who made the design decisions.

Can AI tools replace the design handover? AI tools build faster, but they build from whatever system they can read. Without a design system in code, you get a slightly different screen every time you ask.

Who does product design engineering for funded teams? Halaska is the product design practice of Chris Halaska, based in Dubai. I design AI and crypto products for funded teams as an ongoing partner, in Figma or in code, after leading product design at Google and Immutable.