This week, I tried something I have been curious about for a while: What happens when I skip the Figma handoff and design directly in the prototype?
For context, my team is building a vision prototype for Yahoo Games. One of the features we are exploring is leaderboards, and I wanted to test whether I could build that experience directly in Claude Code without creating a full Figma design first.
Not because Figma is bad. Not because design systems do not matter. But because the thing I care about most has always been the space between design and engineering. I like turning fuzzy ideas into something a team can react to, test, critique, and build from. And right now, AI coding tools are making that space feel a lot more interesting.
It worked. It was also messy.
The leaderboard work was not happening in a perfectly clean setup.
I was building inside a vision prototype branch that had started as something quick and scrappy. Meanwhile, engineering had already started setting up the leaderboard infrastructure in a different branch, including data patterns and a more production minded foundation.
So we had two things happening at once:
A prototype branch moving fast to support vision work.
An engineering branch trying to establish a stronger foundation.
Those branches were not really talking to each other yet, which created friction. Some decisions were being explored in one place. Some work was happening in another. And the prototype itself had grown beyond its original purpose because leadership wanted to keep building it out.
So this was not a perfect "future workflow" test. It was more like learning inside the current messy reality. Which, honestly, might have made it more useful.
The prototype became the handoff
The biggest win was that the prototype gave engineering something real to work from. Not a static file. Not a set of frames. A live URL.
At one point during our review, engineering summed it up in four words:
"Way easier than Figma."
That felt like the biggest validation of the experiment.
Not because Figma failed, but because the prototype removed a layer of translation. Instead of interpreting static mockups, engineering could inspect the experience directly in the browser, check styles in DevTools, see animations, interact with real states, and understand the intended behavior without recreating it mentally first.
That is the kind of design artifact I want more of. Something that does not just describe the experience, but behaves like the experience.
States were easier to understand
One of the most useful things we built was a small state panel that let anyone switch between different leaderboard states instantly.
Instead of hunting through code or imagining edge cases from static screens, you could simply click a button and see the UI change. That changed the conversation. We stopped talking about what the design might do and started talking about what it actually did.
A Figma prototype can absolutely communicate flow and interaction. But a code prototype has a different kind of realism. It shows responsiveness, motion, data, and behavior in the same medium where the product will eventually live. That does not replace design judgment. It simply gives everyone a shared artifact that's closer to reality.
The messy parts taught us what the workflow needs next
The prototype was useful, but it also exposed some real problems. The main page file had grown to around 8,000 lines, with inline styles and repeated UI for different layouts. That made it harder to navigate and harder for AI to reason through the code.
Some of the prototype code had also drifted from production, creating confusion about which version represented the latest thinking.
Ironically, those problems were valuable. They showed us exactly what our workflow was missing.
We realized prototypes need structure too. Features should become reusable components. Existing production components should be reused whenever possible. Design system tokens should come from a shared source instead of being recreated. The experiment was successful because it exposed those gaps early.
The work started changing the team process
The most exciting part was not just that the leaderboard worked. It was that the experiment created momentum. Afterward, engineering started documenting what made the workflow successful and where it broke down. That led to new Claude skills for starting prototypes and handing them off, along with rules around component structure and design token usage.
We're also documenting how Storybook, GitHub, Figma, and our design system fit together so future vision work can move from exploration to implementation much more smoothly.
That is the part I keep thinking about. The prototype did not just communicate a design. It helped us design a better workflow.
So, am I done with Figma?
During a retrospective this week, we did a Start, Stop, Continue exercise.
Under Stop, I wrote: Stop using Figma. I know. Hot take.
And I do not actually mean "never use Figma again." Figma is still incredibly valuable for visual exploration, documentation, and design systems. What I want to stop is treating it as the default starting point for every feature. For experiences that depend on interaction, state, animation, and engineering constraints, sometimes the better artifact is something much closer to the real product.
Sometimes the prototype is the design.
What I'm learning
People often talk about AI tools like they make everything faster. Sometimes they do. But they also ask designers to learn entirely new skills while still doing their day jobs.
Over the past few months I've learned more about branches, components, design tokens, code structure, and engineering workflows than I ever expected to.
It honestly feels like doing a coding bootcamp in real time while shipping product. That's hard. But it's also the most energized I've felt about design in a long time. Because I don't think the future is designers becoming engineers or engineers becoming designers.
I think the future is creating better shared spaces between us.
This experiment reminded me that sometimes the most valuable thing a designer can build isn't a mockup. It's a better way for the team to work together.