Guide7 min de lecture

Guide de la vidéo de journal des modifications

Transformez un seul changement livré en une histoire de version ciblée.

Préparez une vidéo de journal des modifications pour un seul changement livré, avec un scénario ciblé et une liste de vérification pour le contexte de version.

Voir comment ça marcheLes 60 premières secondes de vidéo sont gratuites, avec un filigrane.
Vérifiez votre adresse e-mail pour la télécharger.

Qu'est ce qui rend une vidéo de journal des modifications utile ?

Une vidéo de journal des modifications doit expliquer un seul changement livré, pas démontrer le produit entier. Elle donne aux lecteurs de version une courte réponse visuelle à une question étroite : quel était l'état antérieur, que peut faire une personne maintenant, et quel résultat visible en découle ? La note de version écrite reste la source de la portée complète, des limitations, et du détail technique.

Cette limite compte. Une vidéo de journal des modifications produit est ancrée à un changement livré nommé et à une construction indiquée. Une démo large est ancrée à un flux de travail produit qui peut couvrir plusieurs capacités. Quand un seul actif essaie de faire les deux, le lecteur ne peut pas dire quel comportement est nouveau, quel comportement existait déjà, ou si une affirmation séduisante fait réellement partie de la version.

Pour GogoScreen, un rendu planifié utilise une URL d'application web accessible et une ligne décrivant un flux. Ce n'est pas une preuve qu'un résultat existe, que la fonctionnalité a été livrée, ou qu'un premier rendu sera utilisable. Environ un rendu sur cinq peut échouer ou nécessiter une nouvelle tentative. L'actif de version final doit être vérifié par rapport à la construction réelle et à la note de version publiée, un candidat à la fois.

Comment choisir le seul changement à montrer ?

Choisissez un changement déjà livré qui compte pour le public qui reçoit la mise à jour. Il doit pouvoir être démontré avec une cible préparée contrôlée et doit avoir une différence visible entre l'état antérieur et le comportement actuel. Si la différence n'est qu'un détail d'implémentation sans résultat observable, expliquez le dans la note de version plutôt que de le forcer dans une vidéo.

Rédigez d'abord l'énoncé de version. Utilisez le même nom de fonctionnalité et la même portée dans le scénario, la légende, et le lien voisin. Ne transformez pas un petit ajout en une affirmation sur la performance, la fiabilité, la sécurité, ou une capacité produit plus large. Ne montrez pas de travail prévu, d'expérimentation, ou de fonctionnalité absente de la construction indiquée.

Un seul changement peut encore impliquer plusieurs écrans, mais chaque scène doit soutenir le même énoncé de version. Si la séquence commence à introduire une autre fonctionnalité, arrêtez et faites en son propre futur actif de version. Le lecteur doit repartir en sachant ce qui a changé, pas simplement que le produit a de nombreuses surfaces.

Comment doit fonctionner le scénario état avant, action, résultat ?

L'état avant doit établir la limitation pertinente ou le comportement antérieur sans exagération. Montrez juste assez de contexte pour qu'un lecteur de version comprenne pourquoi le changement compte. L'action montre ensuite comment la nouvelle capacité est utilisée. Le résultat rend le comportement modifié observable et donne à l'actif une fin claire.

Changement livré : un comportement nommé dans la construction indiquée
État antérieur : le comportement pertinent avant ce changement
Action visible : l'action qui utilise le changement
Résultat visible : le comportement modifié qu'un lecteur de version peut examiner

Par exemple, la structure pourrait être une vue de paramètres antérieure, une nouvelle sélection ou action, et l'état résultant. Le flux exact dépend du changement livré. La règle importante est la continuité. Le spectateur doit pouvoir voir que le résultat découle de l'action et appartient à la construction indiquée.

Gardez le scénario distinct d'une visite produit complète. Une visite demande : « que peut faire ce produit ? » Une vidéo de notes de version demande : « qu'est ce qui est différent dans cette mise à jour ? » La première peut utiliser une séquence de flux de travail indépendants. La seconde doit préserver une chaîne traçable d'un changement livré jusqu'à un résultat.

Comment les notes de version et les légendes gardent elles la vidéo exacte ?

Liez l'actif depuis le contexte de la note de version et relisez les deux ensemble avant de partager. La note doit fournir la version, la portée, et toute qualification qui ne peut pas être vue dans le clip. La légende doit identifier le changement dans les mêmes termes que ceux utilisés par la note de version. Elle ne doit pas introduire une nouvelle affirmation de bénéfice que la note ne soutient pas.

Vérifiez chaque libellé visible par rapport à la version indiquée. Une cible préparée peut dériver quand les données, les valeurs par défaut, la navigation, ou les indicateurs de fonctionnalité changent. Si la capture ne reflète plus l'état de version, rejetez la même si le montage semble clair. L'exactitude compte plus que la préservation d'un rendu terminé.

Si le montage publié a une voix off générée audible, relisez l'exigence de divulgation et de marquage applicable avant qu'elle ne soit utilisée. Un montage en muet nécessite tout de même une inspection du contenu de navigateur enregistré. Aucun des deux formats ne permet d'applications client, d'identifiants, d'URL client, de médias client, ou d'identifiants personnels.

