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.
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:trueThat 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
- Fork your Storybook stories list into a /demos/storybook directory of YAMLs.
- Each YAML hovers, focuses, clicks, and asserts on the right roles.
- A CI hook re-renders all of them on every design-system release.
- Embed the resulting MP4s on your design-system site, your marketing pages, your docs.
- 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.