How to Prompt v0 by Vercel for UI (2026): Formulas + Examples

v0 by Vercel turns a natural-language prompt into production-ready React, Next.js, Tailwind, and shadcn/ui code — real files you can deploy, not a mockup. The quality of that code depends almost entirely on one thing: how precisely you describe the interface. The winning pattern is a three-part formula — product surface + context of use + constraints and taste — and Vercel ships its own template for it.

Copy this shape into the v0 chat box and fill the brackets:

Build [product surface].
Used by [who], in [what moment], to [decision/outcome].
Constraints:
- platform/device
- visual tone
- layout assumptions

This guide breaks that formula down, then gives you nine copy-paste prompts — including vague-vs-specific pairs — plus how to iterate, when to reach for Design Mode, and how to scope big apps. For a full library of ready-made prompts, keep 40 Best v0 by Vercel Prompts open in another tab.

The 3-part v0 formula, broken down

A strong v0 prompt answers three questions before v0 has to guess: what is on the screen, who is looking at it, and what it should look and feel like. Miss any one and v0 fills the gap with an average default.

• Product surface — the actual components, data, and actions. Not "a dashboard" but "an open-tickets count, average response time, a tickets-by-priority bar chart, and an agent list showing each agent's current workload."
• Context of use — who uses it, in what moment, to make what decision. This tells v0 what to emphasize: a support lead triaging at 9am needs the priority chart big and the agent list scannable.
• Constraints and taste — platform and device, visual tone, layout assumptions, and exact design tokens. This is where "clean and modern" loses to real hex codes and a radius value.

Watch what the difference does. Here is a vague prompt that leaves everything to chance:

Make me a support dashboard.

Why it falls flat: no surface, no user, no taste. v0 produces a generic three-card layout you'll immediately re-prompt. Now the same intent with the formula applied:

Build a customer-support triage dashboard. The top row shows three stat cards: open tickets, average first-response time, and SLA breaches today. Below, a full-width "tickets by priority" horizontal bar chart, and to its right an agent list showing each agent's name, avatar, status dot, and current open-ticket count.

Used by a support team lead at the start of a shift, to decide who to reassign work to and which tickets need escalation now.

Constraints:
- Desktop-first, responsive down to 768px (stack columns on mobile).
- Calm, professional tone; generous whitespace, no drop shadows.
- Sidebar nav on the left with 5 items; content area to the right.
- Use shadcn/ui Card, Badge, and Avatar; mock the ticket data.

Why it works: v0 knows every element, the decision it supports, and the visual rules — so the first generation is close enough to refine instead of restart. If you want this shape as fill-in-the-blank slots, see the v0 prompt templates.

Give exact design tokens

The fastest way to make v0 output look like your product is to hand it real design tokens instead of adjectives. "Modern and clean" means nothing measurable; #4F46E5 and radius: 12px do. Put tokens in the constraints block as concrete values.

Apply this design system to the whole UI:
- Primary: #4F46E5  Primary-hover: #4338CA
- Background: #0B0B0F  Surface/card: #15151B
- Text: #F4F4F5  Muted text: #A1A1AA
- Success: #22C55E  Danger: #EF4444
- Border radius: 12px on cards and buttons, 8px on inputs
- Font: Inter; weights 500 for body, 700 for headings
- Spacing scale in multiples of 4px; card padding 24px
- Subtle 1px borders instead of shadows; dark theme only

Best for: pinning brand consistency across every screen v0 generates. Send this once, then reference it in later prompts ("keep the design tokens from before"). For a full menu of token blocks and visual modifiers, the v0 prompt cheat sheet is the one-page reference.

Specify the stack — or deliberately don't

v0 already defaults to React, Next.js (App Router), Tailwind, and shadcn/ui with TypeScript, so you rarely need to name the frontend stack. Call it out only when a specific choice matters: a particular shadcn component, a server action, a route handler, or a database connection. The "new v0" runs a full sandbox, so it can wire real backends too.

Build a waitlist signup page (Next.js App Router, Tailwind, shadcn/ui). A centered hero with headline, subhead, and an email field with a "Join waitlist" button.

Wire the form to a server action that inserts the email into a Supabase table called `waitlist` (columns: id, email, created_at) and returns a success or duplicate-email state. Show an inline success message and disable the button while submitting. Use shadcn Input, Button, and Toast.

Constraints: single-column, mobile-first, max-width 480px content column, Inter font, primary #16A34A.

Why it works: it names only the stack details that aren't defaults — the server action and the Supabase wiring — so v0 builds real functionality instead of a static form. Once it's working, deploy to Vercel in one click from the same chat.

Say what NOT to build

v0 is eager — it adds auth, dark-mode toggles, and extra sections it thinks you'll want. Each extra costs credits and pulls the output off-target. An explicit exclusions line keeps generations focused.

