I stopped sending Figma files

Two weeks into a redesign you send a Figma link. The founder clicks through, nods, and says it looks great. Six weeks later the build arrives, it does not feel like the thing anyone approved, and nobody can point to where it went wrong.

It went wrong at the link.

A mockup is a picture of a product

Ask someone to approve a photograph of a car and they will tell you about the colour. They cannot tell you about the steering, because a photograph has none.

That is the position a static frame puts every reviewer in. They are being asked to sign off on something they can only imagine using. So they review the part they can actually see, which is the surface, and the parts that decide whether the product is any good stay unreviewed until a developer has already built them.

Those parts are not small:

• What happens between two states, and how long it takes
• Whether a list is usable once it has four hundred rows in it
• What the screen does while it is waiting for the network
• Whether a control that looks obvious is actually reachable with one thumb
• What the whole thing feels like when you use it quickly instead of carefully

None of that survives the trip into a flat frame. All of it shows up in QA, which is the most expensive place to find it.

What a working prototype changes

I now build the screen as working HTML, with AI coding tools, in roughly the time it used to take me to make the same screen pretty in Figma.

That one change moves four things.

Review stops being imagination. A stakeholder opens the thing and uses it. The feedback changes character immediately. "Can we make the card bigger" turns into "I cannot tell which of these two is selected", which is a far more useful sentence.

Developers build from behaviour, not description. Motion is the clearest case. Writing "the panel eases in" in a spec means every developer guesses a different curve. Handing over a panel that already eases means nobody guesses.

Interaction bugs surface in design. The DABs coordination board I designed at VisiLean is a real application: a file tree of construction models, zones and locations drawn onto a 2D plan. Half the design decisions in it only became visible once I could click. A flat frame would have hidden every one of them until somebody had built it.

Approved starts meaning something. When the artefact behaves, agreement on it is agreement about the product rather than about a picture of it.

What deliberately did not change

This is the part I want to be precise about, because the interesting claim is not the one people expect.

Research did not change. Flows did not change. Talking to the people who will use the thing did not change. The argument for why a design is right did not change, and neither did the work of having that argument with people who disagree.

AI did not replace any of that thinking. It replaced the medium the thinking gets delivered in. That is a smaller claim than the industry is currently making and it is the one I can actually defend.

A designer who skips the research and generates a beautiful working screen has built a faster way to ship the wrong product.

What this is not

It is not production code, and it should not pretend to be.

The prototype is throwaway on purpose. It cuts corners a real build cannot: hard-coded data, no error handling worth the name, no tests, one browser. Its job is to answer design questions and then be deleted. Treating it as a head start on engineering is how you end up shipping a prototype, which is worse than shipping a mockup.

You also still need a design system. Working HTML with no tokens behind it is just a faster way to produce inconsistency.

When a flat mockup is still right

A prototype is not free, and it is the wrong tool more often than the people selling AI workflows admit.

Reach for a static frame when:

• The question is purely visual. Brand direction, a poster, an illustration.
• You are exploring twenty options. Breadth beats depth, and twenty prototypes is a waste of two weeks.
• The screen genuinely has no interaction. Some do not.
• The decision is about content and hierarchy, not behaviour.

The rule I use: if the disagreement is about how something looks, a frame settles it. If the disagreement is about how something works, only a prototype settles it, and arguing over a frame will just take longer to reach the same answer.

What to ask before you hire anyone for this

If you are hiring a designer and this way of working matters to you, the questions that actually separate people are not about tools.

1. Ask to use something, not to see something. A link you can click tells you more in thirty seconds than a portfolio does in ten minutes.
2. Ask what they would do differently. Anyone who has shipped has a real answer. Anyone who has only presented does not.
3. Ask what the prototype is missing. A good answer is specific and slightly uncomfortable. "Nothing" means they have not shipped one.
4. Ask how they decided, not what they decided. Tools change every year. The decisions are the durable part.

You can click through the coordination board and the rest of the work, or read the field studies where this way of working came from.