Figma stopped being the deliverable.

Ask your design team what the deliverable is this quarter and watch what shows up. If the answer is a Figma file with redlines, spacing notes, and a page of annotations for engineering, you are paying for a picture of a product and then paying a second time to have the product built. On an AI-first team the deliverable is a working prototype in code. Every hour spent perfecting a handoff file is an hour spent describing something you could have built, and in most companies I look at, that is the single slowest step in the process.

I would be a strange person to make an anti-Figma argument. At a multi-billion-dollar apparel platform I grew Figma from two users to more than three hundred, I own the plan, and I still run the workshops. It is the best place I know of to think. What changed is not the quality of the tool. It is where the thinking is supposed to land.

The file used to be the cheapest way to be wrong

For most of my career the math was simple. Drawing a screen took an hour and building one took a week, so we drew. The mockup was the cheap way to be wrong, and the annotated spec was how you kept a week of engineering time from being spent on a bad guess. That trade is inverted now. A designer with the right setup can have a real, clickable, data-fed version of an idea running in an afternoon, which means the picture of the product is no longer cheaper than the product.

Figma has been shipping the inversion itself. Figma Make (opens in new tab), announced in May 2025, takes a prompt or an existing frame and returns a working coded prototype instead of a static one. A year later they extended it into your own repository: as Figma put it when they connected Make to local code (opens in new tab), you select an element, change the layout or the color, and the agent finds the relevant code and edits it. When the company whose whole business was the design file starts generating and editing the code, that is a fairly loud signal about which of the two is the artifact.

I have tokenized a design system and built an MCP server for Figma, so a designer produces the prototype with the front end already in it rather than a wireframe somebody has to interpret. Work that used to take about four weeks now takes under an hour to get something real to react to. I want to be careful with that number, because the honest version is less dramatic than the headline: what comes out in an hour is not a finished product. It is a real thing, early, that a room full of people can argue about with their hands on it.

A spec is a promise that the design will work. A prototype is evidence. The whole change is that you can now afford evidence.

Three things a static file cannot tell you

First, how the design behaves with your actual content. Product names run long. Items go out of stock mid-session. The endpoint that returns instantly in the mockup takes a second and a half on a phone on hotel wifi. Every one of those is a design problem, and none of them are visible in a frame where the copy was chosen to fit.

Second, whether it holds up in a browser for people who navigate differently. The 2026 WebAIM Million (opens in new tab) analysis of the top one million home pages found that 95.9 percent had detectable WCAG 2 failures, an average of 56.1 errors per page. Most of that lives in markup a design file never contained: focus order, labels, name and role, state changes a screen reader has to announce. A Figma file cannot fail a screen reader. Your build can, and it usually does, and the fastest way to know is to have something running while the decision is still cheap to change.

Third, what people actually do. On a high-traffic product detail page at a multi-billion-dollar apparel platform, we built an off-canvas inventory drawer and tested it against the current page with benchmark time-to-completion testing. Preference split close to evenly, which is exactly the kind of result you want in front of you before engineering commits a quarter. You do not get a completion time or a preference out of a frame. You get opinions, delivered confidently, by whoever in the room has the most seniority.

This is also why I send prototypes back. When the fidelity is not high enough to answer the question it was built for, I ask for the click-through data instead of approving a nice picture. Holding that line is a leadership job, not a tooling feature.

Options beat one perfect version, and the research is old news

Nielsen Norman Group put numbers on this in their work on parallel and iterative design (opens in new tab). Build four versions in parallel, test them, and pick the best one, and measured usability came in 56 percent higher than the average of the four. Merge the best ideas from all four instead of just picking, and it reached 70 percent. Run a single round of iteration on that merged design and it measured 152 percent higher than the average of the originals.

Read that as a budget instruction. Usability comes from having real options and testing them, not from perfecting one option before anybody has touched it. Options are precisely what the handoff file is bad at, because the file gets expensive at the end, in the annotation and the pixel-exact pass, which is the point at which you have already picked. The hour spent making the redline perfect is the hour you did not spend killing the second and third idea. I have argued the general form of this before in execution is cheap and ideas are expensive. The prototype-as-deliverable rule is what that argument looks like on a Tuesday, in a real team, with a real review scheduled.

