Design Prototyping plugin

Contexte

Kls édite des logiciels de gestion de dette pour les banques et les institutions financières. Un domaine dense, très normé, où les écrans manipulent des volumes d’information considérables : un tableau de suivi de dossiers n’a pas le même comportement selon qu’il porte dix lignes ou dix mille.

J’y ai rejoint l’équipe produit comme Design System Lead, avec pour mission principale la restructuration complète du design system.

Une particularité de mon poste chez Kls : j’ai accès à la codebase. Je ne fabrique pas seulement des maquettes, je prototype directement dans le code du produit. Ce que l’on teste ressemble à ce qui existera, et pas à une approximation cliquable comme on pouvait avoir avant avec les prototypes Figma.

Cette façon de travailler ne serait pas tenable sans un assistant de code. J’utilise Claude Code au quotidien, qui écrit le code que je ne saurais pas écrire moi-même, à partir de mes intentions de designer.

Audit

Afin de qualifier au mieux le besoin il a fallu se pencher sur 3 axes :

État des lieux

Le problème s’est imposé de lui-même après quelques semaines de prototypage.

Un exemple parmi cent : changer un espacement de 20 à 24 pixels. En pratique, cela voulait dire écrire un prompt, nommer précisément l’élément concerné pour lever toute ambiguïté, attendre, puis regarder le résultat. Pour un ajustement de deux pixels. Multiplié par vingt sur un seul écran.

Sur Figma, ce même geste me prend quelques secondes. L’écart n’était pas dans mes compétences, il était dans l’outil utilisé.

Deux autres frictions se sont ajoutées :

D’abord, la perte du contexte. Les outils d’inspection du navigateur permettent de modifier des valeurs à la volée, mais tout disparaît au rechargement de la page. Impossible d’accumuler un travail d’ajustement sur plusieurs écrans.

Ensuite, la dérive hors du système. Quand on décrit une valeur en langage naturel, on décrit un nombre. Or dans un design system, 24 pixels n’est pas un nombre : c’est un token. Rien ne garantissait que l’ajustement demandé se traduise par le bon token plutôt que par une valeur en dur.

J’ai regardé ce qui existait. Plusieurs outils s’approchent du besoin, mais chacun buttait sur un point : soit ils appliquent directement les modifications dans les fichiers, ce qui est risqué sur une codebase de production, soit ils ne fonctionnent que sur une stack technique différente de la nôtre, soit ils ignorent complètement la notion de design token.

Aucun ne collait à 100 % à notre façon de travailler.

Conception de l’outil

J’ai donc défini l’outil dont j’avais besoin, en partant de ce que je connais le mieux : le panneau de propriétés de Figma.

Le principe de départ, et la décision la plus structurante du projet : Vernier ne modifie jamais le code. Il applique les ajustements visuellement, dans le navigateur, et les accumule. À la fin, un bouton génère un prompt unique qui décrit l’ensemble du travail, à coller dans ma session Claude Code, qui procède à la vraie modification.

Ce choix résout trois problèmes d’un coup. Aucun risque sur la codebase, puisque rien n’est écrit. La possibilité d’itérer librement avant de valider, comme on le fait sur une maquette. Et surtout, le fait que la modification finale soit écrite par l’assistant, qui connaît les conventions du projet, plutôt que par un outil qui poserait des valeurs brutes.

J’ai ensuite spécifié le comportement attendu, point par point : les propriétés à exposer, la façon de choisir la portée d’un ajustement, la persistance entre les écrans, le retour aux valeurs d’origine. Puis j’ai développé l’outil avec Claude Code, en avançant par lots et en testant à chaque étape.

Ce que fait Vernier

Un panneau de propriétés dans la page. Vernier s’ouvre à droite du prototype, sans le quitter. Je clique un élément, j’ajuste ses dimensions, ses espacements, sa typographie, ses couleurs, ses radius, etc. La page se met à jour immédiatement.

Un arbre de calques. Naviguer dans une interface dense au clic seul est vite pénible. Vernier expose la hiérarchie des éléments comme le panneau gauche de Figma, avec le surlignage croisé entre l’arbre et la page. Je peux aussi y déplacer des éléments directement à la souris.

Les tokens du design system. C’est le point qui distingue Vernier d’un simple inspecteur. Le panneau lit le fichier de tokens du projet : quand je règle un espacement ou une couleur, je choisis dans la palette du système, et c’est le nom du token qui part dans le prompt, pas un pixel en dur. Une saisie libre reste possible, mais elle est signalée comme sortant du système.

Le choix de la portée. Un ajustement peut concerner cet élément précis, tous les éléments issus de la même ligne de code, ou le composant partout où il est utilisé. Cette distinction est indispensable : élargir la largeur d’une cellule de tableau doit toucher toute la colonne, pas une cellule isolée.

La persistance. Les ajustements s’accumulent d’un écran à l’autre et survivent au rechargement de la page. Je peux travailler une session entière avant de valider quoi que ce soit.

Un prompt unique. À la fin, un bouton compile tout : chaque modification, sa portée, le fichier et la ligne concernés, le token retenu. Un seul prompt à coller, au lieu de vingt allers-retours.

Conclusion

Ce qui me prenait dix minutes m’en prend deux. Le gain n’est pas seulement du temps : c’est la possibilité d’itérer sans réfléchir au coût de chaque essai, ce qui change la façon même de travailler un écran.

Un effet de bord auquel je ne m’attendais pas : parce que les ajustements sont accumulés puis envoyés en une fois, la consommation de l’assistant baisse nettement. Un prompt au lieu de vingt.

Sur le fond, ce projet m’a confirmé quelque chose sur mon métier. Face à une friction quotidienne, le réflexe n’a pas été de chercher une licence, mais de regarder si nous pouvions construire la solution la plus adaptée. Des outils proches existaient, mais aucun ne répondait complètement à notre contexte. Celui-là, si : il est fait pour nos prototypes, notre design system, notre stack.

Je n’ai rien inventé ni révolutionné. J’avais un problème concret dans mon quotidien, je l’ai réglé.