À propos de ce cours
Cette leçon explique comment préparer une maquette Figma pour les développeurs. Elle présente le passage de relais (handoff), le Dev Mode (mesures, variables, extraits de code, sections « Prêt pour le développement »), les annotations de comportement, de responsive et d'accessibilité, le dessin de tous les états (vide, chargement, erreur, succès, contenu extrême), l'alignement des variables avec le code, l'export des ressources et une liste de contrôle avant de livrer. Trois activités portent sur l'écran Panier de CantineCampus.
| Durée | Niveau | Prérequis | À la fin de la leçon |
|---|---|---|---|
| 1 heure 15 (cours et 3 activités) | Débutant, chapitre « Digitaliser le produit avec les outils d'UI » | Partager et commenter une maquette avec InVision | Vous savez préparer un fichier que les développeurs peuvent construire sans ambiguïté : Dev Mode, annotations, états, exports, variables |
-
Objectifs
- Comprendre ce qu'est le passage de relais (handoff) entre design et développement.
- Utiliser le Dev Mode de Figma.
- Annoter les comportements, le responsive et l'accessibilité.
- Dessiner tous les états et exporter les ressources.
- Vérifier la maquette avec une liste de contrôle avant de livrer.
-
Le passage de relais
- Le passage de relais (en anglais handoff) est le moment où la maquette devient la référence pour les développeurs.
- Le développeur ne doit pas deviner: chaque taille, couleur, espacement, état et comportement doit pouvoir se lire dans la maquette ou dans une annotation.
- Ce n'est pas une remise unique : designers et développeurs continuent d'échanger. Mais un fichier bien préparé évite des dizaines de questions et d'allers-retours.
- Vous êtes en BTS Développement : vous serez souvent de l'autre côté. Préparez la maquette que vous aimeriez recevoir.
-
Le Dev Mode de Figma
- Le Dev Mode est un espace de Figma pensé pour les développeurs. On l'active avec le bouton en haut à droite (ou Maj + D).
- En sélectionnant un élément, le développeur lit ses mesures (taille, marges, distances), ses styles et ses variables (« couleur-primaire » plutôt qu'un code couleur), et un extrait de code (CSS, iOS, Android).
- Les sections marquées « Prêt pour le développement » indiquent ce qui est validé ; le Dev Mode signale aussi ce qui a changé depuis.
- Le Dev Mode est inclus dans le plan Éducation ; dans une entreprise, il demande un accès « Dev » ou « Complet ».
-
Annoter ce que l'image ne dit pas
- Comportement: ce qui défile, ce qui reste fixe, ce qui se passe au clic, au chargement, en cas d'erreur.
- Responsive: ce qui change selon la largeur (TP 12) : nombre de colonnes, panneau révélé, navigation.
- Accessibilité: nom accessible des icônes seules, ordre de lecture et de tabulation, textes alternatifs, annonces des messages.
- Contenus: longueur maximale, troncature (« … »), format des dates et des prix, cas des valeurs absentes.
- Utilisez les annotations de Figma ou des composants « Note » placés à côté des écrans, reliés à l'élément concerné.
-
Dessiner tous les états
- Un écran n'a pas qu'un seul état. Pour chacun, prévoyez : vide (aucun contenu), chargement, erreur (réseau, saisie), succès, et le contenu extrême (texte très long, 50 plats, solde à 0).
- Pour chaque composant : tous ses états (normal, survol, focus, appuyé, désactivé, chargement).
- Un état non dessiné sera inventé par le développeur, souvent sans respecter la charte.
-
Variables et code
- Les variables Figma (couleurs, espacements, rayons, tailles) doivent porter les mêmes noms que les variables du code (variables CSS, thème Flutter ou Angular) : c'est le rôle des tokens vus au chapitre sur la charte.
- Le développeur lit alors « couleur-primaire » dans le Dev Mode et utilise directement la variable correspondante.
- Documentez les variables (nom, valeur, usage) dans la page « Design system ».
-
Exporter les ressources
- Icônes et logo: en SVG, net à toutes les tailles.
- Photos: en WebP ou JPG, aux échelles 1×, 2×, 3× pour les écrans haute densité.
- Illustrations: en SVG ou PNG selon leur complexité.
- Réglez l'export dans le panneau de droite (section Export) : le développeur peut alors télécharger lui-même les ressources depuis le Dev Mode.
- Nommez les fichiers de façon prévisible : minuscules, tirets, préfixe par type (ic-, plat-, etat-), suffixe d'échelle (@2x).
-
Vérifier avant de livrer
- Passez la maquette à une liste de contrôle: fichier rangé et nommé, variables et styles partout, composants complets, tous les états, toutes les largeurs, vrais contenus, annotations, sections « Prêt pour le développement », ressources exportables, version nommée.
- Faites relire la maquette par un développeur (un autre binôme) : chaque question posée révèle une information manquante.
🍽 Exemple : CantineCampus
- Pour l'écran « Panier » de CantineCampus, le binôme a livré : l'état normal, le panier vide, le chargement de la validation, l'erreur « solde insuffisant » et l'erreur réseau ; les versions 390 et 1 280 px ;
- et cinq annotations : barre fixe, comportement du bouton, nom accessible du « + », panier révélé à partir de 1 024 px, troncature des noms de plats au-delà de deux lignes.
⚠ Piège : une maquette « parfaite » sur le chemin heureux mais sans états d'erreur ni annotations n'est pas prête : c'est le développeur qui finira la conception, à votre place.
-
Aide-mémoire
-
Activités
Activité 1Lire une maquette en Dev Mode · ⏱ 15 min
- Ouvrez votre fichier en Dev Mode et sélectionnez le bouton principal, une carte de plat et un titre.
- Relevez pour chacun : taille, espacements, variables, style de texte. Les noms de variables sont-ils ceux de votre code ?
📁 Résultat attendu : un tableau élément × informations relevées, et les noms à corriger.
Activité 2Les états de l'écran Panier · ⏱ 25 min
- Dessinez les états de l'écran « Panier » : vide, chargement, erreur réseau, solde insuffisant, succès.
- Annotez le comportement de la barre d'action, le responsive et l'accessibilité.
- Marquez la section « Prêt pour le développement ».
📁 Résultat attendu : les cinq états annotés.
Activité 3La relecture par un développeur · ⏱ 15 min
- Échangez votre écran « Panier » avec un autre binôme qui joue le rôle du développeur.
- Il note toutes les questions qu'il se pose pour coder l'écran.
- Complétez la maquette pour que chaque question trouve sa réponse.
📁 Résultat attendu : la liste des questions et les compléments apportés.
-
Erreurs fréquentes
| Symptôme | Cause | Solution |
|---|---|---|
| Couleurs en code hexadécimal dans le Dev Mode | Variables non utilisées | Variables nommées comme dans le code |
| « Que se passe-t-il si le panier est vide ? » | États manquants | Vide, chargement, erreur, succès, contenu extrême |
| Icônes floues dans l'application | Export PNG trop petit | SVG pour les icônes |
| « Est-ce la dernière version ? » | Pas de statut | Sections « Prêt pour le développement », version nommée |
| Icône sans nom pour le lecteur d'écran | Accessibilité non annotée | Annoter les noms accessibles |
-
Bilan
- Le passage de relais transforme la maquette en référence : le développeur ne doit rien deviner.
- Le Dev Mode donne mesures, variables et extraits de code.
- Les annotations décrivent comportements, responsive et accessibilité.
- Tous les états sont dessinés, les ressources exportables et bien nommées.
- Une liste de contrôle et une relecture par un développeur valident la livraison.
Une maquette est terminée quand un développeur peut la construire sans vous appeler.