Flowtake Storyboard guide
Release Studio Get a public storyboard

Free planning template for maintainers

Plan a 45-second developer-tool demo in six beats.

Turn one public release workflow into a concise screen story. The template below gives each beat a purpose, visible proof, and a sensitive-content exclusion before capture begins.

Use the six-beat template Get a public storyboard

The 45-second timing is an editorial starting point, not a performance benchmark or a promise about audience response.

Six beats in about 45 seconds Public or synthetic sources only One observable result and one CTA

Copy the structure, then replace the brackets

A six-beat storyboard for one real developer workflow.

Start with the visible result, earn it with one uninterrupted action, then make the handoff obvious. Every row includes a capture boundary so secrets and customer data stay out of the recording plan.

The timing is adjustable. Keep the sequence focused on one audience, workflow, result, and call to action.
Time and beat Screen action Narration prompt Visible proof Exclude from capture
0–4s Outcome hook Open on the completed output or final state. “[Audience] can now [specific result].” Release name and the result the viewer should remember. Customer names, notifications, private URLs, or unexplained claims.
4–10s Safe setup Show a local, public, or synthetic demo state and the starting control. “Start with [safe input] in [tool or feature].” Public version, sample project, and a clean source state. API keys, tokens, internal repositories, production access, or real user data.
10–22s One real action Complete the core task without jumping to unrelated features. “Use [feature] to [single action].” One uninterrupted state change in the real interface. Fabricated results, decorative clicks, or steps that do not affect the outcome.
22–31s Visible result Pause after the action so the outcome can be inspected. “The result is [observable output].” Result panel, generated file, preview, log, or other on-screen evidence. Metrics or benefits that are not visible and sourced in the take.
31–39s Handoff or export Show how the viewer saves, exports, shares, or continues the work. “Save or export [artifact] for [next step].” The real control, destination type, and public-safe filename. Private paths, usernames, customer destinations, or hidden follow-up work.
39–45s Single CTA Hold on one public next action long enough to read it. “Try [release], read [docs], or open [public page].” The exact project, release, documentation, or signup destination. Competing CTAs, false urgency, or unverified adoption and performance numbers.

The storyboard text is not uploaded when you copy it. Flowtake records only a cookie-free aggregate copy count.

View the plain-text template

Adapt the words and timing to the workflow. Do not compress away consent, security warnings, installation caveats, or setup steps the viewer needs to reproduce the result.

A brief another maintainer can understand

Write the capture boundary before the shot list.

A useful brief names the public source, the exact workflow edges, and what must never appear. Paste this into an issue, planning document, or your own production workflow.

  • Use a public project URL and a named release or feature.
  • Describe the first and last visible state, not a vague product category.
  • List synthetic or public-safe inputs before listing shots.
  • Choose one final action the viewer can take immediately.

The brief text is not uploaded when you copy it. Flowtake records only a cookie-free aggregate copy count.

The public storyboard clinic is visible to anyone and requires GitHub sign-in. Never post email addresses, credentials, customer data, private repository details, or production access.

Filled example · Flowtake v1.6.0

How the template maps a recorder-to-export workflow.

This example uses the published Flowtake recorder, editor, and local MP4 export path. It is deliberately limited to evidence available in the app and public repository.

Pre-production example—not customer work or a finished video. The six beats below are a capture plan. They do not claim that footage was recorded, a customer received a video, or the timing will produce a particular result.

  1. 010–3s

    Open the recorder

    “Record the build once.”

    Planned evidence: Flowtake brand and recorder shell

  2. 023–10s

    Select safe sources

    “Capture the IDE, terminal, browser, or desktop.”

    Planned evidence: source controls and recording state

  3. 0310–18s

    Open the saved take

    “Keep the take editable.”

    Planned evidence: project handoff and timeline

  4. 0418–28s

    Shape one motion beat

    “Shape the motion around the explanation.”

    Planned evidence: preview, properties, and timeline response

  5. 0528–36s

    Export locally

    “Export locally with FFmpeg.”

    Planned evidence: export controls and a locally rendered MP4

  6. 0636–42s

    Hold on the end card

    “Free. Local-first. MIT licensed.”

    Planned evidence: public repository and download action

Safe capture is part of the storyboard

Make every source reviewable before recording.

Prefer a local fixture, public repository, synthetic account, or disposable test environment. Close notifications and password managers, remove tokens from terminals, and inspect filenames, browser tabs, logs, and recent-file menus before capture.

Flowtake is local-first for ordinary recording, project, and export work, but some explicit features can make network requests. Do not describe a workflow as fully offline unless every feature in the take has been verified that way.

Read the Release Studio privacy and file-handling boundary

Bring one public workflow

Get a six-beat plan before you record.

Through July 23, 2026, up to the first three maintainers with a complete public developer-tool workflow can request a no-obligation storyboard.

Get a public storyboard See Release Studio scope