A static Figma screen tells a stakeholder what you intend. A working v0 preview shows them, and "show, don't tell" is the difference between a CPO nodding politely and a CPO actually feeling the interaction. By 2026 v0 on Vercel will translate a Figma screen into a functioning React component preview in minutes, which is genuinely powerful and genuinely treacherous, because in the translation v0 drifts from your design intent in small, specific, invisible ways: a missing focus ring, a hover state it invented, a responsive breakpoint that reflows wrong. This lesson teaches you to use v0 for the show-don't-tell demo and then catch exactly where it drifted, so what you show is your design and not v0's plausible approximation of it. The artifact is a v0 demo URL plus a design-intent diff sheet that names every drift and its correction.

The Demo That Showed the Wrong Thing

Picture a product review. A designer wants to make the case for a new filter component, and instead of walking the CPO through a static frame, they drop a Figma screen into v0, get a working React preview in four minutes, and share the live URL on the call. The CPO clicks it, hovers, filters, and lights up: this is the moment static mocks never deliver, the felt sense of the interaction. The demo lands. The feature gets greenlit.

Then an engineer picks up the v0 output to build from, and the drift surfaces. The hover state on the filter chips, the one the CPO found delightful, was invented by v0; it is not in the Figma file and not in the design system, so now it is either a new pattern the team has to ratify or a thing to remove that the CPO already fell in love with. The primary "Apply filters" button has no focus ring, so it fails keyboard accessibility, but nobody noticed on a mouse-driven demo. And at the tablet breakpoint the filter row reflows into an awkward two-line wrap that was never designed. The demo showed something compelling. It also showed three things that were not your design, and now they are load-bearing in a stakeholder's memory.

This is the L2 pattern in its show-don't-tell form. v0 supplies the speed and the magic of a working preview from a static screen. You supply the verification that what the preview shows is actually your design and not v0's confident interpolation of the gaps your Figma file left open. The preview is allowed to make your design feel real. It is not allowed to quietly redesign it.

Why v0 Drifts, and Why It Drifts in Predictable Places

To catch v0's drift you have to understand why it happens, because it is not random. A Figma screen is a static artifact. It specifies what the screen looks like in one state, at one size, with no interaction. But a working React component needs far more than that: it needs hover states, focus states, active and disabled states, responsive behavior across breakpoints, transitions, and the dozens of small interactive decisions a static frame never captures. v0 has to fill all of those gaps to produce something that works, and it fills them the only way a model can, by generating the most statistically plausible version of each missing piece.

So v0's drift is concentrated exactly in the gaps your static design did not specify. It is not drifting on the things you drew; it is interpolating the things you did not draw. That is why the drift is predictable: it lives in interaction states, accessibility affordances, and responsive behavior, the three categories a Figma screen is least likely to fully specify. The hover state, the focus ring, the breakpoint reflow - these are not v0 being careless. They are v0 doing its job of making a static thing interactive, and inventing the interactive parts because you did not hand them over. Knowing this tells you precisely where to look.

The Three Drift Zones to Audit Every Time

Because the drift is predictable, the audit is too. Three zones account for nearly all of it, and you check them in order on every v0 output before it goes anywhere near a stakeholder.

Drift Zone One: Focus Rings and Keyboard States

The first and highest-stakes drift zone is focus and keyboard accessibility, because a mouse-driven demo hides it completely and it is a hard accessibility failure. v0 frequently omits focus rings entirely, or generates a default browser outline that does not match your design system's focus token and does not meet the WCAG 2.2 2.4.11 focus-appearance minimum of 3:1 contrast. Tab through the entire v0 preview with the keyboard, not the mouse, and confirm that every interactive element shows a visible focus indicator that matches your system and meets the ratio. This is the drift most likely to ship a real accessibility defect, and the one a stakeholder demo is structurally blind to.

Drift Zone Two: Hover and Invented Interaction States

The second zone is hover and other interaction states that v0 invented because your Figma file did not specify them. These are seductive precisely because they often look good, which is the danger: a stakeholder falls in love with an interaction you never designed and did not approve. Hover over every interactive element and compare what v0 produced against your design system. Is this hover treatment ours, or did v0 generate a plausible one? An invented hover state is not automatically wrong, but it is automatically undecided, and undecided things should not become load-bearing in a stakeholder's memory before you have ruled on them.

Drift Zone Three: Responsive Breakpoints

