Figma and v0
Purpose and Scope
This page explains how the shadcn/ui documentation supports design handoff and component customization through two reader-facing surfaces: community Figma resources and the Open in v0 workflow. A design handoff is the path from a visual specification to working application code. In shadcn/ui, that path is intentionally different from a closed component-library workflow because the project gives teams the component code they will actually run. Designers can work from Figma kits that mirror the component system, while developers can open documented components in v0, customize them in natural language, and paste the resulting code into an app.
Sources: apps/v4/content/docs/(root)/figma.mdx, apps/v4/content/docs/(root)/_v0.mdx, apps/v4/content/docs/(root)/index.mdx
The root introduction is the conceptual anchor for these workflows. It states that shadcn/ui is not a traditional component library but a way to build your own component library. That matters for Figma and v0 because neither tool is treated as the source of an immutable upstream package. Instead, the visual artifact, the generated or edited component, and the code installed in the application are all expected to converge around open, editable component files. The project’s terms are Open Code, Composition, Distribution, Beautiful Defaults, and AI-Ready, and each term maps directly onto how handoff should be evaluated.
Sources: apps/v4/content/docs/(root)/index.mdx
Relevant Source Files
- apps/v4/content/docs/(root)/figma.mdx - Defines the Figma page, including the community-maintained free and paid Figma resources and the maintainer note for feedback.
- apps/v4/content/docs/(root)/_v0.mdx - Defines the Open in v0 page, including the promise that every component on ui.shadcn.com is editable in v0, the account requirement, and the linked onboarding resources.
- apps/v4/content/docs/(root)/index.mdx - Defines the repository’s first-party positioning: Open Code, Composition, Distribution, Beautiful Defaults, and AI-Ready, which explain why design and AI customization workflows fit the project.
Core Concepts
Open Code means that the top layer of component code is available for modification after installation. For a design handoff, this changes the review loop. Instead of asking whether a package exposes the exact prop or theme override a designer requested, the team can inspect and edit the component source that lives in the project. The Figma resources are therefore best used as compatible design companions rather than as a contract that overrides local code. The local implementation remains the final source of truth, and the docs explicitly encourage customization and extension.
Sources: apps/v4/content/docs/(root)/index.mdx, apps/v4/content/docs/(root)/figma.mdx
Composition means that components share a predictable, composable interface. That predictability is useful when a Figma design is translated into application code because designers, developers, and AI tools can reason about repeated structure instead of learning an unrelated API for every component. The introduction explains that if a component does not exist, shadcn/ui brings it in, makes it composable, and adjusts styling to match the system. In practice, a handoff should identify the component structure, slots, variants, and styling decisions that need to survive when moving from the design file into editable project files.
Sources: apps/v4/content/docs/(root)/index.mdx
Distribution is the reason the same design system can move across projects. The introduction describes a flat-file schema and CLI for distributing and installing components with cross-framework support. Figma kits help the design team plan the interface, but the repository’s distribution model is what makes the implementation portable. A team can use the public catalog, registry content, or its own distributed components while still treating the installed files as editable. This is especially important for organizations that maintain a product-specific component library on top of shadcn/ui conventions.
Sources: apps/v4/content/docs/(root)/index.mdx
AI-Ready is the bridge between Open Code and v0. The introduction says open code is readable and improvable by language models, while the v0 page says every component on the site is editable on v0 by Vercel. The intended workflow is not simply to generate a screenshot-like clone. It is to start from a real shadcn/ui component, ask for targeted changes in natural language, and bring the result back into the application codebase. Because the code is visible and editable, the developer can review the output using normal engineering standards.
Sources: apps/v4/content/docs/(root)/_v0.mdx, apps/v4/content/docs/(root)/index.mdx
Figma Resource Workflow
The Figma page is a curated directory rather than a single official design package. It opens with a note that the Figma files are contributed by the community and directs questions or feedback to the maintainers of those files. This distinction is important for teams adopting a kit: the resources are useful accelerators, but compatibility and freshness should be checked against the component code and docs that the team is using. A designer should record which kit, version, or file section was used so that developers can compare visual assumptions with the installed component implementation.
Sources: apps/v4/content/docs/(root)/figma.mdx
The free section currently lists two community resources. The shadcn/ui components file by Sitsiilia Bergmann is described as a well-structured component library aligned with the shadcn component system and regularly maintained. The shadcn/ui design system by Pietro Schirano is described as a design companion where each component was crafted to match the code implementation. These descriptions indicate the intended use: begin with a design artifact that already understands shadcn/ui naming and styling conventions, then adjust it to the product’s theme, layout, and interaction requirements.
Sources: apps/v4/content/docs/(root)/figma.mdx
The paid section broadens the workflow for teams that want more blocks, templates, themes, or dedicated design-to-code features. The listed resources include shadcn/ui kit, shadcncraft Design System, shadcn/studio UI Kit, Shadcnblocks.com, Obra shadcn/ui Pro, and Shadcn Space. Several descriptions emphasize shadcn/ui compatibility, block libraries, theme variables, light and dark mode, Figma MCP readiness, AI-assisted workflows, Figma to React export, or modern React and Next.js workflows. Treat these as product options with different strengths, then validate output against the app’s component code and styling system.
Sources: apps/v4/content/docs/(root)/figma.mdx
A practical handoff should include more than a Figma link. Capture the chosen resource, the component names used, visual states, responsive behavior, color and radius decisions, icon choices, and any deviations from the default shadcn/ui look. The introduction’s Beautiful Defaults principle means the defaults are already designed to work together, so the handoff can focus on intentional differences rather than rebuilding the baseline. When a design introduces a custom variant or layout, document whether it should be implemented by editing an existing component, composing several components, or creating a new registry item for reuse.
Sources: apps/v4/content/docs/(root)/figma.mdx, apps/v4/content/docs/(root)/index.mdx
Open in v0 Workflow
The Open in v0 page defines v0 as the customization path for components on ui.shadcn.com. It states that every component is editable on v0 by Vercel and that this lets users customize components in natural language and paste them into an app. The workflow is intentionally lightweight: open the component, describe the change, inspect the result, and move the code into the project. Because shadcn/ui components are open code, the generated result should be reviewed as source code, not treated as an opaque artifact from a design tool.
Sources: apps/v4/content/docs/(root)/_v0.mdx, apps/v4/content/docs/(root)/index.mdx
The v0 page also sets account expectations. To use v0, readers are directed to sign up for a free Vercel account. The same page notes that the account also gives access to Vercel’s frontend cloud platform from the creators of Next.js, where projects can be deployed and hosted for free. It links separately to Vercel getting-started documentation and the v0 FAQ. For a team workflow, this means the design-to-code loop may involve both component customization and deployment review, but those steps remain downstream of the local code review process.
Sources: apps/v4/content/docs/(root)/_v0.mdx
Use v0 when the desired change is easier to describe visually or behaviorally than to write from scratch. Examples include changing the arrangement of a component, adapting a component to a brand tone, adding nearby supporting UI, or exploring a variation before committing to a final implementation. Use the Figma resources when the team needs a shared visual planning surface, stakeholder review, or a full design system inventory. The two workflows complement each other: Figma helps align intent before implementation, while v0 helps turn a documented component into editable code faster.
Sources: apps/v4/content/docs/(root)/figma.mdx, apps/v4/content/docs/(root)/_v0.mdx
System-to-Code Mapping
| Reader task | Documentation surface | What to verify in code |
|---|---|---|
| Choose a design kit | apps/v4/content/docs/(root)/figma.mdx | The selected kit’s components, tokens, and states match the project’s installed shadcn/ui code. |
| Customize a component with AI | apps/v4/content/docs/(root)/_v0.mdx | The v0 output is pasted into the right project files and reviewed as editable component code. |
| Explain why customization is expected | apps/v4/content/docs/(root)/index.mdx | The implementation follows Open Code, Composition, Distribution, Beautiful Defaults, and AI-Ready principles. |
The mapping is deliberately centered on reader tasks rather than vendor categories. A designer may start from a free or paid Figma file, but the implementation decision still flows through the shadcn/ui model: components are copied into the app, composed predictably, distributed through schema and CLI workflows when needed, and changed directly when the product requires it. A developer may start in v0, but the output should still be reconciled with the same local aliases, styling, accessibility expectations, and component conventions used everywhere else in the application.
Sources: apps/v4/content/docs/(root)/figma.mdx, apps/v4/content/docs/(root)/_v0.mdx, apps/v4/content/docs/(root)/index.mdx
Recommended Handoff Checklist
Before moving from design to implementation, identify the exact component or block being customized, the Figma resource or v0 conversation that informed it, and the intended product behavior. Confirm whether the change is a simple style adjustment, a new variant, a composition of existing components, or a new component that should be distributed. Then compare the final code against the repository’s principles: it should remain transparent, easy to modify, compatible with the surrounding component interface, visually consistent with the system, and understandable to both developers and AI-assisted tools.
Sources: apps/v4/content/docs/(root)/index.mdx
Next, decide where the customized code should live. If the work started from v0, paste the code into the application in the same style as other shadcn/ui components, then update imports, theme tokens, and supporting files as needed. If the work started in Figma, translate the design into the smallest practical component composition before adding extra abstraction. When the design represents a reusable pattern, consider documenting it internally or preparing it for registry distribution so future projects can install the same pattern instead of recreating the handoff manually.
Sources: apps/v4/content/docs/(root)/_v0.mdx, apps/v4/content/docs/(root)/figma.mdx, apps/v4/content/docs/(root)/index.mdx
Next Steps
Read the overview to understand why shadcn/ui treats component code as editable project code. Then use the installation and components pages to add the relevant implementation to your app before applying Figma or v0 changes. If your team plans to reuse the result across projects, continue to the registry pages so the customized component or block can be packaged and distributed with the same conventions used by the public catalog.