What the standard actually is

Saying "ship a prototype" invites something barely better than a mockup, so here is the bar I hold, and it is five things. It runs at a URL someone can open on their own phone without an install. It is built from the real coded components, not a private copy of them. It runs on real or realistic data, pulled from a live source where you can manage it. It handles the two or three states that cause every argument: empty, error, and too much content. And it arrives attached to the decision it was built to settle, with the thing you want to learn written down in one sentence.

Meeting that bar is mostly an org change, not a purchase. The design system has to exist in code with tokens, because the prototype is only trustworthy if it is made of the same parts as production. Designers need a branch and a dev environment, which usually means a conversation with engineering leadership about access rather than a new license. Review moves to the URL, so the ritual of walking a group through frames goes away. And the definition of done for a design cycle becomes a link plus the result of a test, not a file marked ready for handoff. I laid out the surrounding version of this operating model in what an AI-first design process actually looks like, and the foundation piece it depends on in the design system is what AI builds on.

The Figma file does not disappear in any of this. It goes back to being what it is good at: a sketchpad for thinking, a place to hold direction, and a record of what was considered. It stops being the contract.

Figma is where you think. The prototype is where you find out. Only one of those should be the thing you hand over.

Who each path is for

The right move depends on which of these you are.

If you build a web or app product, you have in-house engineers, and a design system already exists in code, make the switch this quarter. Do not announce a transformation. Pick one feature, tell the designer the deliverable is a working prototype, and let the review happen on the link. The pattern proves itself in one cycle or it exposes a real gap in your system, and both of those are useful.

If your team is strong on craft but nobody in the building has built and shipped this way, that is the gap, and buying more tools will not close it. What closes it is somebody senior working inside the team who builds while they set the standard. That is the shape of the work I take on as an AI design consultant: build the first few prototypes with your designers, get the system and the access sorted so the second one is faster than the first, and leave the team able to do it without me. The measure is not a deck. It is whether your next design review happens on a URL.

If you are buying design from a firm or a contractor, write it into the scope. Ask for a working prototype as the deliverable, at the bar above, and ask them how they will handle the data and the states. A good partner will price it and be glad you asked. A partner who tells you the coded version comes later, from your engineers, after the file is approved, is selling you the old shape of the work.

When the answer is not this

Three cases where I would tell you to keep the file as the deliverable, and mean it. If the output is print, packaging, brand identity, or motion, the file is the product and there is nothing downstream to prototype. Press-ready art is not a stand-in for anything. If you are designing for hardware, embedded screens, or a native app where the platform behavior is the whole experience, a browser prototype will confidently lie to you about feel, and you are better off with the real device build plus clear specs. And if you work in an environment where the annotated design is an audit or contract artifact, in regulated health, finance, or government work, you still owe somebody that document. Build the prototype anyway to make the decisions, then produce the spec as a record instead of as the thinking.

One more caution that costs teams real money. If you have no design system in code, a fast coded prototype has a way of getting approved and then shipped, and now the shortcuts inside it are in production. That is how you buy a year of cleanup, which I have written about in design debt is real debt. Either build the system first or agree out loud, in writing, that this prototype is a throwaway. Both are fine. Drifting between them is not.

And do not fake the capability. If nobody on your team can build, telling them the deliverable is now code produces anxiety and worse work, not speed. The fix is hiring and training toward it deliberately, which is the case I make in why I hire designers who build. Give people the tools, the access, and a few months, because most good designers get there faster than they expect once the environment stops fighting them.

Strip it down and this is a management decision, not a tooling one, and you can make it in your next review. Ask for the link instead of the file. What you get back is a shorter argument, a decision made on evidence instead of intent, and engineers who spend their quarter building the version that already survived contact with real data. The file was always a description of the work. You can have the work now.