Aller au contenu
Guide7 min de lecture

Vidéo de démo d'un planificateur de repas

Montrez une recette devenir une liste de courses, pas une visite de chaque écran.

Bâtissez une vidéo de démo d'un planificateur de repas autour d'un parcours recette vers liste de courses, avec des données préparées et une relecture honnête.

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.

Une vidéo de démo d'un planificateur de repas fonctionne quand elle montre le moment où une seule décision devient un plan utilisable, pas un diaporama de la bibliothèque de recettes. Un logiciel de planification de repas a généralement trois couches visibles : une collection de recettes, un calendrier hebdomadaire dans lequel les recettes sont glissées ou assignées, et une liste de courses censée se mettre à jour une fois le calendrier modifié. La couche qui convainc réellement un spectateur est la troisième, car elle prouve que l'application a fonctionné plutôt que simplement stocké des préférences.

GogoScreen accepte une URL d'application web et une indication d'une ligne décrivant le flux, puis retourne un fichier MP4 narré et monté avec des sous-titres, des zooms sur les clics, et un lissage du curseur déjà appliqués. Les plans de repas personnels et les listes de recettes enregistrées se trouvent généralement derrière une connexion, donc un compte de démonstration est souvent nécessaire même si la navigation des recettes elle même peut être publique. Prévoyez cette séparation avant de choisir quoi enregistrer.

À quoi ressemble généralement un planificateur de repas au moment de la démo ?

Un compte neuf a presque jamais une semaine remplie et prête à montrer. Le calendrier est vide, la liste de courses n'a rien dessus, et la bibliothèque de recettes peut n'avoir que le contenu d'exemple livré par le créateur. Essayer de cacher cela en enregistrant une longue navigation à travers des recettes sans rapport ne résout pas le problème, cela ne fait que retarder le moment où le spectateur remarque que rien n'a réellement été planifié.

La meilleure approche est de préparer un petit ensemble réaliste de recettes avant l'enregistrement, puis d'en assigner deux ou trois à des jours précis du calendrier. Cela donne au rendu une base sur laquelle s'appuyer. L'objectif n'est pas un mois complet de repas. C'est assez de contexte pour qu'ajouter une recette de plus et regarder la liste de courses réagir se lise comme un résultat réel, pas comme une application vide qui prétend être remplie.

Préparer cette semaine de départ prend plus de temps qu'il n'y paraît, surtout parce que les recettes doivent sembler choisies plutôt que générées. Une recette intitulée plat exemple un signale à un spectateur que personne n'a réellement planifié cette semaine, même si l'interface environnante est soignée. Nommer les recettes préparées comme le ferait une vraie personne, pâtes du mardi soir plutôt que recette quarante deux, garde le calendrier crédible sans avoir besoin de l'historique de repas réel d'un vrai client.

Comment les choix de connexion et de données façonnent ils le plan ?

Décidez tôt si le flux a besoin d'un compte. Parcourir une collection publique de recettes peut ne pas en avoir besoin, mais enregistrer un plan, modifier un calendrier, ou générer une liste de courses en a presque toujours besoin. Testez le parcours de connexion à la main avant de soumettre quoi que ce soit pour un rendu. Confirmez que le compte atterrit directement sur le calendrier ou le tableau de bord, pas sur un sondage de préférences ou une invite d'abonnement qu'un spectateur de première fois ne supporterait jamais volontairement.

Élément de planificationCe qu'un spectateur a besoin de voirCe qu'il faut éviter
Sélection de recetteUne recette choisie avec un nom et des ingrédients visiblesUn défilement de toute la bibliothèque
Calendrier hebdomadaireLa recette placée sur un jour précisUn calendrier vide ou chaque jour rempli à la fois
Liste de coursesDes ingrédients apparaissant après le changement du planUne liste de courses montrée sans lien retour vers le plan
État du compteUn écran d'atterrissage propre après la connexionUn sondage de configuration ou un écran de vente s'ouvrant en premier

N'utilisez jamais les informations diététiques, les repas enregistrés, ou l'historique d'achat d'une vraie personne comme contenu de démo, même des données de test laissées par un vrai utilisateur. Des recettes préparées et clairement fictives protègent contre ce risque de la même façon que le guide de catégorie des applications de prise de notes traite les notes personnelles comme un contenu qui n'a jamais sa place dans un enregistrement public, peu importe la commodité qu'offrirait un vrai compte pour prendre une capture d'écran.

Rédiger l'indication de flux

Nommez la recette de départ, l'action d'assigner cette recette à un jour, et le résultat consistant à regarder la liste de courses changer. Une indication qui fonctionne : depuis la bibliothèque de recettes, ajoutez la recette de pâtes du mardi soir au mercredi et montrez la liste de courses gagner ses ingrédients. C'est assez précis pour qu'un relecteur puisse vérifier le candidat fini par rapport à cela, et cela évite d'inviter une errance à travers des écrans sans rapport.

  1. Choisissez un flux qui va d'une recette choisie à un résultat visible dans le planificateur.
  2. Préparez quelques recettes d'exemple et un calendrier hebdomadaire partiellement rempli avant l'enregistrement.
  3. Rédigez une indication d'une ligne nommant l'écran de départ, l'action et le résultat visible.

