Vidéo de lancement pour un produit logiciel
Produisez une vidéo de 30 à 60 secondes qui fait comprendre et désirer le produit.
La décision qui façonne tout : reconstruire, ne pas enregistrer
Les enregistrements d'écran vous combattent. La latence réelle, c'est du silence mort. Les reprises coûtent cher. Vous ne pouvez pas figer une image, vous ne pouvez pas ralentir un rythme et en accélérer un autre, et vous ne pouvez pas recadrer serré sans tomber dans la compression.
Alors reconstruisez l'interface utilisateur en tant que React piloté par les images dans Remotion. Chaque visuel est une
fonction pure de useCurrentFrame(). La frappe arrive sur une courbe exacte, un
état de chargement se résout sur le rythme, et une reprise coûte un nombre.
Ce n'est raisonnable que parce que vous pouvez lire le code réel du produit (si local) ou son DOM+CSS (si hébergé) et le reproduire fidèlement. Faites cela — prenez les vrais noms de classe, les vraies couleurs, les vrais textes. La reconstruction doit être indiscernable d'un enregistrement, puis meilleure.
Quand enregistrer à la place : 3D lourd, contenu vidéo à l'intérieur du produit, une
surface canvas/WebGL, ou une application de bureau native. Si une surface spécifique ne peut pas être
reconstruite, enregistrez uniquement cette surface et compositez-la avec <OffthreadVideo>.
Phase 1 — Comprendre le produit
Lisez references/discovery.md avant de commencer cette phase. Il couvre la
procédure de navigation et de tri, la conversation sur les identifiants, et comment extraire
un système de design d'un site en ligne.
Version courte :
- À partir d'une URL : naviguez. La page d'accueil d'abord (elle vous dit comment ils se positionnent), puis l'application elle-même. Comprenez quel travail le produit fait pour qui.
- À partir d'un dépôt local / serveur de dev : lisez le code. Bien plus riche — vous obtenez les vrais composants, les vraies variables de thème, les vraies données de démonstration.
- Triez les pages. La plupart des produits ont 20 écrans et 3 qui comptent. Authentification, paramètres, facturation, confidentialité, compte, onboarding générique — ce sont presque jamais l'histoire. Trouvez l'écran où le produit fait la chose que lui seul peut faire.
- Si le contenu intéressant est derrière une connexion, demandez d'abord — des identifiants de test, ou un
compte amorcé dans leur environnement de développement local. Si aucun n'est disponible, n'abandonnez pas
et ne simulez pas une session que vous n'avez jamais vue : passez à la forme chapitrée et
construisez à partir des propres cartes de fonctionnalités, textes et composants de la page d'accueil.
discovery.mdcontient la procédure de récolte et les règles d'honnêteté.
Confirmez ensuite votre compréhension avec l'utilisateur avant de construire — une mauvaise lecture du produit coûte toute la construction. Montrez-lui : ce que vous pensez que le produit fait, les 2 à 4 écrans que vous prévoyez de présenter, le scénario héroïque, la liste des plans, et la question sur la musique (voir Phase 4). Un point de contrôle, puis exécutez.
Phase 2 — Choisir la forme
Lisez references/structure.md. Deux formes fonctionnent ; mal choisir coûte la
construction.
Forme A — le récit unique. La valeur par défaut. Un utilisateur faisant un travail et obtenant un artefact. Pas un tour des fonctionnalités.
| temps | action |
|---|---|
| Accroche (0–5s) | Énoncez le problème dans les propres mots du spectateur. Pas encore d'interface. |
| Demande (5–12s) | L'utilisateur demande la chose. Serré sur l'entrée. |
| Travail (12–25s) | Le produit fait visiblement quelque chose de difficile. Montrez les preuves. |
| Artefact (25–35s) | La sortie, en entier, en taille lisible. |
| Contrôle (35–45s) | L'utilisateur la modifie et reste aux commandes. |
| Générique (45–50s) | Logo, une ligne, domaine. |
Les temps de Travail et Contrôle sont ce qui distingue une vraie démonstration d'une maquette. « Il m'a demandé au lieu de deviner » et « Je pouvais éditer ce qu'il a créé » sont des arguments de confiance, et la confiance est ce que vend réellement une vidéo de lancement.
Choisissez le moment où le produit fait quelque chose qu'une personne ne pourrait pas facilement faire elle-même, et rendez la sortie concrète et visible — un document généré, un graphique construit, un bug corrigé, un site déployé. Les artefacts concrets sont ce dont les gens se souviennent.
Forme B — le film chapitré. Trois fonctionnalités, chacune introduite par une carte de libellé en langage simple, puis montrée.
accroche → [01 libellé → fonctionnalité] → [02 libellé → fonctionnalité] → [03 libellé → fonctionnalité] → générique
Utilisez-la lorsque le produit est verrouillé et que vous travaillez à partir de sa page d'accueil, ou lorsque les fonctionnalités ne partagent vraiment pas un parcours utilisateur, ou lorsque vous voulez trois clips indépendants à partir d'une seule construction. Trois est le nombre — quatre signifie qu'aucun ne marque les esprits.
Ne chapitre pas une séquence. Si les capacités se produisent les unes après les autres dans une session unique (recherche → brouillon → édition), c'est un seul workflow, et le labelliser comme trois fonctionnalités lutte contre le matériel. Si quelqu'un demande des chapitres sur un produit séquentiel, proposez plutôt la voie médiane : gardez le récit unique et mettez les libellés sur l'action à mesure que chaque capacité apparaît. Même lisibilité, mêmes limites de clip, aucun coût de durée, histoire intacte.
structure.md couvre la conception des cartes de chapitre, comment écrire les libellés (nommez le
résultat, pas le mécanisme ; reprenez les propres mots du produit), les transitions, et l'ordre.
Phase 3 — Ancrez tout
Quel que soit le domaine du produit, n'inventez pas son contenu. S'il s'agit d'un produit juridique, la loi doit être réelle. S'il s'agit d'analytiques, les chiffres doivent être plausibles et cohérents en interne. S'il s'agit d'un outil de code, le code doit se compiler dans la tête du lecteur.
Tirez la chose réelle du dépôt, de l'API, des données de démonstration ou de la documentation. Les experts du domaine regardent ces vidéos et un seul détail inventé vous coûtera tous. Il est acceptable d'inventer les noms des parties, les dates et les montants en dollars — ceux-ci sont spécifiques à un client, pas des affirmations sur le monde.
Conservez une note de provenance dans le fichier de données indiquant d'où vient chaque fait. Le vous futur en aura besoin.
Phase 4 — Construire
Exécutez l'échafaudage, qui épingle les versions qui fonctionnent réellement ensemble et écrit la configuration :
python3 <skill-dir>/scripts/scaffold_video.py <target-dir> \
--name "lancement-produit" --fps 60 --secondes 45
Il crée un projet Remotion autonome (son propre dépôt git — n'ajoutez jamais d'outillage vidéo
au dépôt du produit sauf demande contraire), copie useCamera.ts, et
vous laisse un module de timeline à remplir.
Ensuite, dans l'ordre :
-
src/timeline.ts— calcul des images et limites des plans. Choisissez un BPM dont le temps est un nombre entier d'images (à 60fps : 120 BPM = 30 images, 90 BPM = 40). Mettez chaque limite de plan sur un temps. Même sans musique, cela donne à la coupe un rythme interne, et cela signifie qu'une bande musicale peut être ajoutée plus tard sans ré-éditer. -
src/data/script.<lang>.ts— chaque chaîne, chaque nombre, chaque morceau de contenu de document, dans un seul fichier avec des commentaires de provenance. Rien de codé en dur dans les composants. Le ré-étalonnage et la traduction deviennent triviaux. -
Composants — recréez l'interface utilisateur du produit. Copiez les vrais noms de classe. Si le produit utilise Tailwind, apportez sa configuration et son CSS de thème ; s'il utilise des variables CSS pour les couleurs, vous devez les ramener ou tout s'affichera sans couleur.
-
src/scenes/ProductScene.tsx— un objetBexporté contenant chaque temps comme un numéro d'image absolu. Tout le monde lit à partir de là : le DOM, la caméra, le son. Ré-étalonner signifie éditer ce bloc et rien d'autre.
Lisez references/camera.md pour le système de plans, references/motion.md pour
les durées et la typographie.
Phase 5 — Audio
Deux pistes, deux fichiers, deux balises <Audio> : effets et musique. Gardez-les
séparés afin que l'un ou l'autre puisse être remplacé sans régénérer l'autre.
Effets — references/sound.md. La retenue est toute la discipline : une
vidéo de 45 secondes nécessite généralement trois à cinq événements au total. Un « pop » signifie qu'une chose
est apparue, un « swish » signifie qu'un élément s'est déplacé à l'intérieur du plan, un « whoosh » signifie que le plan a bougé.
python3 <skill-dir>/scripts/make_sfx.py sfx.spec.json public/sfx.wav
Musique — references/music.md. Demandez avant d'en construire une. La plupart des gens
ont un avis et beaucoup ont déjà un morceau ; demander coûte une phrase et peut
économiser tout l'effort :
Voulez-vous une bande musicale ? Si vous avez un morceau, envoyez-le et je couperai dessus. Si non, je peux en synthétiser un — énergique, calme, cinématique, minimal, chaleureux, ou tendu ?
S'ils ont un morceau, coupez dessus : trouvez son BPM, réglez la timeline pour correspondre, déplacez les limites de plan sur ses mesures. Sinon, synthétisez une bande dont les changements d'arrangement atterrissent sur vos coupes à l'image :
python3 <skill-dir>/scripts/make_music.py music.spec.json public/musique.wav
Mettez une entrée sections sur chaque limite de plan réelle, une entrée hits sur votre
plus grande coupe, et une entrée ducks sous toute ligne maintenue que vous souhaitez lire plutôt que
ressentir. Musique à ~0.30 de pic, effets à ~0.62. Choisissez l'ambiance en fonction de ce que le produit
est — un sujet sérieux nécessite une bande plus calme, et une coupe chargée a besoin
d'une plus clairsemée.
Phase 6 — Vérifier avec des images fixes, avant de rendre
C'est la boucle serrée, et la sauter fait perdre des heures.
npx remotion still <CompositionId> out/f0700.png --frame=700
Ensuite, regardez vraiment le PNG. Rendez une image fixe par plan, plus une à chaque transition. Vérifiez : le sujet est-il dans le cadre, quelque chose est-il coupé au milieu d'un mot, y a-t-il de l'espace vide, le texte tient-il.
Ajoutez une composition silencieuse (defaultProps: { withAudio: false }) afin que les images fixes
n'aient pas besoin que le fichier audio existe.
Réglez numériquement chaque fois que vous le pouvez. Les courbes d'assouplissement, les distances de défilement, le contenu spectral — tout cela est calculable. Écrivez un script Python jetable qui échantillonne la courbe et imprime ce que vous devriez autrement deviner. C'est plus rapide qu'un rendu et c'est correct.
Ne rendez l'intégralité que lorsque les images fixes sont correctes.
npx remotion render <CompositionId> out/video.mp4 --concurrency=4
Limitez la concurrence à environ 4 sur une machine de 16 Go — Remotion lance un onglet Chrome par emplacement et la valeur par défaut (nombre de cœurs) va swapper.
Phase 7 — Remettez honnêtement
Envoyez le fichier. Dites ensuite clairement :
- Ce que vous n'avez pas pu vérifier. Vous pouvez lire des images fixes ; vous ne pouvez pas juger comment huit secondes se sentent, et vous ne pouvez pas entendre l'audio. Dites-le.
- Tout écran que vous avez reconstruit plutôt qu'observé — surtout sur un produit verrouillé. Listez-les, et proposez de refaire ces temps s'ils veulent partager l'accès.
- Où vous avez pris une décision avec laquelle ils pourraient être en désaccord.
- Comment changer la musique : déposez n'importe quel WAV ou MP3 dans
public/music.wavet re-rendez. - Tout ce que vous avez trouvé dans leur produit en construisant — un bug de rendu, une mauvaise étiquette, un état manquant. Vous venez de lire leur interface utilisateur plus attentivement que la plupart des gens ne le feront jamais. Cette observation vaut souvent plus que la vidéo.
Fichiers de référence
Lisez-les lorsque vous atteignez la phase pertinente — ils sont détaillés et il n'y a aucun intérêt à tous les charger d'un coup.
| fichier | quand |
|---|---|
references/discovery.md | Phase 1 — navigation, tri des pages, identifiants, systèmes de design, et construction à partir de la page d'accueil d'un produit verrouillé |
references/structure.md | Phase 2 — récit unique vs chapitres, conception des cartes de chapitre, écriture des libellés de fonctionnalités, transitions, ordre |
references/camera.md | Construction des plans — espace de disposition, caméra à point focal, coupe vs poussée vs morphose, isolation des composants |
references/motion.md | Durées d'animation, typographie, motifs d'accroche, le rouleau de questions |
references/sound.md | Conception sonore — le vocabulaire pop/swish/whoosh, retenue, synthèse du clavier et des clics |
references/music.md | Trouver vs synthétiser une bande, choisir une ambiance, aligner les sections sur les coupes, mixer sous les effets |
references/pitfalls.md | Lisez ceci avant votre premier rendu. Bugs qui coûtent de vraies heures, chacun avec le correctif. |
Scripts intégrés
<skill-dir> ci-dessous est le propre répertoire de cette compétence — le chemin qui vous a été donné lorsque
la compétence a été chargée. Ne supposez pas un emplacement d'installation fixe ; la compétence peut être
installée personnellement, en tant que plugin, ou extraite dans un projet.
| script | quoi |
|---|---|
scripts/scaffold_video.py | Crée le projet Remotion avec des épingles de version fonctionnelles et une configuration |
scripts/make_sfx.py | Synthétise une piste d'effets sonores à partir d'une liste d'événements JSON. Pas d'échantillons, pas de dépendances au-delà de numpy. |
scripts/make_music.py | Synthétise une bande musicale dans l'une des six ambiances, avec son arrangement aligné sur votre coupe. Mêmes dépendances. |
assets/useCamera.ts | Le crochet de caméra à point focal — copiez dans src/hooks/ |
assets/ChapterCard.tsx | Carte de chapitre pour la forme chapitrée — copiez dans src/components/ |
La version courte
Reconstruisez plutôt que d'enregistrer. Une histoire, un artefact — sauf si le produit est verrouillé ou si ses fonctionnalités sont vraiment distinctes, alors trois chapitres avec des libellés simples. Ancrez chaque fait du domaine. Les images sont l'unité de tout. Isolez un composant plutôt que de recadrer la page. Le mouvement de l'interface utilisateur est de 150 à 300 ms, les mouvements de caméra sont d'environ 1 s. Quatre sons suffisent. Demandez avant de faire de la musique. Regardez les images fixes avant de rendre. Dites ce que vous n'avez pas pu vérifier et ce que vous avez déduit.