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, pas enregistrer
Les enregistrements d'écran vous combattent. La latence réelle est un temps mort. Les refaires coûtent cher. Vous ne pouvez pas figer une image, vous ne pouvez pas ralentir un temps et en accélérer un autre, et vous ne pouvez pas recadrer serré sans tomber dans la bouillie de compression.
Reconstruisez donc l'interface utilisateur comme du 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 temps, et une refaite coûte un nombre.
Ce n'est raisonnable que parce que vous pouvez lire le code réel du produit (s'il est local) ou son DOM+CSS (s'il est hébergé) et le reproduire fidèlement. Faites cela — prenez les vrais noms de classes, les vraies couleurs, le vrai texte. La reconstruction doit être indistinguable d'un enregistrement, puis meilleure.
Quand enregistrer plutôt : 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 composez-la avec <OffthreadVideo>.
Phase 1 — Comprendre le produit
Lisez references/discovery.md avant de commencer cette phase. Il couvre
toute la procédure de navigation et de tri, la conversation sur les identifiants, et la façon d'extraire
un système de design d'un site en ligne.
Version courte :
- Étant donné une URL : naviguez. La page d'accueil en premier (elle vous dit comment ils se positionnent), puis l'application elle-même. Déterminez quel travail le produit fait et pour qui.
- Étant donné un dépôt local/serveur de développement : lisez le code. Bien plus riche — vous obtenez les vrais composants, les vrais tokens de thème, les vraies données de test.
- Faites le tri des pages. La plupart des produits ont 20 écrans et 3 qui comptent. L'authentification, les paramètres, la facturation, la confidentialité, le compte, le onboarding — ce n'est presque jamais l'histoire. Trouvez l'écran où le produit fait la chose que seulement lui peut faire.
- Si ce qui est intéressant est derrière une connexion, demandez d'abord — des identifiants de test, ou un
compte pré-rempli 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 de la page d'accueil, du texte et des composants.
discovery.mdcontient la procédure de récolte et les règles d'honnêteté.
Confirmez ensuite votre lecture avec l'utilisateur avant de construire — une mauvaise lecture du produit coûte toute la construction. Montrez-leur : ce que vous pensez que le produit fait, les 2 à 4 écrans que vous prévoyez de mettre en avant, 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 lancez-vous.
Phase 2 — Choisir la forme
Lisez references/structure.md. Deux formes fonctionnent ; choisir la mauvaise coûte
la construction.
Forme A — le récit unique. La forme par défaut. Un utilisateur fait un travail et obtient un artefact. Pas une visite guidée des fonctionnalités.
| temps | action |
|---|---|
| Accroche (0–5s) | Énoncez le problème dans les propres mots du spectateur. Pas d'interface utilisateur encore. |
| 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) | Le résultat, en entier, à une taille lisible. |
| Contrôle (35–45s) | L'utilisateur le modifie et garde le contrôle. |
| Filtre (45–50s) | Logo, une ligne, domaine. |
Les temps 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 modifier ce qu'il a fait » sont des arguments de confiance, et la confiance est ce qu'une vidéo de lancement vend réellement.
Choisissez le moment où le produit fait quelque chose qu'une personne ne pourrait pas facilement faire element, et rendez le résultat concret 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é] → filtre
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 autonomes à partir d'une seule construction. Trois est le nombre — quatre signifie qu'aucun ne marque.
Ne chapitre pas une séquence. Si les capacités se succèdent dans une seule session (recherche → brouillon → édition), c'est un seul workflow, et l'étiqueter comme trois fonctionnalités combat la matière. Si quelqu'un demande des chapitres sur un produit séquentiel, proposez plutôt la voie du milieu : gardez le récit unique et mettez les libellés sur l'action au fur et à mesure que chaque capacité apparaît. Même lisibilité, mêmes limites de clip, pas coût de temps d'exécution, 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 — Ancrer 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'analytique, les nombres doivent être plausibles et cohérents en interne. S'il s'agit d'un outil de code, le code doit compiler dans la tête du lecteur.
Extrayez la chose réelle du dépôt, de l'API, des données de test ou de la documentation. Les experts du domaine regardent ces vidéos et un détail inventé vous coûte tous leurs regards. Les noms de parties, dates et sommes d'argent peuvent être inventés — ceux-ci sont spécifiques à un client, pas des affirmations sur le monde.
Gardez une note de provenance dans le fichier de données indiquant d'où chaque fait provient. Votre futur vous la voudra.
Phase 4 — Construire
Exécutez le script de base, qui fige les versions qui fonctionnent réellement ensemble et écrit la configuration :
python3 <skill-dir>/scripts/scaffold_video.py <target-dir> \
--name "product-launch" --fps 60 --seconds 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 si on vous le demande), 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 sonore 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 codé en dur dans les composants. Le retiming et la traduction deviennent tous deux triviaux. -
Composants — recréez l'interface utilisateur du produit. Copiez les vrais noms de classes. Si le produit utilise Tailwind, vendez sa configuration et son CSS de thème ; s'il utilise des variables CSS pour les couleurs, vous devez les importer, sinon tout s'affiche sans couleur.
-
src/scenes/ProductScene.tsx— un objetBexporté contenant chaque temps sous forme de numéro d'image absolu. Tout lit à partir de lui : le DOM, la caméra, le son. Retimer signifie éditer ce bloc et rien d'autre.
Lisez references/camera.md pour le système de prises de vue, 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 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 a généralement besoin de 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 s'est déplacé.
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 une opinion et beaucoup ont déjà un morceau ; demander coûte une phrase et peut
sauver tout l'effort :
Voulez-vous une bande sonore musicale ? Si vous avez un morceau, envoyez-le et je couperai dessus. Si non, je peux en synthétiser un — énergique, calme, cinématographique, minimal, chaleureux ou tendu ?
S'ils ont un morceau, coupez dessus : trouvez son BPM, réglez la timeline pour correspondre, déplacez les limites des plans sur ses mesures. Sinon, synthétisez une bande dont les changements d'arrangement tombent sur vos coupes à l'image :
python3 <skill-dir>/scripts/make_music.py music.spec.json public/music.wav
Mettez une entrée sections à chaque limite de plan réel, une entrée hits sur votre
plus grande coupe, et une entrée ducks sous toute ligne maintenue que vous voulez faire entendre plutôt que
ressentir. Musique au pic ~0.30, 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
en a besoin d'une plus clairsemée.
Phase 6 — Vérifier avec des images fixes, avant de rendre
C'est la boucle rapide, et la sauter fait perdre des heures.
npx remotion still <CompositionId> out/f0700.png --frame=700
Ensuite, regardez réellement 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 mort, le texte tient-il.
Ajoutez une composition silencieuse (defaultProps: { withAudio: false }) afin que les images fixes
n'aient pas besoin du fichier audio pour exister.
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 devineriez autrement. C'est plus rapide qu'un rendu et c'est juste.
Ne rendez l'ensemble qu'une fois les images fixes 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 échanger.
Phase 7 — Le remettre 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 ressentent, 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 partagent l'accès.
- Où vous avez fait un jugement avec lequel ils pourraient ne pas être d'accord.
- Comment changer la musique : déposez n'importe quel WAV ou MP3 dans
public/music.wavet refaites le rendu. - Tout ce que vous avez trouvé dans leur produit pendant la construction — un bug de rendu, un libellé erroné, 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 à les charger tous au début.
| 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 de libellés de fonctionnalité, transitions, ordre |
references/camera.md | Construction des plans — espace de mise en page, caméra à point de focalisation, coupe vs poussée vs morphose, isolation des composants |
references/motion.md | Durées d'animation, typographie, modèles 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, mixage sous les effets |
references/pitfalls.md | Lisez-le avant votre premier rendu. Des bugs qui coûtent de vraies heures, chacun avec le correctif. |
Scripts inclus
<skill-dir> ci-dessous est le répertoire de cette compétence elle-même — 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 versions de travail verrouillées et la configuration |
scripts/make_sfx.py | Synthétise une piste d'effets sonores à partir d'une liste d'événements JSON. Pas d'échantillons, aucune dépendance au-delà de numpy. |
scripts/make_music.py | Synthétise une bande sonore musicale dans l'une de six ambiances, avec son arrangement aligné sur votre coupe. Mêmes dépendances. |
assets/useCamera.ts | Le hook de caméra à point de focalisation — 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 que ses fonctionnalités sont vraiment séparées, 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 UI 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.