Figma

Figma intervient avant les outils no-code, et c'est ce qui rend nos projets prévisibles. Maquetter avant de construire coûte quelques jours ; le découvrir après avoir construit coûte le projet. Chaque interface que nous livrons a d'abord existé comme prototype cliquable, validé par ceux qui allaient s'en servir.

Maquetter et faire valider

Un prototype Figma se parcourt comme l'application finale, écran par écran, sans qu'une ligne ait été produite. C'est le moment le moins cher pour changer d'avis, et le seul où les utilisateurs peuvent réagir à autre chose qu'une description.

Sur la conception d'une plateforme destinée à faciliter les échanges entre parents et assistantes maternelles, cette étape a été déterminante : les maquettes interactives ont permis d'ajuster l'interface aux usages réels des deux publics — qui n'avaient ni les mêmes habitudes ni les mêmes contraintes — avant que quoi que ce soit ne soit figé.

Tenir la cohérence d'un projet

Les composants réutilisables et les styles partagés font qu'un bouton, une couleur ou un espacement se décident une fois. Sur un projet qui dure, c'est ce qui évite la dérive visuelle où chaque écran ajouté ressemble un peu moins aux précédents.

Passer du design à la construction

Figma sert de référence commune entre ceux qui conçoivent et ceux qui assemblent. Le partage en temps réel et les commentaires posés à même la maquette remplacent les allers-retours par e-mail, et le passage au montage dans WeWeb, Softr ou Bubble se fait sur une base non ambiguë : les écrans sont décidés, il reste à les brancher.

Sa place exacte dans un projet no-code

Figma ne produit pas l'application — il produit l'accord sur ce qu'elle doit être. C'est pour cela que nous ne le sautons pas, même sur les projets courts : une maquette est le seul document qu'un client, un utilisateur et un constructeur lisent de la même façon.