I stopped handing off static mockups

For most of my career, what I handed to engineering was a picture of software. A very detailed picture, with measurements, variations and a clickable prototype that faked the movement between screens.

Engineers then rebuilt it from scratch. We spent the next two weeks discovering everything the picture couldn’t say.

This year I mostly stopped doing that. I still design in Figma. But what I take into reviews and hand over is a working prototype, built with the help of an AI coding assistant like Claude Code or Cursor.

What changes when the prototype is real

The obvious gain is that it behaves like the product. A prototype I built recently for a support tool had real loading screens, real empty screens and a list you could actually filter. Nobody had to imagine the in-between moments, because they were there.

The less obvious gain is in reviews. With a Figma prototype, people comment on how it looks. With a working one, they use it.

A product manager typed a long customer name into a field and watched the layout break. That was a two-minute fix in the prototype. It would have been a bug in the live product.

It also changed how I design. When trying an idea costs a sentence to an assistant rather than an afternoon of linking screens together, I try more ideas. Three versions of a filter panel, compared side by side in the browser at real screen sizes, is now a normal morning.

Agreeing the rules with engineering

I was nervous about this part. Nobody wants a designer dumping unchecked code on the engineering team. So I’m clear about what the prototype is and isn’t.

• It is the reference for how things behave: what each screen shows in each situation, how things move, how layouts adapt to different screens, and the wording.
• It is tidy enough for engineers to reuse parts of, because it follows the team’s design system and naming.
• It isn’t the finished product. It isn’t tested, isn’t connected to real data and makes no promises about speed.

Engineers I’ve worked with this way say the biggest win is that questions come earlier. “What happens when this is empty?” used to come up in week two of the build. Now it comes up in the review, because they’ve already clicked the empty screen themselves.

The fastest way to agree on how something behaves is to build it.

Where it goes wrong

AI tools are quick at making something that looks finished. That’s a trap. A prototype that looks ready to ship gets treated as ready to ship, and the conversation turns to polish instead of whether we’re solving the right problem.

So early on, I keep prototypes deliberately rough. Nobody should mistake a direction for a decision.

The other risk is drifting away from the design system. Left alone, an assistant will invent a new shade of grey every time. I give it the team’s colours, spacing and list of standard parts up front, and I review its work the way I’d review a junior designer’s file.

The takeaway

The deliverable isn’t the picture anymore. It’s the behaviour, and the designer’s job is still deciding what that behaviour should be.