The third zone is responsive behavior. Your Figma screen was probably designed at one width; v0 has to decide what happens at every other width, and it decides by interpolation. Resize the v0 preview across your real breakpoints - mobile, tablet, desktop - and watch for reflows you never designed: a row that wraps awkwardly, a column that collapses wrong, a fixed element that overlaps content, a touch target that shrinks below the 2.5.8 24-by-24-pixel minimum on the smaller view. The responsive drift is invisible on the demo machine, which is always at one comfortable size, and it is exactly what breaks first when a real user opens the feature on a phone.

v0 does not drift on what you drew. It drifts on what you left blank. The audit is not 'check everything' - it is 'check the gaps,' because the gaps are where the model did the inventing.

The Design-Intent Diff Sheet: The Artifact That Keeps the Demo Honest

The deliverable that turns a risky v0 demo into a safe one is the design-intent diff sheet: a short, structured record of every place v0's output differs from your design intent, what the difference is, and how you resolved it. It is the v0 analog of the Galileo rebuild diff, and it does the same load-bearing job: it makes the drift visible and the correction auditable, so nobody downstream has to guess which parts of the demo are your design and which are v0's interpolation.

Structure it as a table, one row per drift, with four columns: the element, the design intent (what your system specifies or what you decided), what v0 produced, and the resolution. "Filter chip hover: system specifies a subtle background-token shift; v0 invented a scale-up animation; resolution: removed the animation, applied the system hover token." "Apply-filters button focus: system specifies the 3:1 focus-ring token; v0 produced no focus ring; resolution: added the focus token, re-verified at 3:1." "Filter row at tablet: design intent is a single scrolling row; v0 wrapped to two lines; resolution: set the breakpoint to maintain a horizontal scroll." The diff sheet does three jobs. It documents your corrections so the demo you show is verified. It hands engineering a precise list of where v0's output must be changed before it becomes real code. And it protects you in the room: when the CPO loves the invented hover, you can say "that is a v0 addition I have not approved, here is what our system does instead," instead of silently shipping a pattern you never designed.

Correct Before You Show, Not After

The sequencing matters more than it seems. The temptation is to run the v0 preview, show it immediately because it is exciting, and clean up the drift later. This is exactly backwards, and it is the single most common way the show-don't-tell demo backfires. The moment a stakeholder sees and loves an interaction, that interaction becomes a commitment in their head, whether or not it is your design. If the delightful hover was v0's invention, you now have to either un-delight the CPO by removing it or ratify a pattern that never went through your design system. Both are worse than the thirty minutes it would have taken to audit the drift before the call.

So the rule is: audit the three drift zones and resolve the diff sheet before the demo, never after. Show a v0 preview you have already corrected, so that everything the stakeholder reacts to is your verified design. The preview's power - making the interaction feel real - is a power you want pointed at your actual design intent, not at v0's plausible guesses about the parts you left blank. A corrected v0 demo is the best show-don't-tell tool available in 2026. An uncorrected one is a way to get a stakeholder emotionally attached to design decisions you never made.

When v0 Is the Right Tool, and When It Is Not

v0's profile makes it excellent for two jobs and risky for a third. It is excellent for the show-don't-tell stakeholder demo, once corrected, because its working React preview delivers the felt interaction a static mock cannot. It is excellent for the engineering handoff, because its output is real React close to what engineering will build, and the diff sheet hands them a precise correction list. Where it gets risky is exactly the scenario in the opening story: an uncorrected preview shown live to a high-stakes stakeholder, where the invented interactions become commitments before anyone has audited them.

The discipline is to always insert the audit between v0's speed and the stakeholder's eyes. v0 is not the author of your interactions any more than Galileo was the author of your screen; it is a fast translator that fills the gaps your static design left, and the gaps are where you must verify. Use the speed, point it at your real design, and never let the parts v0 invented reach a stakeholder unaudited. That single rule converts v0 from a demo that can quietly redesign your feature into a demo that makes your actual feature unforgettable.

The Fourth Drift Zone: Motion and Timing

The three zones - focus, hover, responsive - account for the overwhelming majority of v0 drift, but there is a fourth that surfaces once a preview passes the first three and still feels subtly wrong, and it is worth knowing so your audit is complete. A static Figma screen specifies no temporal behavior at all: no transition durations, no easing curves, no motion when a state changes. A working React component, to feel alive, needs all of that, so v0 invents it, generating transitions and animations the way it generates everything else, by plausible interpolation. The result is motion you never designed, which can violate both your intent and accessibility.

