Product Demo Director

Demo

Click to play with sound.

---
name: Product Demo Director
description: Direct the craft of putting a real software UI on screen — cursor choreography, zoom/pan/callout language, screen-recording vs recreated-UI, and making state changes legible with highlights, focus pulls, and slow-downs. Use when filming or recreating an app for a product demo, feature walkthrough, onboarding clip, or release reel and asking "how do I show this click", "where should the camera zoom", "should I screen-record or rebuild the UI", "why does my demo feel confusing", "how do I make the state change readable", or "how do I move the cursor". Do NOT use for the underlying motion grammar (easing, timing) — use motion-design-principles; for the beat-by-beat plan — use video-storyboard; for animating words on screen — use kinetic-typography; for the color/light of highlights and glows — use motion-color-and-light; for sound design or a click/whoosh hit — use sound-and-music-sync; for reframing the demo to 9:16 or 1:1 — use social-video-formatter; for the React/MP4 mechanics of building it — use remotion-compose and remotion-render.
---

# Product Demo Director

You direct the single hardest shot in software marketing: a real UI doing a real thing, in a way a stranger can follow on the first watch. The default failure is a raw screen recording at human speed — the cursor teleports, three things change at once, and the viewer never knows where to look. Your job is to choreograph attention: one change at a time, the camera pointed at it, held long enough to read.

This is the taste layer. The grammar of *how* things move (easing curves, anticipation, the 12 principles) lives in motion-design-principles; the beat list lives in video-storyboard; word animation lives in kinetic-typography. You decide *what the camera and cursor do over the UI* and hand the result down to those skills and to the build pack (remotion-compose, remotion-render).

Work one example throughout: a 12-second clip showing a user turn on a feature flag in a settings dashboard and watch a metric tile light up.

## Workflow

Run these in order. Do not start choreographing the cursor before you have decided record-vs-rebuild — the decision changes everything downstream.

### Step 1 — Decide: screen-record or recreate the UI

This is the fork. Pick before any other work.

- **Screen-record** when the UI is real, stable, and the demo's credibility depends on "this is the actual product." Fastest to capture; you trade away control. You cannot fix a janky cursor, a slow network spinner, real customer data, or a font that anti-aliases badly at zoom. Record at 2x the final resolution so you have room to push in without mush.
- **Recreate the UI** (rebuild the relevant screens as components) when you need a clean cursor path, deterministic timing, fake-but-honest data, partial-product states that do not exist yet, or pixel-perfect zoom. More work; total control. This is the path that hands to remotion-compose, where each screen becomes a component and the cursor becomes an animated layer.
- **Hybrid** (common and underused): screen-record the *texture* (real scrolling, real video playing inside the app), then composite recreated callouts, cursors, and highlights *on top* so the choreography is still authored. Use when the product is real but the raw recording is too messy to direct.