In product teams building AI experiences, Figma is quietly losing its position. Not because it’s getting worse. Because what design produces has changed. That shift carries real consequences for anyone who signs off on how products get built.
When Shali Nguyen, head of consumer experience design at DoorDash, described how her team now works, she was precise: Figma has shifted "from being the primary design tool to a canvas for quick exploration and polishing details as input for Claude Code."
"Traditional prototyping took two weeks on average. Now, using vibe-coded prototypes, it’s completed in hours. We use Figma as a scalpel now — pull an area out for specific cuts and push it back into the coded prototype."
A sketch pad and a scalpel are not the same thing. The distinction is the story the industry has mostly missed.
What actually collapsed — and what didn’t
Figma has not been demoted to one role. It has been stripped of one.
AI in Design 2026 report surveyed more than 900 designers across 60 countries. Around half have shipped AI-generated code to production. 65% have taken on product or engineering responsibilities that weren’t in their job descriptions a year ago. 40% say the reverse is also true: engineers are making design decisions.
Nobody updated the org chart.
But the more important shift is not who uses Figma. It is where Figma sits in the sequence. A year ago, Figma was the comprehensive artifact: the file that captured the whole product, specified every state, and served as the primary source of truth from idea to handoff. That role is gone. What remains is the sketch — rough exploration of ideas before anything is built — and the scalpel — precision polish after the product is running. The middle, where design lived for most of the last decade, has collapsed.
This matters to product leaders because the middle is where most decisions got made. If your process still assumes the Figma file is the source of truth, your team is making decisions in a medium that no longer holds them.
The lesson from Norvana — and what it actually proves
The clearest way to explain this shift is through a project we built ourselves.
When we started The Making of Norvana — an AI-native personal health companion — we made a common mistake, and it wasn’t Figma. The mistake was sequencing.
We designed the way we’d designed every product before. Screens in Figma. Flows. Health dashboards with energy scores that looked polished and meant nothing — because without real user data, none of it could be tested on real people. Norvana was a startup with an unvalidated hypothesis. We polished before we validated. The Figma work was not wrong. It was premature.
Then we put a designer in front of Cursor, connected Apple HealthKit, and fed real step counts, heart rate data, and sleep patterns to a model. Everything ran on-device. The demo was rough. But for the first time, we could feel the product — not look at a picture of it. It all came together fast: what the AI could actually do with real data, where the recommendations fell flat, where the experience broke. We scrapped that demo. It wasn’t good enough. But in the time it took to build and discard it, we understood more about what Norvana needed to be than months of mockups had produced.
That working code also unlocked something static design structurally cannot: the ability to test what happens when a user uploads real lab results. Bloodwork. Biomarkers. Chronic conditions. The AI’s response to a user with low iron is different from its response to the same user without that context. Scan an apple and Norvana tells one user it’s a great source of fibre. It tells a diabetic user to watch the sugar content and consider timing relative to meals. Same input, different context, different response. You can draw two states in Figma in ten minutes. You cannot draw the space between them — all the variations a real model produces across real people with real health profiles. That space is the product. You only see it when the model is running.
From that point, Figma became the sketch tool it should have been at the start: a place to rough out ideas before building and testing in code. And after validation, it became the scalpel — pixel-perfect polish for the screens that needed it, handed to developers as an unambiguous spec. Sketch. Validate. Polish. Figma at both ends, code in the middle.
The sequencing failure we made at Norvana is not new. Beautifully designed products have died before launch for as long as design has existed. What AI changed is that validation got cheap enough to come first. The teams that understand this are not abandoning Figma. They are moving it.
What this means for your product strategy
Three structural risks follow from a process that hasn’t made this shift.
Evaluation criteria that measure the wrong thing. If you’re assessing design work — internal team or external partner — by Figma output, you’re evaluating a document rather than a product. The better question is: can they show you a working system? A team producing polished Figma files without the ability to build and test in code is skipping the step that tells you whether the product actually works. Worth noting: great products can have a messy Figma. The Figma file is not the evidence.
The handoff problem — and the real opportunity. The traditional handoff from design to engineering introduces a translation at every step: Figma to code, code to QA, QA back to engineering. For AI products, each translation introduces assumptions about behaviour that can only be tested in the actual system. But the opportunity is not to eliminate the handoff — it is to improve what gets handed off. A working prototype is a better specification than a static file. Teams that validate in code and then hand off a functional prototype to implementers get the benefits of both: validated behaviour and a clean path to production.
Behavioural ownership — an old problem in a new location. When designers are shipping code and engineers are shaping experiences, who owns the decisions that determine how your AI product behaves? What does it say when it’s uncertain? When does it ask a clarifying question rather than make an assumption? When does it escalate to a human? This has always been contested territory. What AI has changed is where these decisions live. They are now in the prompt architecture, in the tool call structure, in the fallback logic: a layer below where most POs are currently looking. In practice, on the projects we run, designers write the rules, prompts, and fallback logic and test the model; the client team connects it to the application. That division works — for now. It is worth being explicit about it in your org before a quality incident makes it explicit for you.
The cost of moving to code
Not all of this is straightforward. The AI in Design 2026 report notes a real tension: code forces commitment too early, and speed compresses the open-ended phase where designers develop their judgment. Figma’s CEO Dylan Field made this explicit in a recent post:
"It’s so easy to get lost in the momentum of creating something. There’s a natural pull to keep going. And as a result, the first version often becomes the version."
His argument is right — and it applies more to clients than to designers. Non-technical teams can now arrive with a vibe-coded structure and something more precise than an idea. Vibe-coded does not mean it works. The value of an experienced design partner is not that they know how to use the tools. It is that they have launched enough products to know what needs to be added to make a prototype work, how to sequence the next steps, and which metric will tell you whether it did.
For product leaders, this also surfaces as a hiring question. 22% of design leaders now rank technical and coding skills as a top criterion — a year ago this wasn’t in the top five. Hiring for code alone solves the wrong problem. What you need are people who can make design decisions in code and know when to step back and apply the scalpel.
What to do about it
Three moves worth making now — with one test to run first.
Run the fork test before anything else. The question that determines which of the following actions applies: is design the differentiator on this product, and is there budget for it? For a product where impact and quality are the goal — where craft is what separates it from the competition — pixel-perfect polish and tools like Figma Agent remain legitimate and are currently irreplaceable. Startups optimising for speed, and organisations that value time-to-market over finish, are in a different position.
Audit for behaviour, not aesthetics. When evaluating design work — in hiring, in agency selection, in internal review — ask for a working prototype, not a Figma file. If the team can only show you static screens, they haven’t validated the product. They’ve designed a document about it.
Define who owns AI behaviour — and where. Add a question to your next product review: who owns the decision about how this product behaves when the AI is wrong? When it’s uncertain? When the user does something unexpected? And crucially: where do those decisions live — in a doc, in a ticket, or in the code? If the answer is "whoever wrote that part of the prompt," you have a gap.
Date your assumptions. The sketch/validate/polish split exists because pixel-perfect Figma-to-code still requires developers — a tooling constraint, not a structural fact. A better Figma MCP changes this. The teams moving fastest right now are treating the current tool landscape as a fact about today, not a permanent condition.
The mirror
The companies that will fall behind aren’t the ones that haven’t adopted AI. Most have. The ones that will fall behind are the ones that adopted AI features and kept their design process in 2022 — still treating the Figma file as the source of truth, still handing off static specs for AI-native products whose core behaviour cannot be represented in them.
Figma becoming a sketch pad is not the whole story. Figma becoming a scalpel is the other half. What disappeared is the middle — the comprehensive artifact that specified the whole product and served as the primary handoff. That role will not come back.
The product is the behaviour. The validation is in the code. The question is whether your team has a process that actually reaches the behaviour — or one that stops at the picture of it.
Key takeaways
- 𐩒Figma survives at both ends of the design process — rough ideation and precision polish. What collapsed is the middle: the comprehensive artifact role that served as the primary handoff.
- 𐩒The failure mode most teams hit — including ours on Norvana — is not Figma. It is sequencing: polishing before validating. AI made validation cheap enough to come first. The sequence is sketch → validate → polish.
- 𐩒For AI-native products, the design artifact is a working system, not a Figma file. Static prototypes cannot represent context-dependent, generative behaviour — you see what the model actually does only when it is running on real data.
- 𐩒AI also improves the handoff. A working prototype is a better specification than a static file. The goal is not to eliminate handoffs — it is to hand off something real.
- 𐩒Behavioural ownership is an old problem in a new location: prompt architecture and fallback logic are below where most POs are looking. Be explicit about who owns this layer before an incident makes it explicit for you.
- 𐩒The sketch/code/polish split is a fact about current tooling, not a permanent structure. Better MCP integration will move polish into code. Date your assumptions accordingly.
How does this apply to your product process?
Discuss with your AI.
Andrii is a product designer who takes products from a rough brief to a finished release. He works through discovery, design, handoff, and dev support. He works best with B2B SaaS, internal tools, and data-heavy screens, where he keeps things clear and easy to use. He also brings order to how teams deliver design — with clear specs, simple planning, and close work with developers. Right now he is focused on AI-driven prototyping with React and React Native, using AI to turn ideas into working, testable prototypes faster.
