How to prototype in v0 with your design system

1. Gather the system the prototype should use

Collect the component source or documentation, semantic tokens, an approved screen, and any required providers or global styles. Confirm that the project can actually access these materials. A reference to a private repository is only useful when the tool has permission to read it.

Choose a few relevant components rather than supplying an unfiltered design archive. For a project creation flow, prioritize the form field, button, dialog, and notification patterns. Include examples that compile and describe what should happen in loading and error states.

2. Make reuse an explicit requirement

v0 documents design-system workflows for supplying your team’s components, tokens, and conventions. If that workflow is available in your account, follow its current setup instructions and review the generated starter. You can also make a small task clearer by including concrete component references and usage rules in the brief.

Tell the builder what to do when a needed component is missing. Asking for a short explanation before adding a variant is easier to review than discovering a second button system after the screen is complete. Keep credentials and private customer data out of the prompt.

Prototype a “Create project” flow using our existing design system.
Read the supplied component docs and token file first.
Reuse Button, TextField, Dialog, and the existing notice pattern.
Follow the approved settings screen for spacing and hierarchy.
Include empty, submitting, validation-error, and success states.
Use fictional content and describe any simulated behavior.
If a component or token is missing, explain the gap before adding it.
Report reused components and how you checked the final flow.

3. Correct the specific mismatch

Compare the preview with your reference at the same width. Check visual hierarchy, component choices, spacing roles, and the prominence of the main action. v0’s design mode supports selecting elements in the preview for refinement; check its documentation for current availability and limits.

Ask for one correction with a clear boundary. For example: “Use the existing secondary button for Cancel and preserve the dialog’s keyboard behavior.” Avoid a request to make everything “more premium,” which gives no shared standard for the next review.

4. Inspect reuse before calling the flow done

Review the generated code as well as the preview. A button may resemble your system while being a separate local implementation. Check import paths, supported props, new raw values, and any changes to shared components. Confirm that providers and global styles match the actual application setup.

Repeat the task with a long name, an invalid submission, and a narrow viewport. When moving work into the product repository, review the actual change and run the relevant checks there. CRRT can help preserve accepted visual corrections for a coding-agent handoff on supported project surfaces. Keep a person responsible for the final merge.

• Confirm shared components are imported rather than recreated.
• Review any new tokens or variants against the existing system.
• Test keyboard access and failure recovery in the complete flow.
• Document simulated operations before presenting the prototype to others.

Common questions