Aller au contenu
Guide7 min de lecture

Vidéo de présentation guidée de relecture Bubble

Montrez au relecteur le seul parcours qui prouve que la construction correspond au brief.

Donnez au relecteur d'un projet Bubble un seul parcours enregistré qui prouve que la construction correspond au brief, plutôt qu'une mise à jour écrite.

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 présentation guidée de relecture Bubble existe pour répondre à une question qu'un client ou un chef de projet se pose sans cesse sans la dire à voix haute : ce que j'ai demandé a t il réellement été construit. Les mises à jour écrites sont mauvaises pour répondre à cela. Elles décrivent une intention, pas un résultat, et un relecteur qui lit « le flux de travail de facturation est terminé » n'a aucun moyen de savoir si cela signifie qu'il se déclenche correctement ou que quelqu'un a tapé la phrase avec espoir. Un parcours enregistré du flux de travail réel en train de fonctionner supprime cette ambiguïté, parce que soit le clic sur le bouton produit le résultat promis à l'écran, soit il ne le produit pas.

GogoScreen construit cela à partir d'une URL d'application web et d'une indication d'une ligne décrivant le flux à enregistrer. Il renvoie un MP4 narré, généralement d'environ deux minutes, avec un montage qui supprime les temps morts, lisse le curseur, zoome sur les clics, et incruste des sous titres. Pour un flux de travail qui n'apparaît qu'une fois connecté, un compte de démonstration peut être fourni. Sur GogoScreen, les identifiants sont chiffrés, utilisés pour un seul rendu, puis supprimés ensuite. 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. Rien de tout cela ne remplace la lecture du code ou de la logique du flux de travail dans l'éditeur Bubble. Cela remplace le fait de demander à un relecteur non technique de le faire à la place.

Que doit exactement prouver la présentation guidée ?

Partez du brief, pas de l'application. Relisez la demande précise faite par le client ou le manager, qu'il s'agisse de « les utilisateurs peuvent soumettre une candidature et voir son statut changer » ou « un administrateur peut approuver une annonce et elle apparaît publiquement ». La présentation guidée doit montrer précisément ce chemin, déclenché comme le ferait un véritable utilisateur, se terminant au résultat décrit dans le brief. Une présentation guidée qui s'égare vers des fonctionnalités voisines que le relecteur n'a jamais demandées gaspille son attention et peut inviter une nouvelle portée dans une relecture censée clore une portée ancienne.

Les flux de travail Bubble sont une logique visible dans l'éditeur, une séquence d'étapes attachée à un événement, mais un relecteur non technique ne peut pas lire cette séquence et n'essaiera pas. Ce qu'il peut évaluer, c'est si cliquer sur le bouton a produit le changement qu'on lui avait dit d'attendre. Gardez la présentation guidée ancrée à ce seul résultat observable.

  1. Confirmez exactement ce que le brief demandait et choisissez le seul flux de travail qui le prouve.
  2. Réglez l'application sur l'état juste avant le déclencheur afin que l'enregistrement commence au moment pertinent.
  3. Enregistrez la présentation guidée et envoyez la au relecteur avec une courte note sur ce qui reste ouvert.

Comment préparer l'application avant d'enregistrer ?

Ouvrez l'application, soit la version en production soit la version de test selon l'étape que couvre la relecture, et amenez la dans l'état qui précède directement le déclencheur. Si le flux de travail dépend de données existantes, un enregistrement déjà créé, un utilisateur déjà inscrit, préparez cela à l'avance plutôt que d'enregistrer aussi les étapes de configuration. Un relecteur n'a pas besoin de regarder un compte se créer avant de voir la fonctionnalité qu'il a réellement demandée.

Étape de préparationPourquoi elle compte pour la présentation guidéeCe qu'il faut sauter
Confirmer le libellé exact du briefGarde l'enregistrement ancré à ce qui a été demandéLes fonctionnalités ajoutées depuis le brief mais pas encore approuvées
Atteindre l'état pré déclencheurL'enregistrement commence à l'action pertinenteLa création de compte, l'accueil, la navigation non liée
Choisir production ou version de testLe relecteur sait quelle étape de construction il approuveMélanger les deux dans un enregistrement sans le préciser

Si le flux de travail ne se déclenche que pour un utilisateur connecté, fournissez un compte de démonstration via le processus approuvé plutôt que de partager la connexion d'un vrai client. La gestion sur GogoScreen est que l'identifiant est chiffré, utilisé pour un seul rendu, puis supprimé. 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. Formulez le ainsi si la question se pose, puisque la description exacte est aussi la plus rassurante pour un relecteur qui la pose.

Que doit dire l'indication d'une ligne ?

