Passations design-ingénierie au-delà des commentaires Figma
Pourquoi les commentaires Figma seuls ne suffisent pas à combler le fossé des passations design-ingénierie, et ce qui fonctionne pour les petites équipes.
By Ellis Keane · 2026-04-06
Le meilleur outil de passation design-ingénierie est celui que les ingénieurs n'ouvrent jamais
Plus les designers investissent dans la perfection de leur passation Figma – auto-layout, tokens de design, annotations du mode dev, documentation des composants –, plus la passation design-ingénierie réelle empire souvent. Non pas parce que le travail de design est mauvais – il est généralement brillant –, mais parce que tout cet effort vit dans un outil que les ingénieurs ouvrent à contrecœur, survolent rapidement, puis ferment pour construire ce qu'ils croient avoir vu.
J'ai été des deux côtés. J'ai commencé comme designer (enfin, « designer » – je construisais des sites web de prêteurs sur gage dans le New Hampshire, alors soyons généreux avec le titre) et j'écris maintenant la majeure partie du code d'ingénierie de Sugarbug. Le problème de la passation design-ingénierie n'est pas un problème d'outils – c'est un problème de flux de travail. L'information existe, elle se trouve simplement au mauvais endroit au mauvais moment.
La passation design-ingénierie typique ressemble à ceci : un designer passe trois jours à peaufiner un frame Figma, ajoute douze commentaires expliquant les décisions d'espacement et les cas limites, étiquette l'ingénieur, puis attend. L'ingénieur ouvre Figma, regarde le frame pendant environ quatre-vingt-dix secondes, pense « bien, j'ai compris », ferme l'onglet et construit quelque chose à 80 % correct et à 20 % incorrect – d'une manière qui prendra encore une semaine d'allers-retours à résoudre. Les douze commentaires ? Il en a peut-être lu quatre.
Une passation design-ingénierie n'est pas un fichier que l'on lance par-dessus un mur. C'est du contexte qui doit vivre là où l'ingénieur travaille – dans l'issue, dans le PR, dans le code –, pas dans un outil de design qu'il ne visite qu'une fois.
Pourquoi les commentaires Figma n'ont pas la bonne forme pour les passations
J'utilise Figma tous les jours et j'aime vraiment ça (ce qui est probablement un défaut de caractère à ce stade). Mais les commentaires Figma sont optimisés pour la collaboration entre designers – pas pour la passation design-ingénierie –, et cette différence compte plus que la plupart des équipes ne le réalisent.
Le décalage fondamental est le suivant : les commentaires Figma sont spatialement ancrés aux frames et aux composants. Ils existent à l'intérieur d'un fichier de design. Mais les ingénieurs ne travaillent pas dans des fichiers de design – ils travaillent dans des issues Linear, des PRs GitHub et leur IDE. Lorsqu'un designer laisse un commentaire sur un frame disant « ce menu déroulant devrait se replier sur les viewports mobiles en dessous de 640px », cette information est maintenant coincée dans Figma. Elle ne devient pas une tâche. Elle n'apparaît pas dans le flux de travail de l'ingénieur. Elle existe dans un univers parallèle que l'ingénieur doit se rappeler de visiter, et (voilà la partie qui compte vraiment) ouvrir Figma ne fait pas partie du cycle de travail naturel d'un ingénieur, contrairement à la vérification de Linear ou à la revue de PRs.
Le résultat est prévisible : les décisions de design critiques sont perdues, non pas parce que quelqu'un est négligent, mais parce que l'information se trouve dans le mauvais outil. C'est comme laisser un post-it sur le bureau de quelqu'un qui travaille à domicile.
Où les designers laissent du contexte
- Commentaires Figma – Spatiaux, ancrés aux frames
- Annotations du mode dev Figma – Détaillées mais nécessitent d'ouvrir Figma
- Fils Slack – Conversationnels, introuvables après une semaine
- Documentation du système de design – Complète mais rarement consultée en milieu de sprint
Où les ingénieurs regardent vraiment
- Description de l'issue Linear – La première chose qu'ils lisent avant de commencer
- Description du PR GitHub – Référence pendant l'implémentation
- Commentaires de code – Découverts lors de la revue
- IDE – Où ils passent 90 % de leur temps
Ce qui fonctionne vraiment (par quelqu'un qui fait les deux)
Au cours de la dernière année à construire Sugarbug, j'ai été le designer et (surtout) l'ingénieur, ce qui signifie que j'ai eu l'expérience inhabituelle de me faire des passations à moi-même et de perdre quand même du contexte. Si je ne me souviens pas de mes propres décisions de design du mardi dernier, il n'y a aucune chance qu'un ingénieur séparé capte tout depuis un fil de commentaires Figma.
Voici ce qui a vraiment fonctionné pour le processus de passation design-ingénierie de notre équipe, et rien de tout cela n'implique d'écrire de meilleurs commentaires Figma.
1. Écrivez la décision de design dans l'issue, pas dans le fichier de design
Avant qu'un ingénieur commence à construire, le contexte de design doit vivre dans l'issue Linear (ou ce que votre équipe utilise). Pas un lien vers le fichier Figma avec « voir les designs » – c'est une esquive, et tout le monde le sait. L'issue devrait inclure :
- Quoi : Une capture d'écran ou un frame exporté (pas un lien Figma – un PNG que l'ingénieur peut voir sans ouvrir un autre outil)
- Pourquoi : Le raisonnement derrière les décisions clés. « Nous avons choisi un panneau latéral plutôt qu'une modale parce que l'utilisateur doit référencer la liste en cours d'édition » – une phrase qui économise trois allers-retours de « pourquoi pas une modale ? »
- Cas limites : Que se passe-t-il sur mobile ? Que se passe-t-il avec un texte long ? Que se passe-t-il en l'absence de données ? Si vous y avez réfléchi, notez-le. Si vous n'y avez pas réfléchi, dites-le (honnêtement, « je n'ai pas encore résolu l'état vide » est plus utile que le silence)
2. Les revues de design se font dans l'issue, pas dans Figma
Quand je reçois un retour de design pendant l'implémentation, je le veux dans le fil de l'issue Linear, pas comme un commentaire Figma que je ne verrai peut-être pas pendant deux jours. L'issue est ma seule source de vérité pour le travail – si le retour vit là, je le verrai la prochaine fois que je consulterai l'issue, ce qui arrive plusieurs fois par jour. S'il vit dans Figma, je le verrai quand j'ouvrirai ce fichier par hasard, ce qui pourrait ne jamais arriver.
Cela ne signifie pas ne jamais utiliser les commentaires Figma. Ils sont excellents pour la collaboration entre designers, pour annoter des détails visuels spécifiques et pour les conversations sur le design lui-même. Mais dès que le retour devient « l'ingénieur doit changer quelque chose », il doit migrer vers le flux de travail d'ingénierie.
stat: "La plupart" headline: "Les commentaires Figma n'étaient pas vus pendant plus de 48 heures quand nous en dépendions pour les passations" source: "Expérience de notre équipe sur 3 mois de suivi informel"
3. Bouclez la boucle avec des captures d'écran, pas des suppositions
La forme la moins coûteuse de validation d'une passation design-ingénierie est une capture d'écran. Quand un ingénieur finit d'implémenter un composant, il colle une capture d'écran dans le PR ou l'issue et étiquette le designer. « Est-ce que ça correspond ? » prend dix secondes et détecte les 20 % de divergence avant que ça ne soit mis en production. Pas de réunion, pas de rituel de comparaison Figma – juste un PNG et une question.
Nous avons commencé à faire ça pour chaque PR d'UI, et le nombre de conversations « ça ne correspond pas au design » est tombé à presque zéro. Les conversations qui restent sont de vrais cas limites que le design n'a pas couverts, ce qui est bien – c'est le genre de chose qui devrait être discutée, pas le basique « vous avez utilisé 16px de padding au lieu de 12px ».
4. Laissez le contexte circuler automatiquement entre les outils
C'est là que je vais mentionner Sugarbug, parce que nous l'avons littéralement construit pour résoudre ce problème spécifique. Notre designer laisse un commentaire dans Figma sur un changement d'espacement. Sugarbug récupère ce commentaire, le connecte à l'issue Linear et au PR GitHub pertinents, et l'ingénieur le voit dans son flux de travail sans ouvrir Figma. La passation design-ingénierie cesse d'être un rituel manuel de copier-coller et devient quelque chose qui se produit simplement.
Mais si vous n'utilisez pas Sugarbug (et la plupart d'entre vous ne le font pas – nous sommes encore en pré-lancement), la version manuelle est : assignez quelqu'un comme « pont de passation » qui vérifie les commentaires Figma quotidiennement et copie le retour pertinent dans les issues Linear. C'est fastidieux, mais ça fonctionne, et c'est infiniment mieux que d'espérer que les ingénieurs se souviennent de vérifier Figma.
Si je ne me souviens pas de mes propres décisions de design du mardi dernier, il n'y a aucune chance qu'un ingénieur séparé capte tout depuis un fil de commentaires Figma. attribution: Chris Calo
Votre liste de contrôle pour la passation design-ingénierie
Si vous ne retenez qu'une chose de cet article, que ce soit ceci : la solution n'est pas de meilleurs outils (enfin, pas principalement – bien que j'en construise un, donc prenez ça avec des pincettes). La solution consiste à établir des normes sur l'endroit où vivent les décisions de design, et à s'assurer que cet « endroit » se trouve à l'intérieur du flux de travail naturel de l'ingénieur.
- [ ] Exportez les frames clés en PNG dans l'issue Linear (pas seulement un lien Figma)
- [ ] Écrivez le « pourquoi » de chaque décision de design majeure dans la description de l'issue
- [ ] Listez les cas limites connus (mobile, états vides, texte long) – ou signalez explicitement ce que vous n'avez pas encore résolu
- [ ] Déplacez le retour d'implémentation des commentaires Figma vers le fil de l'issue
- [ ] Exigez une capture d'écran dans chaque PR d'UI avant la validation du design
- [ ] Assignez une personne « pont de passation » si vous n'avez pas d'outils pour connecter Figma et Linear automatiquement
Foire aux questions
Q: Pourquoi les commentaires Figma échouent-ils comme outil de passation design-ingénierie ? A: Les commentaires Figma se trouvent à l'intérieur du fichier de design, déconnectés du flux de travail d'ingénierie. Les ingénieurs travaillent dans Linear, GitHub et leur IDE – pas dans Figma. Un commentaire sur un frame ne devient pas une tâche à moins que quelqu'un ne le copie manuellement, et c'est cette étape manuelle qui fait échouer la passation design-ingénierie. Ce n'est pas un problème humain, c'est un problème de frontières entre outils.
Q: Sugarbug connecte-t-il automatiquement les commentaires Figma aux issues Linear ? A: Oui – c'est l'un des problèmes spécifiques pour lesquels nous l'avons construit. Sugarbug récupère les commentaires Figma et les connecte aux issues Linear et aux PRs GitHub pertinents, de sorte que le retour de design apparaît dans le flux de travail de l'ingénieur sans que personne n'ait à copier-coller entre les outils. Nous l'utilisons nous-mêmes tous les jours, et la différence est (honnêtement) un peu embarrassante étant donné la simplicité de l'idée.
Q: Quel est le meilleur processus de passation design-ingénierie pour les petites équipes ? A: Écrivez la décision de design dans l'issue Linear avant que l'ingénieur commence à construire. Incluez le raisonnement, pas seulement le visuel. Si des cas limites surviennent pendant l'implémentation, discutez-en dans le fil de l'issue – pas dans un commentaire Figma que l'ingénieur doit chercher. Le processus le plus simple est souvent le plus durable.
Q: Comment gérer les changements de design une fois que l'ingénierie a commencé ? A: Traitez-les comme des changements de périmètre : documentez le changement dans l'issue avec un clair avant-et-après, expliquez le raisonnement et laissez l'ingénieur évaluer le coût d'implémentation avant de s'engager. Les pires échecs de passation se produisent lorsque des changements de design arrivent sous forme de commentaires Figma désinvoltes sur un travail déjà construit – c'est ainsi que l'on obtient des ingénieurs rancuniers et des designers frustrés.
Recevez l'intelligence des signaux directement dans votre boîte de réception.