v0 prompts — UI component builder for specs that ship

Build a page section / block for: [product purpose].

## Requirements
- [list the sections, fields, and primary actions the UI must include]

## Stack
Use Next.js (App Router) + React + TypeScript + Tailwind CSS.

## Visual direction
Balanced density suitable for product UI.
Neutral professional palette, subtle borders, no neon gradients.
Use a clear visual hierarchy. Prefer real-looking copy over lorem ipsum.

## States & responsiveness
- Include empty state with helpful CTA
- Include loading / skeleton state
- Include responsive mobile layout

## Accessibility
- Semantic HTML, labels on inputs, visible focus rings, keyboard-usable controls.
- Sufficient color contrast for text and icons.

## Constraints
- Production-ready structure; keep components composable.
- No placeholder stock photos unless essential; use simple shapes or initials.

## Deliverable
- A complete, copy-pasteable implementation of the UI described above.

No sign-up, nothing uploaded — the spec assembles in your browser.

Why vague v0 prompts produce demo UI

Generative UI tools optimize for something that looks complete. If you omit structure, they invent structure. If you omit states, they invent a happy path. If you omit constraints, they invent dependencies and stock photography. The output is impressive in a screenshot and awkward in a codebase. The gap between demo and product is almost always unspecified states and unspecified constraints — not a lack of “creativity tokens.”

Product designers already write specs. A v0 prompt is a condensed PRD for a single surface: problem, layout inventory, interaction states, implementation dialect, and non-goals. When you skip non-goals (“no chart library,” “no fake testimonials”), the generator fills the vacuum with fashionable defaults. Non-goals are as important as goals; the builder’s constraints field is where you protect your repo from surprise dependencies.

Speed is the seductive trap. Generating five landing pages in ten minutes feels like progress until none of them match your information architecture. Slow down for the first brief — purpose, structure, stack, states — then go fast on variants. The free v0 prompts tool is designed to make that first brief cheap enough that you stop skipping it.

A strong v0 prompt is a UI specification, not a mood board. It answers: what job does this screen do, what blocks does it contain, what stack should it target, how dense and themed should it feel, which states matter, and what is forbidden. The builder enforces those answers so you do not skip them under time pressure.

Real-looking copy matters. Lorem ipsum teaches the model nothing about hierarchy; “Start free,” “Invite teammate,” and “No prompts yet” do. Quote critical labels. Ban fake metrics if you do not want invented social proof. Specificity is kindness to future you who has to replace placeholders.

Treat generation as a draft pipeline. First prompt establishes structure. Second pass fixes spacing or component splits. Third pass wires real data shapes. Dumping every wish into one megaprompt often produces a tangled component; sequenced prompts produce cleaner layers.

Anatomy of a v0-ready UI prompt

Read the assembled prompt like a contract. If a contractor could still invent half the page, the contract is incomplete. Add the missing bullets before you generate. Iteration after a vague first pass costs more than thirty seconds of structure now — especially once you have fallen in love with the wrong layout.

Purpose — the product job

One sentence: pricing page for X, settings for Y, widget for Z. Purpose prevents a beautiful wrong page. Include the audience when it changes the UI (“for admits who manage seats,” “for first-time creators”). Audience is a layout input, not only a marketing input.

Requirements — the wireframe in bullets

List sections and actions. If two PMs would disagree about what is on the page, you are not done. Include empty-state copy goals when the page is often empty.

Stack — the implementation dialect

Next App Router vs plain React, Tailwind vs shadcn — these change imports and patterns. Say them. Matching your repo’s stack is how generated code stops being a rewrite project.

Visual direction — density and theme

Spacious marketing, balanced product, compact data — pick one. Neutral pro vs brand accent vs dark UI — pick one. Ambiguous “modern clean” is not a direction.

States, a11y, constraints — production honesty

Loading skeletons, errors, mobile, labels, focus rings, no unauthorized libraries — these lines are the difference between a mock and a starting point you can merge toward.

How to use this v0 prompts builder

After generation, read the component tree before you fall in love with the pixels. Split oversized files, rename generically named components, and replace dummy handlers. The prompt got you 70%; engineering judgment ships the rest.

Five v0 prompt recipes to copy

Full specs you can paste. Swap product details; keep the sections that force production thinking.

Build a full page layout for: a SaaS pricing page for a prompt library product.

## Requirements
- Hero with headline, subcopy, and primary CTA “Start free”
- 3 pricing tiers (Free / Pro / Team) in a responsive card grid
- Feature comparison bullets per tier; highlight the recommended tier
- FAQ accordion with 4 questions
- Sticky mobile CTA bar on small screens

