CaptureBeamDemo compiler
Playbook

From Storybook to product demo in 60 seconds

Component-level demos from Storybook URLs: the playbook for design-system teams who want their components to be motion-ready everywhere they ship.

2026-04-01 · 4 min read

Your design system has a Storybook with a story for every component variant. The marketing site shows static screenshots that go stale every quarter. The design-system team has a website with no live examples. Bridging Storybook and marketing is no one's job.

Or it isn't until the bridge is a YAML. Here's the playbook.

Step 1 — point CaptureBeam at a Storybook URL

Storybook lets you encode a story's args in the URL. So a Button component in its loading state is just:

https://design.example.com/?path=/story/button--default&args=loading:true

That URL is reproducible. It's the perfect target for a YAML.

Step 2 — author a tiny YAML per story

# demos/storybook/Button-loading.yaml
title: "Button — loading state"
preset: paper
aspect: "1:1"
quality: 1080p
steps:
  - goto: https://design.example.com/?path=/story/button--default&args=loading:true
  - hover: { role: "button", name: "Click me" }
  - click: { role: "button", name: "Click me" }
  - wait: 1500
    caption: "Loading state spins for 1.5s"

Five lines. Renders a polished motion clip showing the button hover → click → loading state. Because the source is a Storybook URL, the demo always shows the latest design tokens.

Step 3 — re-render on every design-system release

Hook the design-system release pipeline to re-render every demo when a token bumps. Bump --accent from blue to violet? Every component demo regenerates with the new color, automatically. The marketing site doesn't even know the design system shipped a change.

Why this is leverage for design-system teams

Design systems live and die by adoption. Adoption goes up when the components feel real — when prospective adopters can see them moving, responding, behaving. Static screenshot-based component galleries are a poor proxy for that.

Component-level demo videos are the proxy. They show the component in motion, in its actual styling, with its actual interaction states. Building a hundred of these by hand isn't feasible. Building a hundred when each is five lines of YAML is a Friday afternoon.

The whole playbook

  1. Fork your Storybook stories list into a /demos/storybook directory of YAMLs.
  2. Each YAML hovers, focuses, clicks, and asserts on the right roles.
  3. A CI hook re-renders all of them on every design-system release.
  4. Embed the resulting MP4s on your design-system site, your marketing pages, your docs.
  5. Watch your design-system adoption rate budge in the right direction for the first time in a year.

That's the whole playbook. Sixty seconds per demo, once you're in the rhythm. The alternative is hand-recording every component every time the design system ships, and that's nobody's favorite Friday.

Demos as code, in your repo, regenerating on every UI change.

$19.99/mo or $199/yr. Render through the dashboard or via the API — same access either way.