The gap gets smaller when you build both sides

I still started in Figma

AI hasn't made me want to skip design.

Quite the opposite.

I started in Figma because I wanted somewhere cheap to make decisions: hierarchy, density, type, what the row is, what Remove actually does, and what absolutely should not live in a confirm dialog.

I wasn't trying to design every possible screen before touching code.

I was trying to establish the grammar of the control.

• What does a member look like in the system?
• What does revoked look like?
• What deserves interruption?
• What should happen without asking?
• What can you still undo?

That gave me enough of a visual and behavioural language to start building.

Then I stopped designing the picture.

The picture needed a system underneath it

The handoff used to be the line.

Design finished here. Engineering started there.

For this build, the line was deliberately blurry.

Before asking Claude to write much of anything, I worked out the shape underneath the interface: the entities, relationships, states and rules the UI would eventually have to represent.

Member
  └── Seat
       └── Access
            ├── Role
            ├── Revoke
            ├── Undo window
            └── Commit

That little diagram matters more than quite a lot of pixels.

Because once Access can become Revoked, and revoke has a consequence, a window, and a commit you cannot rewind, the interface stops being a collection of frames.

It becomes a view onto a system.

That's the first impact. You stop decorating screens and start designing consequences. Remove isn't red because it looks important. It's a window because the person on the other side of it still has a job to do. Undo isn't a toast. It has to restore the seat.

Then Claude became part of the loop

I used Claude heavily during the build.

Not as a make app button.

More like an extremely fast engineering partner with no objection to me changing my mind every eleven minutes.

I'd give it the intent, architecture, constraints and existing code. It could help scaffold the row, reason through motion, find boring TypeScript problems and get me from an interaction in my head to something I could actually touch.

Then I'd use the working thing to design again.

Figma
   ↓
Product model
   ↓
Architecture
   ↓
Claude
   ↓
Working software
   ↓
"Oh. That's wrong."
   ↓
Design again

That last bit is doing quite a lot of work.

The impact of a loop that fast is not that you produce more screens. It's that wrong arrives while you still have the nerve, and the time, to change it. Minutes, not meetings. No deck to defend. No week of implementation sunk into a composition that was never going to survive a thumb on Remove.

The browser pushed back

A static design is extraordinarily polite.

It sits exactly where you left it.

Software is less accommodating.

Press Remove and the row has to leave, say what just happened, and mean it. Leave undo as a badge and you realise it was supposed to bring her back. Leave the name as “Member name” and the object stays a wireframe pretending to be a decision.

Those moments changed the design.

Not because I'd failed to design it properly in Figma, but because the component had started answering back.

That's the bit I've become slightly addicted to.

The picture cannot tell you that eight seconds is long enough to notice a mistake and short enough to feel like a door. The working row can. Once you've felt that, going back to arguing about frames starts to feel like describing a meal instead of tasting it.

The stack was ordinary. The movement wasn't.

The final thing wasn't particularly exotic, which was intentional.

• Figma for the initial product language and interaction thinking
• Next.js + React + TypeScript for the component
• CSS for the surface
• Motion for the swap, the countdown, and reduced motion
• Claude throughout the engineering loop

The interesting technology wasn't any one item on that list.

It was the speed at which I could move between them.

A spacing decision in Figma could become a token. A product rule could become a state machine. A state machine could expose a bad interaction. That interaction could send me back to the design.

Minutes, not meetings.

Faster engineering made the decisions louder

This is probably the bit worth saying.

Claude made me dramatically faster at producing code.

It did not decide what the component should be.

It didn't know that Remove should undo, not confirm. It didn't care that the copy should say what Maya loses, not that a row disappeared. It didn't decide that committed needs an empty well, not a toast.

Those are product decisions.

If anything, faster engineering gives me less excuse not to sweat them.

When implementation becomes cheaper, the quality of the decisions becomes more visible.

That's the actual impact. Not that I can produce a settings-shaped thing. That I can no longer hide a vague idea behind a beautiful file, or a weak interaction behind "engineering will figure it out." The loop will expose it before lunch.

Somewhere in the middle

I've spent a lot of my career around the supposed gap between design and engineering.

I'm increasingly unconvinced the interesting place is either side of it.

For me, it's the bit in the middle.

Design enough to know what you're trying to make. Understand enough engineering to give it a sensible shape. Use tools like Claude to collapse the expensive bits. Get a real component into the browser as quickly as possible.

Then look at the real thing.

Argue with it.

Change it.

The gap between design and engineering gets considerably smaller when you're willing to work on both sides of it.