The accessibility stakes are real and specific. WCAG 2.2's 2.3.3, animation from interactions, expects motion triggered by interaction to be disable-able, and the broader expectation is that a component respects the user's prefers-reduced-motion setting rather than forcing animation on someone who has asked the system to minimize it. v0, filling the temporal gap by default, frequently ships transitions that ignore prefers-reduced-motion entirely, which is a genuine accessibility defect hiding inside a delightful-feeling demo. So when a preview passes the first three zones but the motion feels off, extend the audit: check every transition v0 generated against your motion tokens, confirm the durations and easing match your intent rather than v0's invented defaults, and verify the component honors prefers-reduced-motion. Add motion rows to the design-intent diff sheet in the same four-column form: the element, the intended motion, what v0 produced, and the resolution.

The reason motion is the fourth zone and not one of the first three is purely about stakes ordering, not about whether it drifts. Focus carries the highest severity-times-invisibility, so it leads; hover and responsive carry the next-highest commitment and breakage risks. Motion drift is real but usually lower-stakes than a missing focus ring or a broken mobile layout, so it earns a place in the complete audit without displacing the three that come first. The principle is the same throughout: v0 drifts wherever your static design left a gap, and motion is simply the temporal gap. Once you see all four zones as the four categories a static screen fails to specify - interaction states, accessibility affordances, responsive behavior, and temporal behavior - the audit becomes a complete map of exactly where the model had to invent, which is exactly where you must verify.

This four-zone map is also why richer design-system context in your v0 prompt reduces drift without ever eliminating the audit. If you expose your tokens, map your components through Code Connect, and specify your focus, hover, breakpoint, and motion treatments in the prompt, v0 has fewer gaps to fill and will pull more of your real system instead of guessing, which genuinely lowers the drift rate at the source. But a static screen plus even a complete system still under-specifies the interactive and responsive decisions of any particular feature, so v0 must still interpolate something, and it will do so plausibly. System context and the audit are complementary, not substitutes: the context reduces how much v0 invents, and the four-zone audit catches what it still invents. Removing the audit because your prompt got better is exactly the mistake of trusting the model's plausibility over your verification of system-truth, which is the whole error this lesson exists to prevent.

Putting It to Work This Week

Before your next stakeholder review, try the corrected v0 demo. Take a Figma screen you would otherwise present statically, run it through v0, and get the working preview. Then, before you show anyone, audit the three drift zones in order: tab the whole thing for focus and keyboard states, hover every element to catch invented interactions, and resize across your real breakpoints to catch reflows and shrunk touch targets. Build the design-intent diff sheet as you go, one row per drift, resolving each against your design system. Then show the corrected preview, with the diff sheet ready in case anyone asks where v0 ended and your design began.

You will know the practice has landed when a stakeholder feels your interaction for the first time and reacts to it, and every single thing they react to is something you actually designed and verified. That is the whole promise of show-don't-tell done right: the emotional power of a working preview, pointed entirely at your real design intent, with none of v0's invisible interpolations smuggled in. v0 gives you the working demo in minutes. The drift audit and the diff sheet are what make the demo yours.

Key Takeaways

• v0 on Vercel translates a Figma screen into a working React preview in minutes, delivering the felt interaction a static mock cannot, but in the translation it drifts from your design intent in small, specific, invisible ways.
• v0's drift is predictable because it is concentrated in the gaps your static design left blank: interaction states, accessibility affordances, and responsive behavior, the three categories a Figma screen least specifies. It interpolates what you did not draw.
• Audit three drift zones every time, in order: focus rings and keyboard states (tab the whole preview; verify the 2.4.11 3:1 focus ring), hover and invented interaction states (catch the delightful pattern you never designed), and responsive breakpoints (resize across mobile, tablet, desktop; catch reflows and touch targets shrunk below 2.5.8's 24-by-24).
• Build a design-intent diff sheet: one row per drift with element, design intent, what v0 produced, and the resolution. It verifies the demo, hands engineering a precise correction list, and protects you when a stakeholder loves an invented interaction.
• Correct before you show, never after. The moment a stakeholder loves an interaction it becomes a commitment in their head; auditing the drift before the call is far cheaper than un-delighting a CPO or ratifying a pattern that never went through your system.
• Always insert the audit between v0's speed and the stakeholder's eyes. v0 is a fast translator that fills the gaps, not the author of your interactions; point its power at your verified design intent and let nothing it invented reach a stakeholder unaudited.