Flowtake Storyboard guide
Community kit Contribute an example

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 Improve the kit on GitHub

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 copied by your browser. Flowtake does not upload the text or count the action.

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 is copied by your browser. Flowtake does not upload the text or count the action.

GitHub issues, pull requests, and discussions are public by default and may require GitHub sign-in. Never post email addresses, credentials, customer data, private repository details, unreviewed footage, or production access.

Filled example · Flowtake v1.7.2

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

This example uses the Flowtake recorder, editor, and local MP4/WebM 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 MP4 or WebM locally—with the edit's audio when present.”

    Planned evidence: format control and Include audio state when available, Completed state, and Folder/Play proof for a local export

  6. 0636–42s

    Hold on the end card

    “Free. Local-first. MIT app code.”

    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 privacy and safe-sharing boundary

Keep the kit free and useful

Use the plan, then contribute what improves.

Open a public issue or pull request with a sanitized example, clearer instruction, accessibility fix, or platform-specific capture tip.

Read the contribution guide Browse public issues