La plainte habituelle des développeurs, ce n’est pas que les designs sont laids, ou en retard. C’est que le fichier de design répond aux mauvaises questions. Un fichier Figma décrit des écrans ; une base de code React décrit des composants avec des props et des états. Quand le handoff livre des écrans, le développeur doit faire de la rétro-ingénierie sur le modèle de composants, et sa supposition ne correspondra pas à la vôtre.
Sur la plupart des projets, je conçois puis je construis moi-même le front-end, ce qui veut dire que je ressens le coût de mes propres handoffs bâclés environ deux jours plus tard. Tout ce qui suit sort de cette boucle.
Le vrai fossé : les écrans face aux états
Un écran est une combinaison figée de données, de viewport et d’état d’interaction. Un composant, lui, doit tous les gérer. Si le fichier montre un tableau de bord avec quatre cartes aux titres de longueur idéale, le développeur doit encore décider ce qui se passe avec une carte, avec douze, avec un titre qui passe à trois lignes, pendant le chargement des données et quand la requête échoue.
Ces décisions se prennent de toute façon. La seule question est de savoir si c’est un designer qui les prend ou si elles sont inventées à 18 h par quelqu’un qui se bat en plus avec une erreur de type. Chaque état laissé sans réponse est un endroit où la réalisation s’écarte du design, et cet écart est ce qui déclenche la conversation sur la reconstruction.
Le livrable n’est donc pas un ensemble de beaux écrans. C’est un inventaire de composants, plus les écrans qui montrent ces composants assemblés ensemble.
Donnez aux propriétés Figma la forme des props React
Les propriétés de composant Figma et les props React sont la même idée avec une syntaxe différente. Un bouton dont la variante est réglée sur primary ou ghost, la taille sur sm ou md, et des propriétés booléennes pour une icône de tête se traduit directement en une interface de props. Nommez-les à l’identique et le mapping devient mécanique plutôt qu’interprétatif.
Évitez les propriétés de variante qui encodent deux choses à la fois. Une variante appelée primary-large-icon doit être décomposée avant de pouvoir devenir du code, et elle multiplie votre matrice de variantes. Trois propriétés indépendantes valent mieux qu’une seule combinée, à chaque fois.
La même discipline s’applique aux noms de calque à l’intérieur du composant. Slot, label, icon et container sont des noms utiles. Frame 247 ne l’est pas. Un développeur qui ouvre Dev Mode lit votre arbre de calques comme une ébauche approximative du DOM, si bien qu’un arbre bien rangé fait réellement partie du livrable.
Quand un composant en imbrique un autre (une carte contenant un bouton), utilisez un instance swap ou une instance imbriquée plutôt que de le redessiner. L’imbrication dans le fichier est ce qui indique au développeur que la composition est intentionnelle.
Mappez les tokens vers la configuration du thème avant le premier composant
Si le projet utilise Tailwind, les design tokens devraient atterrir dans la configuration du thème sous forme de valeurs nommées dès le premier jour : couleurs, espacement, rayons, tailles de police, ombres. Faites cela d’abord et le code qui suit utilise bg-surface-raised et p-4 au lieu de valeurs arbitraires éparpillées dans le balisage.
Le point de friction, c’est généralement l’échelle d’espacement. Les paliers par défaut de Tailwind sont des multiples de 4px ; si les tokens d’espacement de Figma utilisent une autre base, chaque écart de la réalisation devient une valeur entre crochets mise une seule fois. Alignez les deux échelles dès le départ, ou engagez-vous à surcharger complètement le thème. Un demi-alignement est le pire des deux.
Les tokens de couleur devraient franchir la frontière par nom sémantique, pas par hex. Quand un token change de valeur plus tard, un mapping sémantique signifie une seule modification dans le fichier du thème. Un handoff fondé sur le hex signifie un rechercher-remplacer à travers toute une base de code, et il ratera celui du modèle d’e-mail.
Concevez les états que personne ne demande
Pour chaque composant qui affiche des données, dessinez les cas zéro, un et plusieurs. Zéro, c’est l’état vide, et il lui faut un texte qui dit quoi faire ensuite, pas seulement "Aucun résultat". Un, c’est là que les mises en page centrées et les grilles cassent souvent. Plusieurs, c’est là que vous découvrez si la liste avait besoin d’une pagination.
Pour chaque composant qui va chercher des données, dessinez les états de chargement et d’erreur. Un squelette qui correspond à la mise en page finale évite le décalage que les utilisateurs ressentent comme une saccade ; un spinner au milieu d’un conteneur, non. Pour les erreurs, écrivez le vrai message : "Impossible de charger les factures. Réessayer" est une décision de design, pas un texte que quelqu’un remplit plus tard.
Pour chaque élément interactif, définissez hover, focus-visible, active et disabled. Les anneaux de focus en particulier sont sautés à la conception, puis, dans le code, soit omis, soit laissés au réglage par défaut du navigateur, ce qui est à la fois un échec d’accessibilité et le genre de détail non peaufiné que les clients remarquent sans pouvoir le nommer.
Et testez la mise en page avec du contenu hostile : un nom trois fois plus long que le placeholder, un nombre avec plus de chiffres que prévu, une langue plus longue que l’anglais. Dix minutes de cela dans Figma économisent un rapport de bug par écran.
Spécifiez le comportement responsive, ne le sous-entendez pas
Deux frames, un à 1440 et un à 390, laissent tout ce qui les sépare à l’interprétation. Dites ce qui se passe dans l’intervalle : quels breakpoints existent, quelle est la largeur maximale du conteneur, quelles grilles passent de quatre colonnes à deux puis à une, et quel est le padding à chaque palier.
L’auto layout avec wrapping et redimensionnement fill-container communique une grande partie de cela sans frames supplémentaires, parce qu’il démontre l’intention au lieu de la décrire. Là où le comportement n’a vraiment rien d’évident (une barre latérale qui devient un bottom sheet, un tableau qui devient des cartes empilées), dessinez l’état intermédiaire. C’est celui que le développeur devrait sinon inventer.
Ce que les plugins de design vers code ne savent toujours pas faire
Les plugins qui exportent des frames Figma vers React se sont beaucoup améliorés, et ils sont réellement utiles pour une section marketing statique ou un prototype rapide. Ce qu’ils ne savent pas faire, c’est produire un composant qui s’intègre à la base de code que vous avez déjà. La sortie ne connaît ni votre Button existant, ni vos tokens de thème, ni votre routage, ni votre couche de données, ni votre gestion d’état, si bien qu’elle arrive comme un îlot de balisage autonome qu’il faut démonter avant de pouvoir s’en servir.
Ils ne peuvent pas non plus déduire les props ou les états, parce que ceux-ci n’existent pas dans le frame, ce qui est précisément le fossé décrit au début de cet article. Le code généré représente un écran, un breakpoint, un état.
L’usage réaliste, c’est l’échafaudage : laissez un plugin mettre grossièrement en place la structure et l’espacement, puis réécrivez-le face au vrai design system. Traitez la sortie comme un premier jet écrit par quelqu’un qui n’a jamais vu le reste du projet, et l’outil devient utile au lieu d’être une source de dette technique.