## Stack
Use React + TypeScript + Tailwind + shadcn/ui primitives where helpful.

## Visual direction
Balanced density suitable for product UI.
Mostly neutral with one strong brand accent color.
Use a clear visual hierarchy. Prefer real-looking copy over lorem ipsum.

## States & responsiveness
- Include empty state with helpful CTA
- Include loading / skeleton state
- Include error state with recovery action
- Include responsive mobile layout

## Accessibility
- Semantic HTML, labels on inputs, visible focus rings, keyboard-usable controls.
- Sufficient color contrast for text and icons.

## Constraints
- Production-ready structure; keep components composable.
- No placeholder stock photos unless essential; use simple shapes or initials.
- Do not invent fake social proof numbers; use generic “Trusted by teams” copy.

## Deliverable
- A complete, copy-pasteable implementation of the UI described above.

Build a form with validation UI for: notification preferences in a web app.

## Requirements
- Header with title and short description
- Toggle rows for Email, Push, and SMS with helper text
- Quiet hours time range inputs
- Save and Discard actions; Save disabled when pristine
- Inline validation if quiet hours end is before start

## Stack
Use Next.js (App Router) + React + TypeScript + Tailwind CSS.

## Visual direction
Balanced density suitable for product UI.
Neutral professional palette, subtle borders, no neon gradients.
Use a clear visual hierarchy. Prefer real-looking copy over lorem ipsum.

## States & responsiveness
- Include loading / skeleton state
- Include error state with recovery action
- Include success confirmation state
- Include disabled control styles
- Include responsive mobile layout

## Accessibility
- Semantic HTML, labels on inputs, visible focus rings, keyboard-usable controls.
- Sufficient color contrast for text and icons.

## Constraints
- Production-ready structure; keep components composable.
- No charts libraries.

## Deliverable
- A complete, copy-pasteable implementation of the UI described above.

Build a dashboard widget for: weekly product metrics overview.

## Requirements
- Row of 4 metric cards: Signups, Activation rate, Churn, Revenue
- Each card: label, value, delta vs last week, sparkline placeholder
- Last updated timestamp
- “View report” text button

## Stack
Use React + TypeScript + Tailwind CSS.

## Visual direction
Compact density for data-heavy interfaces.
Dark surface hierarchy with clear contrast for text and controls.
Use a clear visual hierarchy. Prefer real-looking copy over lorem ipsum.

## States & responsiveness
- Include empty state with helpful CTA
- Include loading / skeleton state
- Include error state with recovery action
- Include responsive mobile layout

## Accessibility
- Semantic HTML, labels on inputs, visible focus rings, keyboard-usable controls.
- Sufficient color contrast for text and icons.

## Constraints
- Production-ready structure; keep components composable.
- Do not add a full charting library; CSS sparkline placeholders are fine.

## Deliverable
- A complete, copy-pasteable implementation of the UI described above.

Build a card component for: first-run empty library state.

## Requirements
- Illustration placeholder area
- Headline “No prompts yet”
- Two sentences of guidance
- Primary CTA “Create prompt” and secondary “Import”
- Optional checklist of 3 getting-started tips

## Stack
Use React + TypeScript + Tailwind + shadcn/ui primitives where helpful.

## Visual direction
Generous spacing, airy layout, marketing-site feel.
Soft pastel accents, rounded corners, friendly tone.
Use a clear visual hierarchy. Prefer real-looking copy over lorem ipsum.

## States & responsiveness
- Include empty state with helpful CTA
- Include responsive mobile layout

## Accessibility
- Semantic HTML, labels on inputs, visible focus rings, keyboard-usable controls.
- Sufficient color contrast for text and icons.

## Constraints
- Production-ready structure; keep components composable.
- No placeholder stock photos unless essential; use simple shapes or initials.

## Deliverable
- A complete, copy-pasteable implementation of the UI described above.

Build a data table with actions for: team members admin list.

## Requirements
- Columns: Name, Email, Role, Status, Last active
- Row actions: Edit role, Deactivate
- Toolbar: search input, role filter, Invite button
- Pagination controls
- Confirm dialog pattern described for Deactivate

## Stack
Use Next.js (App Router) + React + TypeScript + Tailwind CSS.

## Visual direction
Compact density for data-heavy interfaces.
Neutral professional palette, subtle borders, no neon gradients.
Use a clear visual hierarchy. Prefer real-looking copy over lorem ipsum.

## States & responsiveness
- Include empty state with helpful CTA
- Include loading / skeleton state
- Include error state with recovery action
- Include responsive mobile layout

