Explore UI Directions with Prompt-to-UI Tools — Behind a Throwaway Boundary

Tier: Foundation · Workflow area: Component development · Tools: v0, Claude artifacts, Cursor

Prompt-to-UI tools are the fastest ideation instruments frontend has ever had — and the fastest way to pollute a codebase with off-system markup if you paste their output straight into a PR. This playbook gives you a repeatable exploration loop with a hard line between "prototype" and "production."

When to use

• A layout question is genuinely opendashboard vs. wizard, sidebar vs. tabs, card grid vs. table — and words in a design review are not settling it.
• You need stakeholder reactions todaya clickable direction in front of a PM beats a static wireframe next week.
• A greenfield surface with no Figma yetmarketing pages, internal tools, admin panels where design capacity is thin.
• You want interaction feel, not just structurehover states, empty states, and transitions that a mockup cannot convey.

When NOT to use

• The design already exists in Figmago through the design-to-code pipeline (pb-09) instead; re-inventing an approved design is waste.
• The component must land on your design system todayuse instruction files and registry grounding (pb-02, pb-03); prompt-to-UI tools default to their own stack.
• The surface handles regulated or sensitive datathrowaway tools mean pasting requirements into third-party services; check your data policy first.
• You are tempted to "just clean it up and ship it"that instinct is precisely what this playbook exists to stop.

The recipe

1. 1.

   Write one exploration brief and reuse it verbatim across tools. Divergence between outputs should come from the model, not from you rephrasing. Keep the brief about the problem, not the implementation:

   Copy

   Design a billing-history screen for a B2B SaaS app. Users: finance admins
   who reconcile 50-500 invoices/month. Must support: filter by status
   (paid/overdue/void), date-range picker, bulk export, per-row actions
   (download PDF, resend). Density matters more than whitespace. Show the
   empty state and the "filters returned nothing" state too. Desktop-first,
   1280px. Do not use a data-fetching library; hardcode 12 realistic rows.
   

2. 2.

   Fan out to two or three generators in parallel. Paste the brief into v0 (v0.dev), a Claude artifact, and optionally a scratch Cursor project. For the Cursor variant, isolate it so nothing touches your repo:

   Copy

   mkdir ~/scratch/billing-explore && cd ~/scratch/billing-explore
   npm create vite@latest . -- --template react-ts
   cursor .
   

   In Cursor's agent panel, use the same brief with one addition: Build this as a single self-contained page in src/App.tsx. Inline styles or plain CSS only.

3. 3.

   Iterate each direction two or three times, no more. Prompt for variation, not polish — polish is a production concern:

   Copy

   Variant B: replace the table with grouped-by-month sections, sticky month
   headers, and move bulk actions into a selection toolbar that appears only
   when rows are checked.
   

   A good output at this stage looks like: three visibly different information architectures, each demonstrating the empty state, with realistic data — not three shades of the same table.

4. 4.

   Harvest decisions, not code. Screenshot each direction and write a decision note. This is the artifact that crosses the boundary — nothing else does:

   Copy

   DECISION NOTE — billing history exploration, 2026-08-05
   Chosen: v0 variant B (month-grouped) for scannability at high volume.
   Stolen ideas: selection toolbar from Claude variant, overdue-first sort
   from Cursor variant. Rejected: card grid (too sparse at 500 rows).
   States to spec: empty, no-results, single-row selection, 50+ selection.
   

5. 5.

   Re-implement on-system in your real repo. Start a fresh branch and build with your primitives, referencing only the screenshots and decision note. If you have instruction files (pb-02), this is where they earn their keep:

   Copy

   git checkout -b feat/billing-history
   claude
   

   Copy

   Implement the billing-history screen per docs/decisions/billing-history.md
   and the attached screenshots. Use only components from @acme/ui — Table,
   Toolbar, DateRangePicker, EmptyState. Match our token scale for spacing
   and color. Do not copy any code from the prototype.
   

6. 6.

   Delete the prototypes. Literally. rm -rf ~/scratch/billing-explore, delete the v0 chat, close the artifact. If the prototype survives, someone will ship it.

Make it yours

• React / Next.js teamsv0 is the strongest fan-out tool since it natively emits React + Tailwind + shadcn/ui; treat that as a rendering detail of the prototype, not a suggestion for your stack.
• Vue / Angular teamsv0's React output is still useful as a visual artifact; do Cursor or Claude-artifact explorations in your own framework (npm create vue@latest, ng new scratch-app --minimal) so interaction patterns translate directly.
• React Native / Flutter teamsprompt-to-UI tools are web-first, so use them only for information architecture and state inventory; do the interaction-feel exploration in Expo Snack (snack.expo.dev) or DartPad with the same brief, and keep the same throwaway rule.

Quality check

• Three distinct directions existed before you converged — if all outputs looked the same, your brief over-specified the solution.
• A written decision note exists naming the chosen direction, stolen ideas, and required states — reviewable by someone who never saw the prototypes.
• The production PR contains zero pasted prototype codespot-check by grepping for the prototype's telltale class names or component imports.
• The shipped screen passes your normal gatestypes, lint, axe scan, visual review — with no "it's from the prototype" exemptions.
• Prototypes are gonescratch directory deleted, v0/artifact history cleared or archived out of reach.