Guide6 min de lecture

Présentation guidée de relecture d'application Figma Make

Montrez au relecteur le flux qui répond à sa question avant qu'il ne la pose.

Donnez à un relecteur interne le flux unique qui prouve qu'une réalisation Figma Make fait ce qui a été demandé, avant qu'il ne s'assoie pour l'approuver.

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.

gogoscreen.com

Faire correspondre la présentation guidée à la demande

Faites correspondre la présentation guidée à la demande exacte que le relecteur vérifie, pas une visite générale.

Ouvrir la réalisation à froid

Ouvrez la réalisation à froid pour confirmer qu'elle atteint le résultat demandé sans détour sans rapport.

Énoncer ce qui a été demandé et ce qui a été livré

Énoncez ce qui a été demandé et ce qui a été livré dans le même message que la vidéo.

Une relecture d'application est une comparaison, pas une première impression. Quelqu'un a demandé une chose précise, et le travail du relecteur est de vérifier si la réalisation la livre. Cela change ce que la présentation guidée doit faire. Elle ne vend pas la réalisation. Elle répond à une question déjà posée, aussi directement que possible, afin que le relecteur puisse approuver, demander un changement, ou escalader sans avoir à fouiller lui même l'interface. Traitez la demande comme le script, et traitez la vidéo comme une preuve, pas comme une persuasion.

Une réalisation Figma Make vit généralement sur un lien de prévisualisation partageable qui s'ouvre sans connexion, puisque la plupart des projets Figma Make sont des prototypes plutôt que des logiciels livrés avec un vrai système de compte derrière eux. Cela signifie que le relecteur pourrait, en principe, aller ouvrir le lien et le vérifier lui même. En pratique, il en a rarement le temps, ce qui est exactement pourquoi une présentation guidée ciblée fait gagner un cycle de relecture au lieu d'en ajouter un. Une file de demandes de relecture avance plus vite lorsque chacune arrive avec une réponse de deux minutes jointe plutôt qu'un simple lien que le relecteur doit programmer du temps pour explorer.

À quoi la présentation guidée doit elle correspondre ?

Partez de la demande d'origine, pas de la réalisation. Si un ticket demandait « les utilisateurs peuvent filtrer la liste par statut », la présentation guidée doit montrer exactement cela : la liste, le contrôle de filtre, et le résultat filtré. Tout ce que la vidéo montre au delà de cette demande est, au mieux, un bonus et, au pire, une distraction par rapport à la seule chose que le relecteur vérifie.

C'est une tâche plus étroite qu'une vidéo de remise client, où l'objectif est une décision de la part de quelqu'un qui ne connaît pas la demande au départ. Un relecteur interne connaît déjà la spécification. Le seul travail de la présentation guidée est de combler l'écart entre la spécification et le résultat visible.

Question du relecteur	Ce que la vidéo doit répondre	Ce qu'il faut laisser de côté
Cela a-t-il été construit comme demandé	Le flux exactement demandé, du début à la fin	Des fonctionnalités sans rapport, absentes de la demande
Est ce que cela fonctionne réellement	Une exécution propre sans impasse	Une exécution idéale qui évite un bug connu
Que manque-t-il encore	Un état honnête de la réalisation actuelle	Des affirmations exagérées sur l'achèvement

Comment gérer une réalisation qui n'est pas entièrement terminée ?

Montrez la réalisation telle qu'elle est actuellement, pas telle qu'elle sera un jour. Si une partie du flux demandé n'est pas terminée, dites le directement dans le message qui accompagne la vidéo plutôt que de monter autour de l'écart. Un relecteur qui découvre une pièce manquante après qu'on lui a dit que tout était fait perd confiance plus vite que celui à qui on a dit d'emblée ce qui restait. Cette confiance compte plus que n'importe quelle relecture isolée, puisque la prochaine présentation guidée du même bâtisseur sera évaluée par rapport à l'honnêteté de la dernière.

Confirmez la demande exacte en cours de relecture avant d'enregistrer quoi que ce soit.
Ouvrez la réalisation à froid pour vérifier qu'elle atteint le résultat sans contournement connu du seul bâtisseur.
Notez toute partie de la demande qui n'est pas encore complète dans le message accompagnant la vidéo.
Évitez de raconter un plan pour un travail futur à l'intérieur de la vidéo elle même, puisque cela appartient au compte rendu écrit, pas à l'enregistrement.

Les étapes qui gardent une présentation guidée de relecture honnête sont les trois mêmes à chaque fois :

Faites correspondre la présentation guidée à la demande exacte que le relecteur vérifie, pas une visite générale.
Ouvrez la réalisation à froid pour confirmer qu'elle atteint le résultat demandé sans détour sans rapport.
Énoncez ce qui a été demandé et ce qui a été livré dans le même message que la vidéo.

