Aller au contenu
Guide7 min de lecture

Partager un projet Windsurf avec un client

Certains clients ne cliqueront jamais sur le lien. Envoyez leur le résultat à la place.

Remettez un projet Windsurf fonctionnel à un client non technique qui n'ouvrira pas de lien de prévisualisation, en utilisant une vidéo plutôt qu'une URL.

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.

Certains clients ouvrent chaque lien que vous leur envoyez. D'autres non, que ce soit par manque de temps, par manque d'aisance avec des logiciels inconnus, ou simplement par préférence pour qu'on leur dise plutôt qu'on leur montre où cliquer. Un projet Windsurf construit pour ce second type de client a besoin d'une remise différente d'une URL de prévisualisation et d'un message plein d'espoir. Une courte vidéo qui se joue d'elle même, sans connexion ni navigation requise, respecte à la fois le temps du client et le fait qu'il n'a peut être jamais ouvert de lien de préproduction de sa vie.

Windsurf lui même est un éditeur de code, et le client n'en a presque certainement jamais entendu parler et n'a pas besoin de le savoir. Ce qu'il a demandé était un résultat, décrit dans ses propres mots lors d'un appel ou d'un e-mail, pas une fonctionnalité technique. La vidéo doit répondre directement à cette demande originale, en utilisant le vocabulaire propre du client plutôt que les termes internes de l'interface, puisqu'un client qui doit retraduire des libellés inconnus vers sa propre demande fait un travail que la vidéo aurait dû faire pour lui.

C'est un problème différent de montrer le même projet à un public technique. Une démo de portfolio Windsurf est jugée par quelqu'un qui veut voir du savoir faire et qui est prêt à s'asseoir pour quelques nuances. Une vidéo de relecture client est jugée par quelqu'un qui veut une réponse oui ou non et qui ne s'assiéra pour rien de plus. Confondre les deux, en envoyant à un client quelque chose construit pour un public de portfolio, est une façon courante dont une remise client tourne mal même quand la vidéo sous jacente est bien faite.

Que doit réellement voir un client non technique ?

Partez de la demande originale, pas de la structure de l'application. Si le client a demandé « un moyen pour les clients de réserver un créneau », la vidéo doit montrer exactement ce flux de réservation, décrit comme une réservation, pas comme ce que le code appelle l'objet sous jacent. Sautez tout écran que le client n'a pas demandé, même un écran soigné, puisqu'un écran inattendu invite une question sur le périmètre plutôt que de la confiance dans la livraison.

Les clients lisent aussi le rythme différemment d'un relecteur technique. Un développeur qui regarde une vidéo de relecture peut suivre une coupe rapide entre les écrans parce qu'il comprend déjà la structure sous jacente. Un client ne le peut pas, et une vidéo qui va au rythme d'un développeur le laissera incertain de ce qu'il vient de voir. Ralentissez le rythme, laissez chaque écran s'installer assez longtemps pour être enregistré, et résistez à l'envie de compresser la vidéo simplement parce qu'une coupe plus rapide paraîtrait plus soignée à vos propres yeux.

Ce que le client a demandéCe que la vidéo doit montrerCe qui perturbe plus que ça n'aide
Une description simple d'un résultatCe résultat exact, du début à la finDes écrans ou des termes qu'il n'a jamais mentionnés
Une correction de quelque chose de casséLes mêmes étapes qui échouaient auparavant, fonctionnant maintenantUne autre zone qui a aussi été touchée
Une nouvelle capacitéCette capacité utilisée comme il l'a décriteDes options de configuration destinées à un utilisateur technique

Une liste de vérification de vidéo de démo SaaS est une référence générale utile pour ce type de préparation, même si ce guide précis est écrit pour un public client plutôt que pour un acheteur général.

Comment préparer la version pour un client qui ne l'explorera pas ?

Ouvrez vous même la route déployée et accomplissez exactement la tâche dans les mots du client. Confirmez qu'il n'y a pas de données de débogage restantes, pas de texte de remplacement, et rien à l'écran qui soulèverait une question que vous préféreriez ne pas traiter par e-mail. Un client qui ne va pas explorer l'application ne vous accordera pas non plus le bénéfice du doute sur quoi que ce soit qui semble inachevé, puisqu'il n'a aucun autre contexte du projet pour le pondérer.

  • Parcourez exactement la tâche décrite par le client, dans l'ordre qu'il a décrit.
  • Retirez toute donnée de débogage ou de remplacement laissée pendant le développement.
  • Préparez un compte de démonstration si le flux nécessite une connexion, plutôt que d'envoyer de vrais identifiants.
  • Confirmez que rien à l'écran ne nécessiterait une explication de suivi.

