01 / Design notes
Your Figma File Is Not the Source of Truth Anymore
I know. That one stings a bit.
For years, Figma was gospel. Every screen, every state, every interaction, refined until it was flawless, then passed to development and rebuilt from the ground up in code.
Two files. Two versions. Two chances for them to fall out of sync. And the distance between what was designed and what actually shipped? We treated it as inevitable. Just part of the process. Something designers grumble about in retros and then quietly work around.
But what if the source of truth was never meant to be a static file? What if it was the working product itself?
The old way ran on translation
Look at what actually happens in a typical handoff. A designer figures out the UX, then translates it into visuals in Figma. A developer then interprets those visuals and rebuilds them in code, filling in the edge cases, states, and interactions a flat canvas was never able to capture. Every step in that chain is a translation, and every translation loses a little something along the way.
The result is a quiet, ongoing tax on every product team. The design file says one thing, the live product says another, and nobody's fully sure which one to trust. In practice, whatever's live wins by default, which tells you the design file was never really the source of truth. It just played the part.
How I approach it these days
I start with the UX, working through it with AI as a thinking partner. By the time I open a design tool, I already know what belongs on each screen and why, because the user journeys have already worked that out. Every interaction, every bit of information someone needs at each step, gets mapped there. That's where the real decisions happen, well before any pixels show up.
Once the journeys feel right, I define the design philosophy: the principles, tone, and constraints I want to hold to. Then I prompt AI to design a journey or two against that, and I test whether the patterns genuinely work for my users. Not whether they look polished. Whether they actually hold up.
I'm not designing every screen in Figma anymore. Just enough to point things in the right direction. From there, I build a working design system straight into the codebase. That's what becomes the source of truth, not the design file.
Everything else takes shape in code from there, guided by the user journeys, because once the journey is right, the interface is just that journey made visible through the right structure and interaction patterns. This is where AI genuinely shines: not doing the thinking for you, but speeding up the leap from good thinking to a working interface.
No gap left to close
The prototype is the design. The design is the prototype.
There's no second version sitting around waiting to be reverse-engineered from a flat file. No guessing which states were actually designed and which were just assumed. No moment where a developer has to figure out what an empty form field or a zero-item list should look like, because the "design" only ever covered the happy path. The working version is the spec, simply because it's the only version there is.
Figma still matters. It's just not the centre of gravity.
To be clear, I still reach for Figma. It's a great tool for ideation: quick, visual, low-risk, ideal for testing a direction before committing to it. What's shifted is its role. It used to be the endpoint, the final, definitive artefact everything else had to match. Now it's just one stop along the way. Something I use when it's useful, not where the "real" design actually lives.
The centre of gravity has shifted, from a static file standing in for the product, to the product itself. Once you've worked this way, going back to designing everything on a flat canvas and hoping the build lines up feels a bit like describing a novel to someone else and asking them to write it for you.