De la maquette Figma à une application : écrans, données et interactions

Votre maquette montre le résultat souhaité. Pour construire l’application, il faut aussi décrire ce qui se passe entre les écrans, où les informations sont conservées et qui peut les modifier. Un exemple de réservation montre comment préparer ce passage.

Vous avez une maquette Figma qui ressemble déjà à un produit. On peut parcourir ses écrans, reconnaître les boutons et imaginer son usage. Pourtant, un bouton « Confirmer » ne dit pas encore ce qui doit être confirmé, enregistré ou refusé. Le passage de Figma à une application consiste à transformer ces intentions visuelles en comportements vérifiables.

Suivons le cas fictif d’Élise, qui prépare un outil de réservation de séances photo. Sa maquette comporte un calendrier, une fiche de séance et une confirmation. Nous allons compléter ces vues avec les règles qu’elles ne montrent pas. Vous pourrez réutiliser la fiche finale avec votre propre design, quel que soit l’outil chargé de construire le code.

Choisir un parcours complet dans la maquette

Prenez une seule action utile, de son point de départ à son résultat. Pour Élise : choisir un créneau disponible, renseigner ses coordonnées et recevoir une réservation conservée. Mettez les écrans correspondants dans l’ordre. Ajoutez une phrase sous chacun pour indiquer ce qui permet de passer au suivant.

Ce travail fait souvent apparaître un vide. Le calendrier montre une disponibilité, mais aucun écran ne dit ce qui arrive si quelqu’un réserve le même créneau quelques secondes avant vous. La fiche possède un champ téléphone, mais vous ne savez pas s’il est obligatoire. Décider ces points maintenant évite de laisser l’assistant inventer une règle commerciale.

Gardez les autres fonctions à part : facturation, avis, galerie, code promotionnel. Elles peuvent être pertinentes plus tard. Le premier parcours doit déjà apporter un résultat visible et conservé. Si vous ne savez pas décrire sa réussite sans parler de couleurs, il manque encore une partie du besoin.

Préparer des repères visuels réutilisables

Regroupez les couleurs, tailles de texte, espacements et composants répétés. Un bouton principal devrait se reconnaître d’un écran à l’autre. Un champ erroné devrait être signalé de la même manière dans le formulaire client et dans le formulaire interne. Les composants de votre maquette donnent une base, mais leur comportement doit suivre.

Préparez au moins une version étroite et une version large du parcours choisi. Expliquez ce qui change : menu replié, ordre des informations, calendrier simplifié, boutons toujours visibles. Une capture d’écran seule ne précise pas les règles de réorganisation entre deux tailles. Notez aussi les contenus longs : une adresse ou un nom peut dépasser l’exemple soigné de la maquette.

La documentation Figma Make décrit l’ajout de designs et de contexte pour créer une interface fonctionnelle. Cela ne signifie pas que tous les outils utilisent les fichiers Figma de la même manière. Vérifiez le mode de transmission disponible : fichier, éléments de design, capture ou description. Ce guide ne suppose pas une fonction native d’import Figma dans Maestro.

Pour comprendre · illustration du guide

Nommer les objets derrière les cartes

La carte « Séance du vendredi » cache plusieurs informations : une séance proposée, un créneau, un client et une réservation. Si tout reste dans une seule ligne de texte, il devient difficile de modifier l’horaire sans perdre le lien avec le client. Demandez un modèle simple qui distingue ces objets et leurs relations.

Dans le cas d’Élise, une séance décrit une offre. Un créneau indique une date et une capacité. Une réservation lie un créneau à un client avec un état. Le montant affiché peut dépendre de l’offre, mais le montant accepté lors de la réservation doit rester explicable même si le tarif change ensuite. Ce sont des choix de fonctionnement, pas des détails réservés aux développeurs.

Prenez chaque information visible et posez trois questions : qui la fournit, où est-elle conservée, qui peut la corriger ? Une date peut venir d’Élise, une adresse du client et un statut d’une règle de l’application. Les mélanger sans distinction rend les corrections et les autorisations difficiles à suivre.

Dessiner les états que personne n’a maquettés

Une liste élégante remplie de trois réservations ne représente qu’un état. Il faut aussi une liste vide, une liste en cours de chargement et une erreur d’accès. Une confirmation doit être précédée d’une opération qui peut prendre du temps ou échouer. Ces états ont besoin d’un texte utile, pas seulement d’une icône.