Si une connexion est nécessaire, un compte de démonstration peut être préparé pour le rendu, et sur GogoScreen, les identifiants utilisés 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. Cela compte particulièrement ici, puisqu'un client non technique ne saurait probablement pas quoi faire d'une connexion même si vous lui en aviez envoyé une, et est mieux servi en n'en ayant jamais besoin du tout.

Réfléchissez à ce que le client fera immédiatement après avoir regardé. Si la prochaine étape naturelle est une réponse disant oui, approuvé, cette réponse ne devrait rien nécessiter au delà de la vidéo elle même. Si le client devait cliquer pour vérifier quelque chose que la vidéo n'a pas montré, la vidéo n'a pas réellement fini le travail, et cela vaut la peine d'ajouter l'élément manquant avant l'envoi plutôt que d'attendre une question de suivi qu'un enregistrement légèrement plus long aurait pu éviter.

Comment l'indication et la narration doivent elles être rédigées ?

  1. Traduisez la demande dans les propres mots du client avant de décider quoi montrer.
  2. Montrez le résultat avant tout détail d'interface, puisque c'est ce qu'il a demandé.
  3. Narrez en langage courant, pas en terminologie produit, pour que rien n'ait besoin d'être expliqué après coup.

Rédigez l'indication comme vous expliqueriez le résultat au téléphone, pas comme vous le décririez à un autre développeur. Si le message original du client utilisait une phrase précise, réutilisez cette phrase plutôt que de la remplacer par un terme plus précis mais inconnu. Une précision qui nécessite un glossaire n'est pas une précision que le client peut utiliser.

Que se passe t il avant et après cette remise ?

Si le client a demandé une relecture avant que le travail ne soit considéré comme terminé, ce guide couvre l'étape de livraison, tandis que le parcours de relecture d'application Windsurf couvre comment structurer le flux autour de la demande originale elle même. Une fois qu'un projet est approuvé par le client et se dirige vers un public plus large, un traitement de type vidéo de démo Base44, une vidéo de page de destination Base44, ou une vidéo de lancement Product Hunt Base44 répondent chacune à une question ultérieure différente, même si la remise client elle même n'a besoin d'aucune de ces trois pour l'instant.

Si le prix plutôt que la livraison est la question ouverte avec ce client, une vidéo de démo pour une page de tarifs SaaS est une préoccupation distincte et ultérieure. Si le client regarde depuis un fil public plutôt qu'un message privé, c'est plus proche d'une vidéo de démo Show HN ou d'une démo Product Hunt d'un agent IA que d'une remise client privée, et le ton doit s'ajuster en conséquence. La mécanique sous jacente reste la même dans les deux cas, et le guide de la vidéo de démo logicielle à partir d'une URL couvre cette mécanique plus en détail si une étape ci dessus n'était pas familière.

Que devriez vous vérifier avant de l'envoyer ?

Regardez la vidéo finie comme si vous étiez le client, sans connaissance préalable du projet. Confirmez que le résultat est visible sans narration au cas où il regarde en muet sur un téléphone, et confirmez que rien à l'écran ne nécessite une question de suivi pour être compris. Comparez le format à Demosmith si vous pesez une autre façon d'emballer cette même remise.

Laissez de la place pour une nouvelle tentative, puisqu'environ un rendu sur cinq en a besoin, et une remise client est un mauvais endroit pour un retard surprise. Chaque nouveau compte reçoit 60 secondes de vidéo une seule fois, avec filigrane, ce qui est souvent suffisant pour une seule tâche client, et ensuite le temps acheté en recharge n'expire jamais et le temps n'est utilisé que lorsqu'un rendu réussit. Consultez les tarifs pour les forfaits, parcourez plus de guides et de comparaisons, ou partez de la page d'accueil de GogoScreen avec la route et l'indication sur lesquelles cette remise est construite.

Précisions

Avant de commencer

Pourquoi ne pas simplement envoyer au client le lien de prévisualisation ?

Un lien de prévisualisation suppose que le client l'ouvrira, comprendra ce qu'il regarde, et interprétera correctement une interface inconnue. Beaucoup de clients non techniques ne feront rien de tout cela de façon fiable, et une vidéo supprime entièrement cette supposition.

Que doit montrer la vidéo à un client qui n'a pas demandé de détail technique ?

Montrez le résultat qui l'intéresse, décrit dans son propre langage plutôt que dans la terminologie interne de l'application, avec assez de contexte pour qu'il n'ait pas besoin d'avoir déjà vu le projet.

Est ce différent d'une vidéo de démo générale ?

Le flux de travail d'enregistrement est le même. La différence est le public. Une vidéo de relecture client est écrite pour quelqu'un qui décide si le travail correspond à ce qu'il a demandé, pas pour un inconnu qui décide s'il va essayer le produit.

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.