AI product design
The middle moved into code.
Figma is still where we sketch and where we polish. Everything in between is decided in a working build, because that is the only place an AI product’s behaviour exists.
For most of the last decade, the Figma file was the product before there was a product. Every screen, every state, every edge case drawn out and annotated, then handed across to be rebuilt in code. It was the source of truth, and whoever held the file held the decisions.
That is no longer how our work runs. Figma is still open on every designer’s screen at the studio, but at the two ends of a project rather than across the whole of it. It has become two tools: a sketch pad at the start and a scalpel at the end. The middle went somewhere else.
Fig. 01Figma kept the ends. The middle changed lanes.
A sketch pad and a scalpel are different tools.
At the start, Figma is where an idea gets roughed out fast: a few frames, a direction, something to argue about. At the end, it is where a finished screen gets its last cuts. The spacing settled, the type tuned, a component lifted out of the working build, refined and pushed back in. Both are real design work, and both suit a canvas.
What we stopped doing is the long middle: specifying the whole product as pictures, every state of every screen, and treating that file as the thing to approve. That middle is now a working build, made with AI coding agents, and it is where most of the decisions happen.
The middle is where the decisions were.
This is not a niche habit. Across the industry, weekly use of AI for design work went from 54 per cent of designers to 91 per cent in a single year, and about half have already shipped AI-generated code to production. The people answering lean towards those who have embraced AI, so read the numbers as a direction rather than a census. The direction is clear enough.
Fig. 02Designers moved first
Weekly AI use in design work
Have shipped AI-generated code to production
The consequence is easy to miss. If the middle of the process moved into code, then a team that still treats the Figma file as the source of truth is making its decisions in a medium that no longer holds them. The file looks finished. The product it describes has already moved on.
An AI product’s behaviour can’t be drawn.
For conventional software this matters less. A form has a known set of states, and you can draw all of them. A product with a model inside it does not. Its output depends on what the person typed, what it knows about them and what it was given to work with, and the set of things it might say is effectively unbounded.
Take a health assistant. Ask it about an apple and most people are told about fibre. Upload lab results that show diabetes, and the same question becomes a conversation about sugar and when to eat. Neither answer is on any artboard. You can draw the five responses you thought of. The model will produce the five hundred you didn’t, and those are the product.
Fig. 03The product is the space, not the five states
The only way to see that space is to run the thing: real inputs, a real model, real data where you are allowed to use it. Which is why we put a working prototype on the table early, and why, for anything with a model in it, it is the prototype that gets approved rather than the file.
Sketch, validate, polish.
The mistake we see most often is not using Figma. It is the order. A team designs every screen of an AI feature to a high finish, then discovers in testing that the model behaves nothing like the screens assumed, and the finish was spent on a guess. Beautiful products have failed before launch for as long as there have been products. What has changed is that validation is now cheap enough to come first.
So our order is simple. Sketch in Figma until there is a direction worth testing. Validate it in code, with the model running, until it behaves. Then polish in Figma, with the scalpel, the screens that have earned it. Code sits in the middle, where the pictures used to be.
Someone has to own the behaviour.
When the product is a model, a large share of the design lives below the screen. What it does when it is unsure. When it asks a clarifying question, and when it hands over to a person. What it says when it is wrong. Those decisions sit in prompts, in the structure of the tools it can call, and in fallback logic, which is a layer product owners rarely look at and design reviews never see.
We treat that layer as design work and write it down the way we write a design system: rules with their reasons, tested against the model, owned by a named person. The useful thing is to agree who owns it, and where it lives, before an incident decides for you.
Code commits early. Use it carefully.
There is a real cost to working this way. A canvas lets you keep five ideas open at once; code tends to make one of them real, and the first working version has a habit of becoming the version. Speed also shortens the loose, exploratory stretch where designers build judgement, and that stretch is worth protecting on purpose.
The same risk now arrives from the client side. Teams turn up with a vibe-coded prototype of their own, which looks precise and often is not, and the instinct is to treat it as a spec. It is better read as a sketch made of code: valuable for what it says the team wants, not for how it is built.
What to ask for instead.
If you are hiring designers or choosing a studio for an AI product, ask to see something that runs, not a file. Ask who decides how the product behaves when the model is wrong, uncertain or surprised, and whether that decision lives in a document, a ticket or the code. And treat today’s split as today’s. Better connections between design tools and code are arriving quickly, and the line between sketch, build and polish will move again.
If you are building something with a model inside it and want the behaviour designed as carefully as the screens, tell us about it.
A picture of an AI product shows the cases somebody thought of. The product is everything else.
Asked often.
Is Figma still used in AI product design?
Yes, at both ends of the process: for fast sketching at the start and for precise polish at the end. The middle, where products used to be specified screen by screen, now happens in a working build made with AI coding tools.
Why can’t AI product behaviour be designed in static mockups?
Because a model’s output depends on the input, the user and the data it is given, so the range of possible responses cannot be drawn as a fixed set of states. It can only be seen and tested by running the product.
Who should own an AI product’s behaviour?
A named person, agreed up front. Decisions about uncertainty, clarifying questions, hand-over to humans and fallbacks live in prompts, tool structure and fallback logic, and should be written down and tested like the rest of the design.