Share Live Prototypes with Vercel Preview Deploys

Why This Matters for Your Design System

“Can you deploy it so I can see it on my phone?” If you have ever typed that sentence in Slack, this workflow saves you from ever typing it again.

Vercel gives every pull request its own live URL. Automatically. An engineer opens a PR to update a button component, and 90 seconds later you have a link you can tap on your phone, drop into a design critique, or send to a stakeholder. No staging server. No DevOps ticket. No waiting until next Thursday. Every token change, every component update is reviewable in a real browser before it merges.

---

Step 1: Connect Your Repository to Vercel

Go to vercel.com and sign in with your GitHub account.

1. Click “Add New Project”
2. Select your GitHub repository from the list
3. Vercel will auto-detect your framework (Next.js, Vite, Astro, plain HTML, etc.)
4. Review the build settings. For a Storybook project, you may need to set:
   • Build Command: npm run build-storybook
   • Output Directory: storybook-static
5. Click “Deploy”

Vercel will run your first build and deploy it to a production URL like your-project.vercel.app.

Why this step matters: This one-time connection is all you need. Once your repository is linked, Vercel watches for every push and every pull request automatically. You will never need to manually deploy again. The platform handles builds, hosting, SSL certificates, and CDN distribution.

---

Step 2: Open a Pull Request and Get a Preview URL

Now comes the part that changes your review workflow. When anyone on your team creates a pull request, Vercel automatically:

1. Builds the branch
2. Deploys it to a unique preview URL
3. Posts a comment on the PR with the link

The preview URL looks something like:

https://your-project-git-feature-update-button-yourteam.vercel.app

Click the link and you are looking at the live build of that branch. Every component, every page, every interaction, exactly as it would appear in production.

The preview updates automatically when new commits are pushed to the branch. So as the engineer iterates on the PR, you always see the latest version without refreshing or redeploying anything.

Why this step matters: Preview deploys remove the biggest bottleneck in design-to-engineering feedback: access. Instead of asking “can you deploy this so I can review it?”, you click a link that is already waiting for you in the PR. Feedback cycles that took hours now take minutes.

---

Step 3: Review and Share with Stakeholders

Preview URLs are not behind any login wall. Anyone with the link can view the deploy. This makes them perfect for:

Design reviews: Open the preview on your phone to test responsive behavior. Compare it side-by-side with your Figma designs. Check hover states, focus states, and transitions that cannot be prototyped in design tools.

Stakeholder feedback: Share the link in Slack or email. Instead of sending static screenshots with annotations, you send a live, interactive build. Stakeholders can click around, resize their browser, and experience the actual product.

Cross-browser testing: Open the preview URL in Chrome, Safari, Firefox, and Edge. Verify that your components render consistently across browsers without needing a testing tool.

Add your feedback directly to the pull request as a comment. This keeps the design conversation attached to the code change that triggered it, creating a clear record of decisions.

Why this step matters: Previews close the loop between design intent and implementation reality. When you can see the built component alongside the PR diff, your feedback becomes more specific and actionable. Instead of “the spacing feels off,” you can say “the gap between the icon and label is 12px but should be 8px, per the token spacing.component.gap.”

---

Step 4: Set Up Environment Variables for Full Functionality

Some projects need environment variables to work properly in preview deploys (API keys for a CMS, feature flags, or analytics tokens). Vercel lets you configure these per environment.

1. Go to your project in the Vercel dashboard
2. Navigate to Settings, then Environment Variables
3. Add your variables and select which environments they apply to:
   • Production: Your main deployed site
   • Preview: All preview deploys (from pull requests)
   • Development: Local development via vercel dev

For a design system documentation site, you might need:

STORYBOOK_FIGMA_TOKEN=your-figma-token
NEXT_PUBLIC_ANALYTICS_ID=your-analytics-id

Mark sensitive values as “Encrypted” so they are not visible in the Vercel dashboard after saving.

Why this step matters: Without the right environment variables, preview deploys might build but show broken features (missing images, empty data, failed API calls). Configuring these once ensures every preview deploy is fully functional, not a partially broken build that wastes reviewers’ time.

---

What You Get

• Automatic preview URLs for every pull request. No manual deploys, no staging servers.
• Live, interactive builds that anyone can access with just a link.
• Automatic updates when new commits are pushed to the branch.
• Production-identical builds. Vercel builds previews the same way it builds production, so what you see is what ships.
• Comment integration. The preview URL is posted directly to the PR, keeping everything in one place.
• Mobile testing. Open the preview URL on any device to test responsive behavior.

---

Common Pitfalls

• Build failures on preview. If your main branch builds but a feature branch does not, check for missing dependencies or environment variables specific to that branch’s code.
• Stale previews. Preview deploys are tied to the branch, not the PR. If you close and reopen a PR, the deploy might need to rebuild. Push a new commit to trigger a fresh build.
• Public URLs for private projects. Preview URLs are accessible to anyone with the link, even for private repositories. If you are working on confidential projects, enable Vercel’s password protection feature (available on paid plans) or use the Vercel toolbar’s comments feature for internal review.
• Build time costs. Each preview build uses build minutes from your Vercel plan. For teams with many active PRs, this can add up. Consider configuring ignored build steps to skip deploys for non-visual changes (like README updates).

---

Exercise

Open a pull request and review the preview on your phone

15 min

1. Connect the repo and ship a tiny change

   On Vercel, click Add New Project and connect the GitHub repo for your Storybook or docs site. Accept the auto-detected build settings. Once the first production deploy is green, create a new branch like test/preview-deploy, change one obvious thing (a heading, a button label), and open a pull request.

   • The first production deploy shows a working site at your-project.vercel.app
   • Vercel posts a comment on the pull request with a unique preview URL inside a couple of minutes
   • The preview URL opens without a login wall and shows your change, not the main branch

2. Review the preview on your phone and leave feedback on the PR

   Copy the preview URL into your phone. Open it on mobile and check responsive layout, tap targets, scroll behavior. Return to the pull request. Leave one concrete review comment that names the exact element and the exact fix (e.g., “Header padding drops to zero below the sm breakpoint, add py-4 to the container”).

   • You found at least one issue on mobile that was invisible on desktop
   • The review comment is attached to the pull request, not in Slack or email
   • The next commit on the branch rebuilds the preview automatically, no manual deploy required
   • Your feedback loop went from “ship to staging, wait, refresh” to “open the link, read, comment”