Pourquoi nous commençons toujours par Figma

Nous avons fait l'erreur une fois : nous lancer dans le code sur la base d'un brief un peu flou, d'une vague idée et d'une pile de références Pinterest. Le projet a pris trois fois plus de temps que prévu. Depuis, Figma est devenu notre point de passage obligatoire.

Ce n'est pas une question de tendance. C'est une question de clarté. Un écran qui existe dans Figma est un écran qui a été débattu, contesté, validé. Le code, lui, n'est plus qu'une traduction mécanique d'une décision déjà prise.

Ce que Figma révèle que le texte cache

Un cahier des charges peut dire "l'utilisateur doit pouvoir filtrer les résultats". Figma vous force à répondre à : filtrer par quoi, combien de filtres actifs en même temps, que se passe-t-il quand il n'y a aucun résultat, comment les filtres se comportent en mobile, est-ce qu'on affiche un compteur.

Ces questions arrivent toujours. La seule différence, c'est le moment où elles arrivent. En phase de design, elles coûtent quelques itérations. En phase de développement, elles coûtent un refactor.

Itérer sur une maquette, pas sur du code

Déplacer un bouton dans Figma prend trente secondes. Déplacer un bouton dans une codebase React, c'est parfois trente minutes : il faut ajuster les composants, les tests, les dépendances, les cas responsive. Multiplié par les dizaines de micro-décisions d'un projet, la différence devient énorme.

Nous préférons faire vingt versions d'un écran dans Figma avec le client, puis coder la bonne, plutôt que de coder une version et de la défendre pendant trois semaines.

Le vrai gain : l'alignement

Quand le client valide une maquette Figma, il valide une vision concrète. Il sait à quoi son produit va ressembler. Il n'y a plus de surprise à la livraison, plus de "ah, ce n'est pas ce que j'imaginais". Et ça, ça change tout pour la relation client et la qualité finale du produit.