Skip the handoff

I have lived this problem more than once. I would design and prototype something in Figma, it would ship, and months later we would need to update it. By then the file was not accurate anymore. I had two options: spend real time bringing it back in line with what had actually shipped, or move on to the next feature. Time constraints being what they are, I usually picked the second one. Later, someone would open that file to reference it, the prototype would not match the real product, and it threw the frontend developers off. More than once. I could not really blame them for it.

This is not really a Figma problem. It happens to any design or prototyping tool that lives outside the actual codebase, which in my case has always been a GitHub repo. The specific tool does not matter. What matters is whether it stays in sync with the one place the real product actually lives, and that kind of syncing takes time nobody consistently has.

If you are a product designer today, my honest suggestion is this: install Claude Code, or something like it, and pull your own copy of the repository your company already ships from.

Then create a branch. Not a Figma file. A branch, the same way an engineer would, for the concept you are exploring. There is no shortage of these. Start a new one for every direction, the same way you already do with Figma files, except now each one is a working version of the actual product, not a picture of it.

This changes what you spend your time on. You are not building a prototype that someone else has to translate later. You are working with real components, real data, and real behavior. If it works when you try it, it works, the same way it will work for a user. That is the whole test.

It also changes what happens when your branch and the real product drift apart, which they will, because other people are shipping too. You can ask your AI to merge the latest version of the main branch into yours and tell you what changed. You find out immediately if something you built now conflicts with what has shipped since, and you can fix it yourself, in the same session, instead of discovering it three weeks later in a handoff meeting.

A lot of what used to require a meeting stops requiring one. Not all of it. Real conversations about direction, tradeoffs, and priorities still matter, and I am not suggesting AI replaces judgment. But a large share of the traditional back and forth was really just translation: explaining what a screen was supposed to do so someone else could rebuild it correctly. When you can just show the working thing instead of describing it, most of that translation disappears, along with the misunderstandings it used to cause.

The same applies to context you would normally have needed a meeting to get. If your team already uses Slack, or records meetings, most of that can be connected to whatever AI system you are using. You can ask it what was discussed in a specific thread, or what came out of a call you missed, and act on the answer directly instead of waiting for someone to summarize it for you.

None of this requires permission from anyone. You do not need your company to adopt a new tool or change its process. You need a laptop, access to the repository your team already works from, and a willingness to work one layer closer to the real thing than most designers are used to.

None of this is new, either. Other companies already work this way, some further along than I am.

The learning curve is smaller than it looks. The field you already know, product thinking, hierarchy, flow, what a user needs first, is still the hard part, and it is still yours. The tool just stops getting in the way of proving it.