Comment garder la mise à jour concise ?

Planifiez le clip autour de la question à laquelle un lecteur de version a besoin d'une réponse. Ouvrez sur l'état antérieur seulement assez longtemps pour établir le changement. Montrez ensuite la seule action qui utilise la mise à jour et l'état résultant. Terminez quand ce résultat est clair. Cette séquence donne aux lecteurs assez de preuves pour comprendre la version sans transformer une mise à jour ciblée en visite produit.

Utilisez la note de version pour le matériel qui n'a pas besoin de démonstration visuelle. La portée du déploiement, l'implémentation technique, les étapes de migration, les limitations connues, et les liens vers de la documentation de soutien appartiennent au contexte écrit quand ils ne peuvent pas être montrés clairement dans le flux borné. Garder ces détails à côté de la vidéo permet à un lecteur de parcourir la mise à jour, de choisir le niveau de détail dont il a besoin, et de revenir à l'action pertinente plus tard.

Ce dont un lecteur de version a besoin	Où cela appartient	Pourquoi
L'état antérieur, l'action et le résultat visible	La vidéo	Seule une séquence d'écran montre le changement se produire
La version et la portée du déploiement	La note de version	Le clip ne peut pas montrer de quelle construction il provient
Les étapes de migration et les limitations connues	La note de version	Elles ne peuvent pas être montrées clairement dans un seul flux borné
L'implémentation technique	La note de version	Elle n'a pas de résultat observable à enregistrer

Un actif concis est aussi plus facile à placer dans une liste de journal des modifications. Son image d'ouverture et sa légende doivent identifier le même changement que la note de version voisine. Une personne arrivant depuis une notification, une archive de versions, ou une page produit doit pouvoir comprendre le clip sans supposer que chaque capacité actuelle est nouvelle dans cette version.

Liste de vérification de relecture de version

Effectuez ces vérifications par rapport au candidat exact et à la note de version. La liste de vérification est un outil de préparation, pas une preuve que le travail a été terminé.

Le changement nommé est livré dans la version indiquée.
L'état avant représente avec exactitude le comportement antérieur pertinent.
Une action montre comment le changement livré est utilisé.
Le résultat est visible et découle de cette action.
La note de version, la légende, le libellé de la fonctionnalité, et le contexte de version concordent.
L'actif ne devient pas une présentation générale du produit et n'introduit pas une autre fonctionnalité.
Aucun matériel client, identifiant, URL client, média client, ou identifiant personnel n'apparaît.
Les sous titres et toute voix off générée audible sont relus pour le traitement de publication prévu.
La date de capture, la construction, le relecteur, la tentative rejetée, la nouvelle tentative, et la décision signée sont enregistrées.

Décisions de lancement associées

Utilisez le flux de travail de démo SaaS quand la question est un flux produit général, pas une mise à jour livrée. Le placement de preuve de page de destination couvre le contexte au dessus de la ligne de flottaison. Le placement d'actif README couvre la lecture rapide de dépôt. Une vidéo de démo de lancement de fonctionnalité présente une capacité nouvellement disponible. Une vidéo de démo de version montre un flux borné à partir d'une version livrée indiquée. Une vidéo de mise à jour produit explique le seul changement actuel qu'un utilisateur doit remarquer. Le guide de la vidéo de journal des modifications pour un SaaS couvre le lien entre cette preuve visible et le dossier de version écrit. La préparation d'URL de démo logicielle couvre la méthode d'entrée pour une application web accessible.

Pour des alternatives de flux de travail, lisez GogoScreen et Loom, GogoScreen et Screen Studio, GogoScreen et Clueso, et GogoScreen et Guidde. Avant publication, vérifiez le contexte par rapport à la page d'accueil, aux tarifs, au centre de guides, au centre de comparaison, et aux informations de confidentialité.

Précisions

Avant de commencer

Que doit couvrir une vidéo de journal des modifications ?

Couvrez un seul changement livré à travers un état avant clair, l'action rendue possible par le changement, et le résultat visible. Les notes de version restent le dossier factuel complet.

Comment choisir le seul changement livré ?

Choisissez un changement livré qui compte pour le public visé et qui peut être démontré dans la version indiquée avec des données préparées sûres. N'utilisez pas de travail prévu.

En quoi une vidéo de journal des modifications est elle différente d'une démo produit ?

Une vidéo de journal des modifications explique ce qui a changé par rapport à un état antérieur. Une démo générale explique plus largement comment un produit fonctionne. Mélanger les deux rend le contexte de version moins exact.

Que faut il relire avant de partager ?

Vérifiez le libellé de la note de version, la construction, la séquence état avant action résultat, la légende, la confidentialité, la voix off audible le cas échéant, et un dossier de toute nouvelle tentative.

Collez une URL, décrivez un parcours et obtenez une vidéo de démonstration de votre application web.

Les 60 premières secondes de vidéo sont gratuites, avec un filigrane. Vérifiez votre adresse e-mail pour télécharger la vidéo.

Voir les tarifs Lire les guides