Build a project-settings page with three sections: General (project name, description), Members (a table of users with role dropdowns), and Danger Zone (a delete-project button with a confirm dialog).

Do NOT build: authentication, a navbar, a dark-mode toggle, or any backend — mock all data with static arrays. Do NOT add sections I didn't ask for. Keep it to these three sections only, in shadcn/ui.

Best for: stopping scope creep on a focused screen. Naming exclusions is also the cheapest way to cut wasted credits, since v0 burns them on every generation — even a failed one.

Iterating: Prompt-for-changes vs Design Mode

Pick the tool to match the change. Use Prompt-for-changes for anything functional — adding features, restructuring the layout, changing behavior. Use Design Mode, v0's visual editor, for quick taste tweaks to colors, spacing, typography, and component states without writing a prompt or touching code.

A precise change prompt beats a vague one just like an initial prompt does. Instead of "make it nicer," name the element and the exact change:

Two changes to the current page:
1. Move the "New ticket" button from the top-right of the header into the sidebar, as the first item above the nav links.
2. In the stat cards row, add a small trend indicator under each number — an up/down arrow and a percentage vs last week — in muted green for up, muted red for down.

Keep everything else exactly as it is.

Why it works: scoped, numbered edits with "keep everything else" stop v0 from redesigning parts you were happy with. For pure visual polish — nudging a color or a gap by a few pixels — skip the prompt and drag it in Design Mode, then fork the generation if you want to branch a variant without losing the original.

Prompt queuing and PRD-first for big apps

Don't describe a whole app in one prompt. Two features make large builds manageable: prompt queuing and a PRD-first approach.

Prompt queuing lets you chain up to roughly ten sequential instructions so v0 works through them in order while you step away. PRD-first asks v0 to write a short plan before it builds, so you catch structural problems before they become code. For anything beyond a single screen, build component by component.

Before writing any code, act as a product engineer and write a short PRD for a habit-tracking web app: core screens, the main data model (habits, check-ins, streaks), key user flows, and which shadcn/ui components each screen needs. List the screens in the order you'd build them.

Do not generate the UI yet — output the PRD only. I'll approve it, then we'll build one screen at a time.

Best for: aligning on structure before v0 commits to code. Once the PRD is approved, queue the build screen by screen:

Now build the app from the approved PRD, one screen per step. Queue these in order:
1. The habits dashboard (list of habits with today's check-in toggles and streak counts).
2. The "add habit" form (name, frequency, color, reminder time).
3. The single-habit detail view with a 12-week calendar heatmap of check-ins.
4. The weekly summary screen with completion-rate stats.

Use consistent design tokens across all four. Pause after each screen so I can review before you start the next.

Why it works: the queue keeps each generation small and reviewable, which produces cleaner code and spends fewer credits than one sprawling mega-prompt. To fork this into your own project scaffolds, browse the full v0 prompt roundup.

Attach a screenshot or Figma for design reference

When you already have a visual target, don't describe it in words — show it. Attach a screenshot or image in the chat, or import a design directly from Figma, and tell v0 what to match. Pair the image with written tokens so v0 has both the picture and the exact numbers.

I've attached a screenshot of a pricing page I like. Recreate its layout and spacing feel in React + Tailwind + shadcn/ui: three pricing tiers side by side, the middle one highlighted as "Most popular," a feature-comparison list under the cards, and a monthly/annual toggle at the top.

Match the general structure and rhythm of the screenshot, but use MY tokens: primary #7C3AED, background #FFFFFF, radius 16px, Inter font. Don't copy their exact copy or logo — use placeholder text and my three tiers: Free, Pro $19, Team $49.

Best for: hitting a look you can see but can't fully spell out. Telling v0 to match structure while swapping in your tokens avoids a pixel-for-pixel clone and gives you something on-brand.

Common mistakes to avoid

Most weak v0 output traces back to a handful of prompt habits. Avoid these and your first generation gets dramatically closer:

• Naming a feeling instead of a surface. "A sleek CRM" gives v0 nothing to render. List the components, data, and actions.
• Adjectives instead of tokens. "Modern colors" is unmeasurable. Give hex values, a radius, a font, and a spacing unit.
• One giant prompt for a whole app. It produces tangled code and burns credits. Write a PRD, then build component by component.
• Vague change requests. "Make it pop" invites a redesign. Name the element and the exact change, and add "keep everything else."
• Forgetting exclusions. Without a "do not build" line, v0 adds auth, navbars, and toggles you didn't want.
• Ignoring the mode. Prompting for a two-pixel color nudge wastes a generation — use Design Mode for visual polish.

Fold the fixes into one default shape — product surface, context, constraints with tokens, and an exclusions line — and reuse it for every screen. For a fill-in-the-blank starting point, grab the v0 prompt templates; if you also build in a sibling tool, compare technique with the best Lovable prompts.