Rédigez l'indication comme vous briefieriez un collègue qui n'a jamais ouvert l'application. Nommez le point de départ, l'action, et le résultat exact promis par le brief. « Depuis la liste des candidatures, approuvez la candidature en attente et montrez son statut passer à approuvé » donne une cible précise. Une indication vague comme « montre la fonctionnalité d'approbation » invite un enregistrement qui s'égare au delà du seul moment que le relecteur doit réellement voir.

Gardez le libellé de l'indication cohérent avec le libellé du brief et de l'application elle même. Si le brief appelle quelque chose une candidature et que l'interface de l'application l'appelle une soumission, choisissez un terme et utilisez le dans l'indication afin que la narration n'introduise pas un décalage que le relecteur doit démêler.

Que se passe t il si la présentation guidée est trop large ?

Une présentation guidée qui essaie de couvrir le flux de travail demandé plus trois autres choses qui se trouvent à proximité laisse généralement le relecteur moins sûr, pas plus. Si un flux secondaire trébuche sur un cas limite en cours d'enregistrement, le client a désormais une nouvelle question ouverte sur quelque chose qu'il ne relisait pas au départ. Gardez chaque présentation guidée étroite, une demande, un résultat, et envoyez en une séparée pour un élément séparé du brief plutôt que de les combiner pour économiser un rendu.

Environ un rendu sur cinq nécessite une nouvelle tentative ou échoue complètement, ce qui vaut la peine d'être su avant de promettre à un relecteur un retour le jour même. Intégrez cela dans le calendrier plutôt que de traiter la première tentative comme garantie. Le guide de l'échec de rendu de vidéo de démo couvre ce qu'il faut vérifier avant de soumettre à nouveau lorsqu'un rendu ne revient pas comme attendu.

Comment cela se rattache t il au reste du flux de relecture et de lancement ?

Une présentation guidée Bubble envoyée pour relecture interne n'est qu'une étape. Une fois qu'un flux de travail est approuvé, le même flux peut devoir réapparaître pour un public différent, et la discipline sous jacente se transpose même si les spécificités de la plateforme changent. Une vidéo de démo Firebase Studio part de la même question de ce qu'un flux prouve, tandis que le guide de la vidéo de page de destination Firebase Studio concerne la preuve pour un inconnu plutôt que pour un relecteur qui connaît déjà le projet. Le guide de la vidéo de lancement Product Hunt Firebase Studio couvre un public de galerie de lancement, et le guide pour partager un projet Firebase Studio avec un client ainsi que le guide de la démo de portfolio Firebase Studio traitent chacun une version du problème de passation que cette page résout pour Bubble.

Pour une construction issue d'une conversation avec un investisseur plutôt que d'un brief client, le guide de la vidéo de démo pour investisseur d'un agent IA couvre un public lié mais distinct avec des attentes différentes. Si l'application elle même a été assemblée par un créateur de site web IA plutôt qu'à la main dans l'éditeur Bubble, le guide de la vidéo de démo d'un créateur de site web IA est le choix le plus proche. Une fois qu'un flux de travail relu est ensuite livré comme fonctionnalité, le guide de la vidéo de démo de lancement de fonctionnalité et le guide de la vidéo de journal des modifications pour un SaaS couvrent son annonce publique, ce qui est un travail séparé de la relecture privée pour laquelle cette présentation guidée sert.

Bouclez avec une courte note écrite à côté de la vidéo : ce qui a été relu, ce qui a été validé, et ce qui reste ouvert. La vidéo prouve que le flux de travail s'est exécuté. La note est ce que le relecteur classe comme enregistrement de la décision. Pour le reste du flux de travail, voir les alternatives Bubble à un outil d'enregistrement d'écran guidé, la page des tarifs pour les forfaits et recharges, la bibliothèque complète des guides, les pages de comparaison, et la page d'accueil de GogoScreen pour le flux de travail de l'URL et de l'indication lui même.

Précisions

Avant de commencer

Que doit prouver une présentation guidée de relecture d'une application Bubble ?

Elle doit prouver que le flux de travail précis demandé dans le brief s'exécute de bout en bout sur la construction en production ou en version de test, depuis le déclencheur attendu par le relecteur jusqu'au résultat qu'on lui a annoncé.

Qui est le public d'une vidéo de relecture Bubble ?

Généralement un client, un chef de projet, ou un responsable d'agence qui n'ouvrira pas l'éditeur Bubble ni ne cliquera lui même sur un lien de version de test. Il doit voir le résultat, pas inspecter la logique du flux de travail.

Une vidéo de relecture remplace t elle une mise à jour écrite ?

Non. Elle remplace la partie d'une mise à jour qui est difficile à décrire avec des mots, le moment où un flux de travail se déclenche réellement et où l'application répond. Associez la à une courte note écrite sur ce qui a été relu et ce qui reste ouvert.

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.