Que doit dire l'indication à GogoScreen d'enregistrer ?

Écrivez l'indication comme un miroir direct de la demande. Si la demande était « les utilisateurs peuvent filtrer la liste par statut », l'indication doit ressembler à « depuis la liste complète, appliquer le filtre de statut et montrer le résultat filtré », pas une description plus large de tout l'écran. GogoScreen renvoie un MP4 narré construit autour de cette indication, avec des zooms sur les clics pertinents, un lissage du curseur, la suppression des temps morts, et des sous-titres, environ deux minutes après la soumission.

Testez le flux à la main avant de soumettre le rendu. Confirmez que le filtre, le formulaire, ou l'interaction nommée par la demande produit réellement le résultat attendu, et vérifiez toute redirection, état vide, ou interruption qui déraillerait l'enregistrement. Un rendu construit autour d'un flux qui ne fonctionne pas réellement ne fera que faire surgir le problème plus tard, devant le relecteur plutôt qu'avant. Repérer cet écart pendant la vérification manuelle coûte quelques minutes. Le repérer dans la réunion du relecteur coûte tout le cycle de relecture.

Gardez la formulation de l'indication assortie aux termes utilisés dans la demande ou le ticket d'origine, plutôt qu'aux noms internes utilisés à l'intérieur de la réalisation elle même. Un relecteur qui vérifie la vidéo par rapport à une spécification écrite doit pouvoir suivre sans traduire entre deux vocabulaires différents pour la même fonctionnalité.

Comment gérer la réponse après l'envoi ?

Si le relecteur revient avec une question à laquelle la vidéo n'a pas répondu, cela signifie généralement que la demande contenait plus que ce que la présentation guidée a couvert, pas que le relecteur se montre difficile. Vérifiez à nouveau la spécification d'origine avant de supposer que le retour est déraisonnable. Une deuxième vidéo plus étroite répondant au suivi précis est souvent plus rapide que d'essayer de réexpliquer la première par écrit. C'est aussi là que le fait de garder chaque présentation guidée limitée à une demande porte ses fruits, puisqu'une vidéo étroite rend évidente la partie de la spécification qui a encore besoin d'une réponse au lieu de forcer un relecteur à revisionner un enregistrement flou à la recherche de la pièce manquante.

Environ un rendu sur cinq échoue ou nécessite une nouvelle tentative, et le temps n'est utilisé que lorsqu'un rendu réussit, donc laissez du temps pour une deuxième tentative avant une échéance de relecture plutôt que de soumettre le rendu au tout dernier moment.

Où cela s'inscrit il dans le reste du processus de relecture ?

Une fois qu'une réalisation passe la relecture interne, elle doit souvent se déplacer vers d'autres audiences. Une vidéo de démo Bubble, une vidéo Bubble de page de destination, une vidéo de lancement Bubble sur Product Hunt, le partage d'un projet Bubble avec un client, et une démo de portfolio Bubble couvrent l'ensemble équivalent de tâches pour cette plateforme, utile quand une demande couvre deux bâtisseurs différents. Le guide de l'indication de flux en une ligne approfondit la rédaction précise de l'indication, et le guide de la vidéo de démo d'application connectée couvre le cas où le flux demandé se trouve derrière un vrai compte.

Pour un format de présentation guidée basé navigateur plus large, voir le guide de la vidéo de présentation guidée d'application web. Une fois la réalisation approuvée et prête pour une audience plus large, le guide de la vidéo de démo de page d'accueil et le guide de la vidéo de démo Product Hunt couvrent cette étape suivante. Pour une comparaison des outils d'enregistrement pour le travail de relecture interne, lisez GogoScreen contre Screen Studio. Commencez sur la page d'accueil de GogoScreen, consultez les tarifs, parcourez la bibliothèque complète de guides, ou consultez le reste des comparaisons.

Précisions

Avant de commencer

Qu'est ce qui distingue une présentation guidée de relecteur d'une vidéo client ?

Un relecteur vérifie généralement la réalisation par rapport à une demande, une spécification ou un ticket précis, il ne décide pas s'il l'aime. La présentation guidée doit correspondre directement à cette demande plutôt que de présenter la réalisation comme un argumentaire fini.

La présentation guidée doit elle couvrir les cas limites ?

Couvrez d'abord le cas réellement demandé. Une deuxième vidéo peut couvrir un cas limite si le relecteur le demande, mais commencer par les cas limites avant que le flux principal ne soit prouvé tend à soulever des doutes que le flux principal aurait déjà résolus.

Le relecteur a-t-il besoin d'un accès à Figma Make pour regarder ceci ?

Non. Le fichier terminé est un MP4 autonome qui se lit sans aucune connexion à Figma Make ni à la réalisation elle même, ce qui compte lorsque le relecteur n'est pas la personne qui a commandé directement la réalisation.

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