Je design avec Claude plus qu'avec Figma maintenant

Le vrai tournant : le prototype au lieu de la proposition

Edwin a longtemps été sceptique sur les LLMs. Copilot, Cursor, Gemini — elle les a essayés sur ses points forts (le design, le code) et ils ont déçu. Mais en rejoignant Jane Street l'été dernier, elle s'est retrouvée confrontée à l'OCaml, Bonsai, et au domaine financier — terrains où elle n'était pas experte. Et là, stupeur : Claude a transformé non pas ses faiblesses, mais sa plus grande force : son workflow de design.

Avant : doc → maquette → allers-retours sans fin

Tu décris le problème, tu fais une maquette Figma, tu l'envoies à l'équipe dev, ils la développent, tu revérifies. Chaque changement d'avis coûte du temps à quelqu'un d'autre. Les petites améliorations (bouton retouché, texte ajusté) ? Elles ne se font jamais parce que c'est trop lourd.

Après : description → Claude construit → tu vois vraiment

Edwin écrit le problème en texte. Elle ouvre Claude dans son éditeur et dit « construis ». En quelques minutes, elle a un truc qui marche. Elle passe des jours à vivre avec, à l'utiliser, à demander des ajustements. 50 changements d'avis ? Claude s'en fout. Elle a retouché un bouton, ajouté des raccourcis clavier, réécrit le texte, et généré des messages de confirmation — du travail qui aurait demandé des échanges sans fin avant.

Résultat : tout l'effort va dans le livrable réel, rien dans le faux-vrai travail (Figma, docs formatées, allers-retours).

Quand ça a pris de l'ampleur

Au début (l'été dernier), elle n'utilisait Claude que pour des petits trucs : corriger une UX cassée. Les grosses idées restaient en Figma. Puis, deux choses se sont passées : les modèles se sont améliorés, et elle a appris à bien les utiliser.

Aujourd'hui elle code des prototypes de 2000+ lignes avec Claude. Elle intègre des données, modifie des modèles de données, construit des bibliothèques, et même des applis entièrement nouvelles — parfois en sautant Figma, en itérant le design directement avec Claude.

Le pouvoir : les designers peuvent enfin tester seuls

Les ingénieurs ont toujours pu faire une preuve de concept en solo quand une idée les frappe. Les designers, eux, devaient convaincre quelqu'un de la construire. C'était une barrière énorme.

Maintenant ? "Requête SQL en langage naturel" — idée vague, faisabilité inconnue. Avant, elle aurait dû demander à un dev de sacrifier son temps pour un proto risqué. Maintenant elle le fait en 2h, et quand elle le montre à son équipe, ils peuvent vraiment l'utiliser. Pas d'imagination requise. Ça change tout.

Le risque caché

Mais Edwin soulève une question pertinente : en codant ses idées directement avec Claude, reste-t-elle fluide et créative ? Ou Claude l'enferme-t-elle dans un mode itératif, contrainte par "ce que Claude peut faire" ?

C'est une vieille tension. Quand elle a commencé en 2011, il y avait un débat : est-ce que les designers doivent coder ? Les critiques disaient que coder te rend moins capable de grands pivots. Elle a codé quand même. Elle aimait ça. Plus tard, quand React est devenu complexe, elle s'est spécialisée (Figma surtout). Maintenant, avec Claude, elle est de retour à faire le truc vrai. Et c'est libérateur.

L'ajustement d'équipe

Il reste un truc à résoudre : quand tu fournis un prototype fini, le relecteur pourrait penser "je dois juste vérifier le code ?" Non. Edwin le rappelle à son équipe : c'est un document de proposition vivant, le code est jetable, et c'est un terrain d'itération commune — pas quelque chose de définitif.

En pratique, les relecteurs reprennent l'idée, la réimplémentent en prod en s'appuyant sur le proto. Ça marche. Pour l'instant.