The 2026 Figma surface is a set of AI instruments — First Draft, the agent, Make, Motion, Weave — each with a job and a boundary. This module makes them daily tools, then goes where static mocks can't: prototyping AI features with real model responses, so your usability tests exercise latency, variance, and failure.
Meera, six years into product design at a Bengaluru SaaS company, is designing her product's first AI feature: a one-click "summarize this account's history" panel for support agents. She does everything her training says. She designs the panel, writes a beautiful example summary as placeholder content, builds a click-through prototype, and runs five usability sessions.
The tests go great. Participants click the button, the polished summary appears instantly, everyone calls it useful. The feature ships eight weeks later.
Then the real numbers arrive. Agents click once, wait nine seconds staring at an unexplained spinner, and read a summary that is — unlike Meera's hand-crafted placeholder — occasionally vague, occasionally wrong about refund amounts, and formatted differently every time. By week three, feature usage has cratered; agents say they "don't trust it." Nothing about this was discovered in testing, because nothing about this was in the testing. Meera tested a static fiction: instant, perfect, identical every run. The shipped feature is slow, variable, and sometimes wrong — and those three properties, the ones that killed it, are precisely what her prototype could not exhibit.
A static happy-path mock of an AI feature doesn't just miss problems — it manufactures false confidence. Latency, output variance, and failure states are the usability problems of AI features, and a prototype that can't produce them tests a product that doesn't exist.
This module has two halves: mastering the in-canvas AI surface as a daily instrument, and building the kind of prototype that would have saved Meera's feature.
Figma's AI capability in 2026 is not one feature but a toolbox, and fluency means knowing each instrument's job and its allowed zone — where output may ship, and where it is draft-only.
| Instrument | What it does | Allowed zone |
|---|---|---|
| First Draft | Prompt-to-wireframe on canvas | Exploration and critique fodder only — never ships as-is |
| Figma agent | In-canvas edits on request: rename layers, restructure, batch ops, build generative plugins | Ops automation; spot-check the result |
| Make an image / Replace | Generate or swap imagery in place | Placeholder and exploration; production assets go through Weave + art direction |
| Smart search | Semantic search across files ("the pricing card with the toggle") | Freely — read-only |
| Prompt-built shaders | Generative visual effects from a text prompt | Exploration; performance-check before any production use |
| Weave image tools | On-brand image generation and restyling | Production-capable under human art direction and a usage-rights policy |
| Figma Motion | AI-assisted keyframes and easing | Drafts you re-time; reduced-motion variant checked before handoff |
| Figma Make | Prompt-to-working-prototype | Usability tests and demos — explicitly not production code |
Two practices turn this from a demo reel into a daily instrument. First, route real grunt work through the agent: layer renaming before every handoff, spacing normalization, page scaffolds for new projects — and when an operation recurs, ask the agent to build a small generative plugin for it so the automation persists. Second, write the allowed zones down. Lab 6 runs you through a timed gauntlet — first-draft a screen from a brief, restyle with Weave, build one plugin — and ends with the artifact that matters most: your team's one-page "AI-allowed zones" convention.
Figma's AI feature set churns quarterly — names, tiers, and credit models included. The instruments-and-boundaries way of thinking transfers across renames; specific menu paths don't. When this module and the product disagree, trust the product and re-derive the boundary.
Figma Make (and the v0/Lovable class beside it) turns a static frame or a written spec into a working, interactive prototype — real inputs, real state, real conditional logic — by prompting. For a designer this collapses a historical wall: interactions that click-through prototypes could only fake (typing, filtering, multi-step forms with validation, data that responds) are now testable without an engineer.
The boundary is as important as the capability, and you should be able to state it in one sentence: Make output is a test and demo artifact, not production code. Production implementation belongs to engineering, with their design-to-code pipeline, their code review, and their quality gates. What crosses the wall from your prototype is learnings — validated flows, state requirements discovered in testing, interaction specs — not the prototype's code. Both this track and the frontend track state this split explicitly, so neither side is surprised.
Working Make well is mostly working it precisely:
Now the half that fixes Meera's failure. An AI feature's user experience is its variability — so the prototype must be variable. The technique is to wire the prototype to a real model: Make's AI blocks or a direct LLM API call behind the summarize button, with the feature's actual draft system prompt.
Instant response. One hand-polished summary, identical every session. No latency, no variance, no failure. Five participants praised a product that cannot be built. The test produced confidence and zero information about the risks that mattered.
Real model call, real 4–9s latency, different output every run. Session 2's participant hit a vague summary and hunted for a regenerate button that didn't exist — finding one. Session 4 hit a genuinely wrong refund figure and didn't notice — finding two, the important one: the feature needs verification affordances, not just polish.
A live-wired prototype turns usability sessions into encounters with the actual material of the feature: waiting, variance, and error. You'll watch participants develop trust or lose it in real time — and that, not layout preference, is the research question for an AI feature.
When wiring a live model isn't feasible — no API access, compliance constraints, a model that doesn't exist yet — fall back to Wizard of Oz: a human operator plays the model, pasting pre-drafted responses (including deliberately slow, vague, and wrong ones) into the prototype during the session. It's manual and it scales badly, but it preserves the property that matters: the participant experiences variable, imperfect output with realistic timing. A curated response deck — good, mediocre, wrong, refused — gives you controlled coverage a live model won't guarantee.
Whichever mechanism you use, script at least one failure. Seed a session where the model refuses, times out, or gets a fact wrong, and watch what the participant does. Module 7 gives failure states their full design vocabulary; the prototype is where you first watch a user hit one.
AI features multiply states, and even ordinary screens carry more than designers usually draw. The enumeration sweep is a Foundation habit that pays off every sprint: for each screen, have an assistant generate the full state matrix, then you curate which states are real for your product.
The model's job is exhaustiveness — it will happily list thirty states. Your job is curation: which are reachable, which matter, which merge. The sweep's output feeds directly into your components, your handoff spec pack, and later your Make prompts ("include empty, error, and loading states" belongs in every generation).
A live-wired prototype generates two kinds of value, and only one of them should leave your desk. The prototype itself — Make's generated code, the API wiring, the duct tape — stays design-side and dies when the learning is extracted. What crosses to engineering is the distilled version:
What does not cross: the prototype's code as an implementation starting point. Engineering owns production design-to-code with its own pipeline and quality gates — the frontend track covers that side of the wall, and both curricula state the boundary so neither team is surprised at handoff.
Figma Motion brings AI-assisted keyframe and easing generation into the canvas. Treat it exactly like First Draft for animation: the model proposes movement; you own timing and intent. Practical rules — keep durations honest to your product's pace rather than the demo-reel default; check the reduced-motion variant before anything ships, because vestibular accessibility isn't optional; and hand off through Dev Mode's animation inspection so engineering reads real values, not a video. Implementation stays on the engineering side of the wall, as ever.
Wire the live model into your prototype at the draft system-prompt stage, not after the feature is fully specified. Watching five participants react to real outputs is the cheapest prompt-engineering feedback loop that exists — you're tuning the feature's actual behavior while it's still a prototype.
Master the instruments, respect the boundaries: First Draft explores, the agent automates, Make prototypes, and none of them ship. And for AI features, prototype the truth — real latency, real variance, real failure — because a usability test of the happy path is a test of a product you aren't building.