• Aucun créneau : proposer une autre période ou une manière de laisser une demande, sans afficher une réservation impossible.
• Créneau devenu indisponible : conserver les coordonnées déjà saisies et inviter à en choisir un autre.
• Enregistrement en cours : éviter un second envoi involontaire et expliquer l’attente.
• Enregistrement refusé : afficher la raison utile et préserver les informations qui peuvent l’être.
• Accès retiré : ne plus afficher le dossier privé, même avec une ancienne adresse directe.

Ajoutez ces états à la maquette ou à une fiche liée. Vous n’avez pas besoin de dessiner chaque combinaison avec la même finition. Quelques lignes précises suffisent souvent pour diriger une première construction et vérifier ensuite si l’interface raconte bien ce qui se passe.

Décrire les interactions comme des engagements

Remplacez « le bouton ouvre la page suivante » par « lorsque la réservation a été acceptée, afficher sa référence et son horaire ». La première consigne décrit une navigation. La seconde oblige à relier la confirmation au résultat réel. Précisez également les cas où l’action doit être refusée.

Pour Élise, le serveur doit vérifier que la place reste disponible au moment d’enregistrer. Masquer le bouton dans le navigateur n’empêche pas deux personnes d’agir simultanément. Vous pouvez demander cette propriété sans écrire vous-même le code : « Deux demandes concurrentes pour la dernière place ne doivent pas toutes les deux être confirmées. Montre-moi comment tu le vérifieras. »

Décidez ce que l’utilisateur peut annuler et jusqu’à quand, selon vos propres règles de service. Une suppression définitive et une annulation conservée dans l’historique n’ont pas les mêmes conséquences. Le mot choisi dans le bouton doit correspondre à l’action exécutée. Si une décision reste ouverte, indiquez-la explicitement plutôt que de laisser une valeur implicite.

Construire une petite tranche qui fonctionne de bout en bout

Demandez d’abord le calendrier, une réservation fictive et sa relecture. À cette étape, faites préciser si le stockage est provisoire ou durable. Ensuite, ajoutez les comptes, les règles d’accès et les cas de refus. Cette progression vous permet d’examiner un fonctionnement complet sans attendre tous les écrans secondaires.

Conservez vos choix visuels pendant cette progression. Une correction de la règle de disponibilité ne devrait pas déclencher une refonte aléatoire du calendrier. Donnez des repères stables : composants à conserver, textes à respecter et parcours à ne pas casser. Dans Maestro, ces éléments peuvent nourrir la description du besoin et la revue du plan de construction.

Si une proposition technique reste incompréhensible, demandez sa conséquence pratique. « Nous utiliserons telle base » apporte moins de valeur à Élise que « les réservations seront conservées dans ce service ; voici comment vous pourrez les exporter et les restaurer ». Vous n’avez pas à connaître chaque bibliothèque pour exiger cette explication.

Faire une revue visuelle et une revue d’usage

Comparez les écrans avec la maquette : hiérarchie des titres, marges, couleurs, états des boutons et comportement sur petit écran. Puis effectuez une seconde revue, centrée sur les actions. Une ressemblance parfaite ne compense pas une réservation perdue ; un stockage correct ne rend pas acceptable un formulaire inutilisable au clavier.

Rejouez une réservation avec un nom long, une erreur de saisie puis une correction. Fermez l’onglet, revenez et cherchez la référence. Faites ouvrir une autre session autorisée pour vérifier la vue interne. Essayez également deux demandes pour le dernier créneau. Pour chaque écart, notez l’action, le résultat attendu et le résultat observé.

Limitez vos demandes de correction à des problèmes identifiables : « À 390 pixels de large, le bouton recouvre le champ téléphone » ou « Après retour arrière, le créneau sélectionné disparaît ». Ces descriptions aident à corriger le produit sans relancer toute la conception. Gardez une capture seulement lorsqu’elle éclaire l’écart.

Livrer un dossier de passage, pas seulement des écrans

La fiche Figma vers application rassemble le parcours d’Élise, les objets, les états et les essais proposés. Elle contient également des champs à compléter pour votre projet. Vous pouvez joindre cette fiche à vos visuels afin que la personne ou l’IA qui construit sache ce qui doit réellement fonctionner.

Au moment de transmettre le projet, conservez la version de la maquette utilisée, les décisions prises ensuite et les limites connues. Si le produit diffère du dessin, expliquez pourquoi. Cette trace facilite une future correction et évite de traiter la dernière capture comme une spécification complète.

Votre prochain travail n’est donc pas d’exporter tous les écrans en une seule demande. Choisissez un parcours, rendez ses règles explicites et obtenez une première réalisation que vous pouvez fermer, rouvrir et faire essayer. C’est à cet endroit que la maquette commence à devenir une application.