Design d'interface quand les ingénieurs le construisent aussi : moins de cycles, meilleurs produits

Résumé : Mieux vaut designer et coder ensemble avec de vrais composants et de vraies données—et traiter explicitement tous les états d'interface—qu'un handoff pixel-perfect.

Design et engineering sont d'habitude deux équipes assises dans des outils différents, parlant des langues différentes, et découvrant les contraintes de l'autre pendant la code review. Le résultat est un produit qui semble cousu — parce qu'il l'est. Chez nous, c'est différent : les gens qui dessinent l'interface sont les gens qui la construisent. Voici ce qui change quand on retire le handoff.

Le coût caché du handoff de design

Un cycle design-puis-build typique, c'est : 4 semaines de Figma, 2 semaines de « design review », 1 semaine de « questions engineering », 6 semaines de build, puis un mois frustrant de tickets « ce n'est pas ce que la maquette montre ».

Le problème, ce ne sont pas les mauvais designers ou les mauvais ingénieurs. Le problème, c'est que Figma ne peut pas imposer de vraies contraintes — performance, accessibilité, données edge case, états de chargement, états d'erreur, états vides. Les designers dessinent le happy path ; les ingénieurs découvrent les 80% restants le mercredi à 16h.

Ce qu'on fait à la place

1. Sketcher en low-fidelity, builder en vrai code

On utilise Figma seulement pour de l'exploration niveau whiteboard — boîtes, flèches, direction de copy. Dès qu'un flow est grosso modo validé, on le construit en vrai code avec de vraies données. L'itération se passe dans la vraie app, pas dans une maquette statique.

2. Une vraie librairie de composants, utilisée par la même personne qui dessine

Tailwind + shadcn/ui + un petit set de composants spécifiques au projet. Le designer-ingénieur compose les écrans de la même façon qu'il le ferait dans Figma, sauf que le résultat est livrable. Il n'y a pas de « design system » maintenu séparément de la prod.

3. De vraies données dès le jour 1

Pas de lorem ipsum. Pas de « John Doe ». On tire de vrais noms d'utilisateurs, de vrais noms de boîtes longs qui débordent, de vrais empty states, de vrais états d'erreur. Le produit a 10× meilleure mine à la démo parce qu'il est stress-testé depuis la semaine 1.

Les états que les designers oublient toujours

Presque chaque fichier Figma qu'on a reçu manquait au moins trois de ces points. C'est aussi de là que viennent la plupart des plaintes « l'app fait cheap » :

• Empty states avec onboarding. Pas « aucune donnée trouvée » — un vrai guide pour quoi faire en premier.
• États de chargement. Skeletons, pas spinners. Mimer le layout de ce qui charge.
• États d'erreur. Spécifiques, pas génériques. « Impossible d'enregistrer — votre session a expiré » bat « Une erreur est survenue ».
• États long-contenu. Que se passe-t-il quand le nom de la boîte fait 80 caractères ? Quand la description a 12 paragraphes ?
• États de permission. Que voit un viewer vs un admin ? Quand les boutons sont cachés vs désactivés vs visibles-mais-expliqués ?
• Mobile. Pas une « version responsive » — un vrai design mobile, avec des interactions mobile-first.

Ce qu'on a arrêté de faire

• Les maquettes pixel-perfect. Elles deviennent obsolètes à la seconde où une vraie chaîne est plus longue qu'attendue.
• Les réunions de design review sans build qui marche. Une opinion sur un screenshot statique vaut une fraction d'une opinion sur un prototype cliquable.
• Les design systems custom avant le product-market fit. shadcn/ui + Tailwind couvre 90% des cas. Construisez le vôtre seulement quand la marque est le produit.
• Les animations comme feature. La plupart des animations « delightful » ralentissent les gens. On utilise le motion seulement pour communiquer des changements d'état, jamais en décoration.

Le résultat, mesuré honnêtement

Sur les projets récents, le temps entre « premier écran sketché » et « écran en prod » est passé de ~5 semaines à ~1,5 semaine. Les tickets bug liés au design ont chuté d'environ 70%. Le nombre de réunions « ce n'est pas ce qu'on avait dit » est tombé à presque zéro — parce que la chose discutée tourne déjà.

Un bon design d'interface n'est pas un livrable. C'est une propriété d'un produit qui a été construit et reconstruit par des gens qui se soucient à la fois de comment il a l'air et de ce qu'il fait.