I Stopped Designing in Figma First

Mar 19, 2026

For the past decade, my workflow has been the same. Open Figma. Push pixels. Hand off to engineering. Wait. Get something back that doesn't quite match. Repeat.

I'm a product designer at XFA, a cybersecurity startup. I've lived in Figma for years. It's been good to me. But three weeks ago, something shifted, and I don't think I'm going back to the way I worked before.

I started using Claude Code as my design tool.

Not as my coding tool. I want to be clear about that. I don't write code. I still can't tell you the difference between useEffect and useState without Googling it. But I figured out that I don't need to understand code to use it as a design material.

How it started

I was prototyping a compliance dashboard for XFA and got tired of the Figma-to-browser gap. You know the one, where something looks perfect in your design tool but feels completely different once it's running in a real browser. The spacing is off. The scroll behavior is wrong. The hover states don't feel the way you imagined.

So I asked Claude to just... build it. Right there. A live HTML prototype I could see in the browser.

And then I said "make the border radius smaller" and watched it happen in real time. Then "the font weight is too heavy." Then "add a subtle hover animation on those cards." Each time, I'd preview a screenshot, react, and redirect.

Within twenty minutes, I had something that felt more real than anything I'd made in Figma that week.

Show me, then fix it

I developed a rhythm pretty quickly. I don't spec things out upfront anymore. I don't write detailed requirements. I just tell Claude what I'm going for, let it build something, look at the preview, and start directing.

"That's too dense. Give me more breathing room."

"The animation is too fast, make it feel more intentional."

"This whole section needs to feel lighter."

It's like working with a junior designer who can code at the speed of light. They don't always nail it on the first try, and honestly, Claude gets it wrong more than I expected. But I can go through ten visual directions in the time it used to take me to set up auto-layout on a single component.

I ran 68 sessions in three weeks. Took 88 screenshots just to check my work. I wasn't coding. I was designing, just with a different material.

Then I pushed it back to Figma

I built a pipeline where my live prototypes get pushed directly back into Figma through an integration. So now my workflow looks like this:

Describe what I want → Claude builds it live → I preview and refine → it goes to Figma.

I'm designing in code and exporting to Figma. The direction is completely reversed from how most designers work. And the results are better, because I'm designing with real constraints. Real browser behavior, real responsive breakpoints, real animations. Not approximations.

I even set up reusable commands for things I do all the time. One normalizes my spacing. Another polishes the overall feel. Another handles animations. I'm orchestrating design work like a producer in a studio, not a craftsman at a single workstation.

What this isn't

I want to be honest about what this isn't.

I'm not becoming an engineer. I still don't commit much code to production, six commits in three weeks, and most of those were design-related PRs. I'm not building backends or writing APIs. I'm using code as a design medium, the same way I use color and typography. The fact that it happens to be HTML and CSS under the hood is almost irrelevant to me.

This also isn't friction-free. About a fifth of my sessions were just setup: connecting tools, fixing expired tokens, getting the pipeline working. There were moments I wanted to throw my laptop. One time, Claude's conversation memory wiped out an entire design I'd been refining for an hour. Just gone. And the rebuild didn't match what I'd lost.

But even with all that friction, I'm faster. And what I'm producing feels more alive than static mockups ever did.

Why I think this matters

The wall between design and implementation is dissolving. Not because designers need to learn to code. Because the code is learning to listen to designers.

When I say "make this feel lighter," that's a design instruction. And now there's a tool that translates that into actual CSS changes, previews the result, and lets me approve or redirect. It's design with a faster feedback loop.

If you're a designer reading this, you don't need to understand React to try it. You need to be willing to describe what you want, look at what comes back, and have the eye to know what needs to change. That part hasn't changed. It's the same skill it's always been.

I just found a faster material to work with.