This wasn't the plan. It's just what happened.

Somewhere in the last six months, my design process flipped. I opened Claude Code more than Figma. I built more prototypes than I made frames. And the strange part is - the work got better.

I want to explain what changed, because I think it says something about where design is heading. Not as a prediction. As an observation from someone who's been designing products for over a decade and suddenly found himself working differently.

The shift started with a permissions flow.

I was designing a role-based access system. In @figma, it looked clean. Clear steps, logical progression, everything fit nicely into frames and arrows. I was ready to hand it off.

Then I decided to build a rough prototype first - just to feel how it worked. I used @claude Code with basic state handling. Nothing production-ready. Just enough to click through.

Within minutes, problems surfaced.

Too many hidden states that weren't visible in static screens. Edge cases where users could land in "valid but confusing" states. Labels that made sense visually but became ambiguous once they appeared dynamically in different contexts.

The biggest issue wasn't visual. It was cognitive. Users had to remember what changed after each action. The system state wasn't obvious unless you experienced it live.

None of this was visible in Figma. The flow "looked done." The prototype felt broken.

What I changed after building

I didn't redesign the screens. I redesigned the logic.

I removed steps instead of adding explanations. I renamed concepts so they stayed consistent across states. I reordered actions based on how the system actually behaved, not how the flow diagram suggested it should.

The final solution was less elegant visually. Fewer screens. Simpler states. But far clearer when used.

That project changed how I thought about the role of prototypes. The prototype wasn't for validation. It was how I discovered the design.

Why building reveals what static frames hide

There's a category of design decisions that only become visible when something runs.

State transitions. What happens between screens. How data populates. What breaks when inputs are unexpected. How error states cascade. Whether a loading state feels fast or slow.

Figma can approximate these. But approximation isn't experience.

When I build - even roughly - I notice friction I couldn't see before. I feel where the product hesitates. I catch assumptions I didn't know I was making.

This isn't about pixel-perfect prototypes. It's about having something real enough to react to.

The tools that made this possible

A few years ago, building a working prototype required either engineering support or serious coding skills. That's no longer true.

Tools like Claude Code, Cursor, and Lovable have collapsed the gap between describing what you want and seeing it work. You're not learning a programming language. You're having a conversation and iterating on running software.

I describe a flow. The tool builds it. I react. I critique. I describe what's wrong. It rebuilds. The cycle is fast enough that building becomes part of thinking, not a separate phase after thinking is done.

This changes the economics of exploration. I can throw away a bad prototype and start over in an hour. I can test three different approaches in a day. The cost of being wrong early dropped to nearly zero.

This isn't "designers should code"

I want to be clear about what I'm not saying.

I'm not saying designers need to learn programming. I'm not saying Figma is obsolete. I'm not saying everyone should work the way I work.

What I am saying is: the gap between design intent and working software is shrinking. Fast. And designers who stay only in static tools will have blind spots they don't know they have.

The question isn't whether you should code. The question is whether you're willing to engage with your designs after they become real - and let that reality change your decisions.

The new shape of senior design work

I've been a product designer for eleven years. For most of that time, the progression was clear: get better at Figma, learn to navigate stakeholders, develop systems thinking, level up your visual craft.

Those things still matter. But something else matters now too.

The designers I find most impressive aren't just good at designing. They're good at reacting. They build something rough, see what's wrong, and fix it. They treat prototypes as thinking tools, not deliverables. They move fluidly between intent and implementation.

This is where judgment lives. Not in the mockup. In the moment when something runs and you have to decide: is this right? What's off? What should change?

AI tools like Claude Code make building cheap. They don't make judgment cheap. If anything, they amplify the gap between designers who have strong foundations and those who don't. Because now there's more output to evaluate. More decisions to make. More surface area for taste to matter.

What I've learned

A few things have become clear to me over the last six months:

Static artifacts show intent. Running software shows what you missed. No amount of annotation or documentation replaces the experience of using something.

Reacting is faster than imagining. A blank canvas has infinite possibilities, which sounds like freedom but is actually friction. A rough prototype is already wrong in specific ways - and specific problems are easier to solve.

Design is becoming more like editing. AI gives me a first draft that's too much. My job is to find what matters and remove the rest.

Figma is now my finishing tool. I used to start every project there. Now I start in Claude Code or Lovable. By the time I get to Figma, the hard decisions are made. It's where I polish, not where I think.

Where this is heading

I don't know exactly what design workflows will look like in five years. But I'm confident about one thing: the designers who thrive will be the ones who engage with their work after it becomes real.

Not because building is mandatory. But because some questions only get answered when software actually runs. And those questions - about state, about flow, about what happens when things go wrong - are often the ones that matter most.

The tools are changing. The judgment isn't.

That's still the job.

If you're thinking about how building fits into your design process, I'd be curious to hear what's working - or not working - for you.