Gardez le vocabulaire de l'indication aligné sur le produit. Si l'application appelle la vue hebdomadaire un planificateur plutôt qu'un calendrier, utilisez planificateur. Un spectateur qui a utilisé une application concurrente remarquera l'incohérence plus vite qu'il ne remarque la plupart des autres incohérences, car le vocabulaire de la planification de repas varie plus que la plupart des catégories logicielles. Testez l'indication exacte à la main avant de la soumettre, car une route qui fonctionne pendant une navigation informelle peut encore révéler un écran différent quand elle est suivie dans l'ordre précis que l'indication décrit.

Qui regarde, et qu'a t il besoin de croire ?

La plupart des gens qui regardent une démo de planificateur de repas décident s'ils vont essayer l'application eux mêmes, pas s'ils l'évaluent comme un achat professionnel. Cela change ce qui les convainc. Un spectateur qui se demande s'il faut abandonner une liste papier ou une autre application veut voir que la liste de courses est réellement générée à partir du plan, pas tapée séparément. Si la démo montre une liste de courses remplie sans jamais montrer la recette qui l'a produite, la promesse centrale du produit reste non prouvée, même si chaque écran individuel paraît soigné.

Un deuxième public, plus petit, est quelqu'un qui évalue l'application comme une construction précoce, similaire au public décrit dans le guide de la vidéo de démo d'un MVP. Ce spectateur pardonne plus facilement une interface rugueuse qu'un lien cassé entre la recette, le calendrier, et la liste, car ce lien est la fonctionnalité réellement testée.

Un troisième cas qui mérite d'être planifié séparément est un planificateur de repas encore en développement actif, où la fonctionnalité de liste de courses elle même est le changement en relecture plutôt que toute l'application. Cette situation se rapproche du flux de travail décrit dans le guide de la vidéo de démo de PR d'un agent IA, où l'enregistrement utile est délimité à un seul changement de code plutôt qu'à un produit fini. Traiter une fonctionnalité encore changeante comme s'il s'agissait d'une sortie stable invite une démo qui cesse de correspondre à l'application en quelques jours.

Choisir où la vidéo a sa place

Une version courte convient à une page de destination au dessus de la ligne de flottaison, en suivant la structure du guide de la vidéo produit de page de destination. Une version plus longue adaptée à une annonce de fonctionnalité suit plutôt le guide de la vidéo de démo de lancement de fonctionnalité. Si le flux a été capturé directement depuis le navigateur sans mise en scène supplémentaire, le guide de l'enregistrement d'écran automatisé explique en quoi cette approche diffère d'une présentation guidée entièrement produite, et le guide pour transformer une URL en vidéo couvre le flux de travail sous jacent dont dépend toute cette catégorie.

Pour une catégorie liée mais distincte, la même discipline de préparation et de connexion s'applique dans le guide de catégorie des applications de planification de voyage et le guide de catégorie des applications d'annonces immobilières, et le guide de catégorie des outils de présentation couvre une catégorie où l'état du compte compte tout autant. Quelqu'un qui pèse des outils générant une vidéo à partir d'un enregistrement existant peut aussi comparer avec GogoScreen contre Screen Studio. Commencez depuis la page d'accueil de GogoScreen avec une URL et une indication, consultez la tarification pour les forfaits et recharges, parcourez la bibliothèque de guides pour des flux de travail liés, ou passez en revue les comparaisons avec d'autres outils avant d'en choisir un.

Précisions

Avant de commencer

Que doit montrer une vidéo de démo d'un planificateur de repas ?

Montrez un seul flux, comme ajouter une recette à un plan hebdomadaire et regarder la liste de courses se mettre à jour, plutôt que de parcourir chaque catégorie de recettes que contient l'application.

Un planificateur de repas a t il besoin de vraies données utilisateur pour une démo ?

Non. Préparez quelques recettes réalistes et un calendrier hebdomadaire partiellement rempli. Un planificateur complètement vide paraît inachevé, et les repas enregistrés d'une vraie personne ne sont pas un contenu de démo approprié.

Un compte de démonstration de planificateur de repas peut il se trouver derrière une connexion ?

Oui, la plupart des plans enregistrés le sont. Un compte de démonstration peut être fourni pour cette route, et sur GogoScreen les identifiants fournis sont chiffrés, utilisés pour un seul rendu, puis supprimés. Si un storyboard est planifié en premier, les identifiants restent chiffrés pendant cette session et sont supprimés au plus tard deux heures après leur dernière utilisation.

Que faire si le premier rendu ne suit pas le flux prévu ?

Environ un rendu sur cinq échoue ou nécessite une nouvelle tentative. Comparez le résultat à l'indication et réessayez avec un périmètre plus étroit plutôt que de publier un candidat qui a dérivé.

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.