## Accessibility
- Semantic HTML, labels on inputs, visible focus rings, keyboard-usable controls.
- Sufficient color contrast for text and icons.

## Constraints
- Production-ready structure; keep components composable.
- Prefer semantic table markup; do not fake a table with div soup if avoidable.

## Deliverable
- A complete, copy-pasteable implementation of the UI described above.

v0 prompts vs Cursor prompts vs design handoff

When the UI must land inside a living codebase with minimal blast radius, switch to Cursor prompts. For general prompt systems, see AI prompts and the coding & development world.

Iteration patterns that stay clean

Change one axis per follow-up: only spacing, only mobile nav, only empty state copy. Bundle ten aesthetic wishes into one message and you will not know which instruction caused a regression. Keep the original spec in PromptFork so you can regenerate from a known-good baseline instead of a corrupted chat tail.

When v0 invents a dependency you do not want, add a constraint line and regenerate the affected section rather than hand-deleting for an hour. When it invents content, replace with quoted product copy in the requirements list. The prompt is the source of truth; the canvas is the compile output.

For design systems, feed token names you actually have: “use existing --color-accent,” “match rounded-xl cards.” Without token hooks, the tool will invent a parallel system you must reconcile later. Constraints are cheaper than refactors.

Accessibility is not a final coat of paint. If you only mention a11y after the visual is “done,” you will fight structure. Include it in the first prompt so labels and semantics are native to the component tree.

When the generated UI is wrong

From v0 draft to production

Generate the shell in v0, drop it into the repo, then use Cursor (with a structured task prompt) to wire data, auth, and edge cases. Do not ask v0 to understand your entire backend in one breath; do not ask Cursor to invent a marketing page without a UI spec. Different tools, different briefs.

Save specs that worked — pricing, settings, empty states — as forks on PromptFork. The next feature starts from a proven skeleton. Supercharge → Studio helps when your rough notes need to become a clean requirements list.

Explore community starting points on Explore and Top, and browse Platforms when you need model-specific hubs beyond UI generation.

Finally, keep taste. A perfect prompt will not choose your product strategy. Decide the user job first, then encode it. The builder removes forgotten states and fuzzy stacks; it does not replace product thinking.

Content design is half the prompt

UI generators mirror the quality of the words you feed them. If every button says “Click here” and every headline says “Welcome,” the layout will look like a theme demo. Write the real CTA, the real empty-state headline, the real error message tone. Content design is not polish after engineering — for v0, it is structural input.

Hierarchy belongs in the requirements list: primary CTA versus secondary, which metric is hero versus supporting, which FAQ is first. Without hierarchy cues, generators flatten everything into equal cards and equal type sizes. Say “highlight the recommended plan” or “make the destructive action visually secondary.”

Internationalization and long copy are constraints too. If labels may grow 30% in translation, say so. If you need truncation rules on mobile, say so. Generators default to English happy-path lengths; products do not live there.

Voice matters for empty and error states especially. A playful empty state on a banking freeze screen is a bug. Include tone notes when the domain is sensitive: calm, direct, no humor. The builder’s free-text requirements field is the right place for those notes.

Design systems, tokens, and multi-screen kits

One screen is easy; a kit is hard. When you need settings, billing, and team admin to feel related, freeze the stack, density, theme, radius language, and button rules across prompts. Only swap purpose and structure. Save that frozen preamble as a PromptFork recipe titled with your product system name so every new screen starts on-brand.

Token hooks beat color poetry. “Use existing accent token” outperforms “a vibrant blue that feels trustworthy.” If you do not have tokens yet, define a tiny temporary system in the prompt: neutral surfaces, one accent, one danger, 8px spacing scale. Consistency is a constraint you write down.

Component boundaries should be intentional. Ask for composable pieces with names — `PricingCard`, `BillingInvoiceRow` — when you plan to rearrange later. A single monolithic page component is fine for a spike and painful for a product. State the intended split when you know it.

After v0, use Cursor prompts to integrate: wire loaders, attach real endpoints, respect auth gates. The UI spec gets you pixels; the coding agent brief gets you behavior. Keeping those prompts separate keeps each tool in its strength zone.

From one great prompt to a reusable system

One excellent v0 prompt drafts a screen. A library of them drafts a product. Fork pricing, settings, empty states, and tables as living templates. That is how PromptFork turns UI generation from a party trick into a repeatable front-end practice — find, copy, fork, save, and stop re-explaining your stack every time you open a blank canvas.

Related tools

Questions people ask about v0 prompts