La plupart des fichiers Figma ne sont pas prêts pour le handoff au développement. Ils ont l'air impressionnants. Les écrans sont soignés, l'alignement est parfait, les choix de couleurs sont délibérés. Mais quand un développeur ouvre le fichier et essaie d'en extraire ce dont il a besoin pour le construire, il se heurte à un mur. Les composants n'ont pas de nommage cohérent. L'auto layout est appliqué de manière incohérente, donc les valeurs d'espacement sont enfouies dans le positionnement manuel. Les variants existent pour l'état hover mais pas pour les états désactivé ou erreur. Les design tokens dans Figma ne correspondent à rien dans le codebase.
J'ai été des deux côtés de ce problème tout au long de ma carrière. En tant que designer UX/UI j'ai livré des fichiers que je pensais complets et reçu des messages confus de développeurs deux jours plus tard. En tant que développeur Angular Senior j'ai reçu des fichiers Figma qui nécessitaient des heures d'appels de clarification avant de pouvoir écrire une seule ligne de code. La solution, que j'ai affinée au fil des années de travail en double rôle, est un ensemble de pratiques que j'applique maintenant de manière cohérente à chaque fichier Figma que je crée. Cet article documente ces pratiques.
Le nommage : la fondation de tout
Un mauvais nommage dans Figma est la cause racine de la plupart des problèmes de handoff. Quand un développeur ouvre le panneau Inspect et voit 'Frame 247' ou 'Rectangle copy 3', il n'a aucune information utile. Pire, un nommage incohérent signifie que le développeur ne peut pas mapper en confiance les composants Figma aux composants de code correspondants dans le design system.
Je suis une convention de nommage qui reflète l'API du composant aussi fidèlement que possible. Les noms de composants Figma utilisent le même format que le sélecteur du composant Angular ou le token du design system. Un bouton dans Figma est nommé Button, pas 'CTA' ou 'Primary Action'. Ses variants sont nommées en utilisant les noms de propriétés et valeurs qui apparaîtront dans le code : variant=Primary, size=Medium, state=Default.
// Figma component naming convention
Button
variant: Primary | Secondary | Tertiary | Destructive
size: Small | Medium | Large
state: Default | Hover | Focus | Disabled | Loading
// Maps directly to Angular component usage
<app-button
variant="primary"
size="medium"
[disabled]="isLoading">
Submit
</app-button>Quand le langage de nommage dans Figma correspond au langage de nommage dans le code, la conversation de handoff devient beaucoup plus courte. Le développeur peut regarder un composant dans Figma, identifier sa variante et son état depuis le panneau de propriétés, et savoir exactement quel composant Angular et quelles valeurs d'input utiliser.
Auto Layout bien fait
L'auto layout est la seule fonctionnalité de Figma qui fait traverser le handoff au modèle CSS flexbox intact. Utilisé correctement, le développeur lit le layout au lieu de le deviner. Utilisé incorrectement, ou pas du tout, il le laisse déduire la logique de layout depuis des mesures en pixels qui décrivent une seule frame figée et ne disent rien du comportement quand la fenêtre bouge.
Mes règles pour l'auto layout dans les fichiers prêts pour le handoff :
- Chaque composant qui sera construit avec flexbox ou grid en CSS devrait utiliser l'auto layout dans Figma. Sans exception.
- L'espacement entre les éléments devrait venir du gap de l'auto layout, pas d'éléments positionnés manuellement. Une valeur de gap dans Figma se traduit directement en gap en CSS.
- Utilisez 'Fill container' pour les éléments qui s'étirent pour prendre l'espace disponible, et 'Hug contents' pour les éléments dimensionnés par ce qu'ils contiennent. La correspondance CSS est proche, pas exacte, et c'est l'axe qui tranche. Fill le long de l'axe du layout, c'est flex-grow: 1. Fill en travers de l'axe du layout, c'est align-self: stretch. Hug, c'est fit-content sur l'axe et auto en travers. Dites de quel axe vous parlez dans l'annotation et le développeur arrête de deviner.
- Le padding devrait être défini dans le panneau auto layout, pas en ajoutant des frames spacer invisibles. Les valeurs de padding dans Figma sont ce que le développeur implémentera en CSS.
- Utilisez les contraintes min/max width pour les composants qui ont besoin d'un comportement responsive. Une carte qui doit faire au moins 280px de large mais peut grandir s'exprime dans les contraintes auto layout.
Variants et états interactifs
Un composant sans tous ses états documentés n'est pas un composant. C'est une spécification partielle. J'en ai déjà parlé du point de vue de l'écriture de brief, mais dans Figma spécifiquement, le standard est : chaque composant interactif doit avoir des variants pour tous les états qui existent dans l'implémentation.
Pour un champ de saisie texte, cela signifie : Default, Focused, Filled, Error, Disabled et Read-only. Pour un bouton : Default, Hover, Focus, Active, Disabled et Loading. Ce ne sont pas des cas limites. C'est l'ensemble minimum que tout bouton rencontrera en production.
La fonctionnalité de composants interactifs de Figma (connexions prototype entre variants) est précieuse pour communiquer le comportement hover et focus dans les prototypes. Mais ne vous reposez pas dessus comme substitut de la documentation des variants. Chaque état devrait exister comme une variante distincte dans l'ensemble de composants, clairement étiquetée, pour qu'un développeur puisse l'inspecter directement sans avoir à déclencher une interaction prototype.
Design tokens : le pont entre Figma et le code
Les design tokens sont l'outil le plus important pour réduire la friction de handoff, et aussi le plus souvent mal implémenté. L'objectif est simple : chaque décision de design dans Figma (couleur, espacement, typographie, rayon de bordure, ombre, durée) devrait référencer un token nommé, et ce token devrait exister dans le codebase sous le même nom.
En pratique, cela signifie configurer vos variables Figma pour correspondre exactement à vos CSS custom properties ou à votre objet de tokens JavaScript. Le montage qui tient la route exporte les Figma Variables en JSON et passe le fichier dans Style Dictionary pour générer le CSS. Tokens Studio (anciennement Figma Tokens) est une autre option : il gère le jeu de tokens à l'intérieur de Figma et peut le synchroniser avec un dépôt.
/* In CSS (design system tokens) */
:root {
--color-action-primary: #0052cc;
--color-action-primary-hover: #003d99;
--color-surface-default: #ffffff;
--color-text-primary: #172b4d;
--space-2: 8px;
--space-3: 12px;
--space-4: 16px;
--radius-md: 6px;
--shadow-card: 0 1px 3px rgba(0,0,0,0.12);
}Quand le développeur inspecte un bouton dans Figma et voit que la couleur d'arrière-plan est var(--color-action-primary) plutôt qu'une valeur hexadécimale, il peut l'implémenter immédiatement avec le bon token. Pas de color picking, pas de valeurs hexadécimales codées en dur, pas de dérive entre design et implémentation.
Synchroniser les tokens entre Figma et le code
Un autre workflow qui supprime la dérive, quand la même personne ou la même équipe possède à la fois la bibliothèque Figma et la bibliothèque de composants, c'est le code d'abord : les design tokens vivent dans un fichier JSON du dépôt comme source unique de vérité. Un plugin de synchronisation comme Tokens Studio lit ce fichier et peuple le jeu de tokens dans Figma. Quand un token change (mise à jour de couleur de marque, ajustement d'espacement), le changement est fait dans le fichier JSON, une PR est ouverte, et une fois mergée, la bibliothèque Figma est synchronisée depuis le fichier mis à jour. Figma reflète toujours ce qui est dans le code, pas l'inverse. Écrire les tokens dans les Figma Variables et exporter le JSON, le montage décrit plus haut, marche tout aussi bien, tant que l'équipe choisit une direction et l'écrit quelque part. Chez BMO, le design system appartenait à une autre équipe et je travaillais du côté consommateur, où la question qui compte est la même : dans quel sens la vérité circule-t-elle ?
Plugins d'annotation et spécifications
Le panneau Inspect de Figma est utile mais insuffisant pour les composants complexes. Quatre types de notes doivent vivre quelque part sur le canvas : notes d'interaction (ce qui se passe au clic, quelles interactions clavier sont supportées), notes de comportement responsive, annotations d'accessibilité (rôles ARIA, ordre de focus), et notes de contraintes de contenu (nombre max de caractères, ratios d'aspect d'images). Aucune n'apparaît toute seule dans Inspect.
Commencez par la voie gratuite, parce qu'elle marche avec n'importe quel siège et que c'est encore mon défaut. Un composant de callout et un style de texte pour les notes vous donnent une couche de spec complète pour rien. Si vous voulez que les parties mesures et anatomie soient générées plutôt que dessinées à la main, le plugin Specs de EightShapes a un palier gratuit qui couvre les annotations d'anatomie, de layout et d'espacement, et Redlines & Annotations dans la communauté Figma fait les overlays de mesures. Les deux écrivent des calques ordinaires sur le canvas, donc n'importe qui avec un accès en lecture peut lire le résultat.
Le Dev Mode de Figma a des annotations et des mesures natives, et elles sont meilleures que tout ce que vous dessinez à la main : l'annotation est liée au calque, elle survit à un renommage, elle se met à jour quand le calque bouge, et elle apparaît dans le panneau Inspect, là où le développeur regarde déjà. Le hic, c'est le siège. Le Dev Mode exige un siège payant Full ou Dev depuis janvier 2024. Traitez-le comme une montée en gamme que vous achetez quand le volume de handoff le justifie, pas comme le point de départ. Si votre équipe le paie déjà, utilisez-le et supprimez votre couche d'annotation manuelle.
D'où que viennent les notes, elles vivent sur leur propre page Figma dans mes fichiers, nommée 'Specs & Annotations'. Elle contient un doublon de chaque écran avec les annotations superposées, plutôt que des annotations posées sur les frames de design elles-mêmes, parce que ça encombre le design dès qu'une partie prenante l'ouvre. Le développeur a besoin de la spec, il va sur la page Specs. La partie prenante veut le design propre, elle reste sur la page design.
Organisation de fichier navigable par les développeurs
Un fichier Figma visuellement beau mais structurellement chaotique est inutile pour le handoff. Ma structure de fichier pour tout projet prêt pour le développement :
- Page de couverture : Nom du projet, statut (En cours / Prêt pour le dev / En développement / Terminé), date de dernière mise à jour, responsable design, contact développeur.
- Page Tokens : Toutes les variables et styles documentés avec leurs valeurs et notes d'utilisation.
- Page Composants : La bibliothèque de composants. Toutes les variants de tous les composants organisées par catégorie.
- Page Flux : Flux écran par écran organisés par parcours utilisateur, avec connexions prototype.
- Page Specs & Annotations : Versions annotées de tous les écrans prêtes pour l'inspection par les développeurs.
- Page Archive : Anciennes explorations et concepts rejetés, gardés pour référence mais clairement étiquetés.
L'avantage du double rôle dans le handoff
Écrire cet article me fait réaliser à quel point mon expérience en développement a façonné ma manière de concevoir. Quand je crée une variante de composant pour l'état de chargement d'un bouton, je ne le fais pas par souci de rigueur pour elle-même. Je le fais parce que je sais d'expérience qu'un développeur implémentant ce bouton aura besoin de savoir à quoi il ressemble quand isLoading est true, et sans référence design il va soit me demander soit inventer quelque chose.
Chaque annotation que j'écris dans une spec est une réponse à une question que je sais qu'un développeur posera, parce que j'ai posé ces mêmes questions moi-même. À quoi doit ressembler le ring de focus ? Combien de lignes ce champ texte supporte-t-il avant de déborder ? Que se passe-t-il avec le layout de la carte s'il n'y a pas de miniature ?
Si vous êtes un designer qui ne code pas, le moyen le plus rapide d'améliorer la qualité de votre handoff est de faire du pair avec un développeur pendant un sprint et de lui demander de narrer son expérience en ouvrant votre fichier Figma et en implémentant à partir de celui-ci. Les points de friction qu'il rencontre vous diront exactement quoi améliorer. Le développeur est votre utilisateur quand le produit est un fichier Figma, et la recherche utilisateur s'applique.
Un fichier Figma est un document de spécification. Un document de spécification est un outil de communication. Jugez-le non pas sur sa beauté, mais sur la clarté avec laquelle il répond aux questions du développeur.
L'objectif n'est pas un fichier parfait. C'est un fichier qui permet à un développeur de commencer à construire le lundi matin sans une seule question de clarification. C'est un standard élevé, mais c'est un standard atteignable, et ça vaut l'investissement initial à chaque fois.
Références
- Figma auto-layout. https://help.figma.com/hc/en-us/articles/360040451373-Guide-to-auto-layout
- Figma variants. https://help.figma.com/hc/en-us/articles/360056440594-Create-and-use-variants
- Guide du Dev Mode de Figma, siège payant Full ou Dev requis. https://help.figma.com/hc/en-us/articles/15023124644247-Guide-to-Dev-Mode
- Annonce de disponibilité générale du Dev Mode de Figma, janvier 2024. https://www.figma.com/blog/dev-mode-ga/
- Tokens Studio. https://tokens.studio/
- API REST Figma Variables (plan Enterprise uniquement ; les plugins d'export de la communauté sont la voie gratuite). https://developers.figma.com/docs/rest-api/variables/