Claude Design : du business plan aux maquettes implémentables en 3h

Entre un business plan validé et le moment où une équipe de développement peut commencer à coder, il y a souvent plusieurs semaines de discovery design : ateliers, wireframes, itérations, validation. Pour un fondateur en pré-seed qui veut confronter son produit au marché vite, c'est du temps qu'il n'a pas. J'ai voulu tester ce que Claude Design peut faire de cette phase quand on lui donne un dossier projet déjà structuré.

Le contexte : un dossier projet déjà mûr

Avant d'ouvrir Claude Design, le projet Bouch.ee avait déjà :

• Un business plan en 10 chapitres
• Un PRD détaillé en 10 modules
• Une analyse concurrentielle
• Un document de périmètre MVP validé
• Une stack technique posée (Expo pour le mobile, Next.js pour le web, Symfony côté API)

Tout ça vit dans un monorepo dédié, et une session Claude Code connaît cette mémoire. Le but n'était donc pas de partir d'une feuille blanche — c'était de demander à un outil de design de lire ce qui existe déjà et de matérialiser une UX cohérente avec.

Le process en sept étapes

Ce qui suit, c'est ce que j'ai effectivement fait. Pas un protocole théorique : un déroulé que j'ai itéré pendant la session.

1. Demander à Claude Code de rédiger le prompt

Première étape, et probablement la plus importante : je n'ai pas écrit moi-même le prompt pour Claude Design. J'ai demandé à Claude Code, qui connaît le projet, de me préparer un brief en piochant dans le BP, le PRD et le design système prévu côté code. Il devait préparer un design system en même temps — pour que les maquettes ne soient pas une bulle isolée, mais bien la suite logique de ce qui était déjà décidé.

Cette première version était propre, mais sage. C'était la base, pas l'arrivée.

2. Demander deux variantes franchement différentes

J'ai ensuite demandé à Claude Design de me proposer deux nouvelles variantes, avec instruction explicite de prendre des partis pris très différents. Il pouvait changer des choix produits, retirer ou ajouter des écrans, modifier le ton, repenser la navigation. Chaque variante avec son propre design system.

Le résultat a dépassé ce que j'attendais. La variante B est partie sur un fond très foncé, presque exclusivement organisé autour d'un module conversationnel — l'app comme un chat, point. La variante C a pris la direction inverse : un assistant papier, tactile, presque artisanal. Deux philosophies opposées sur le même problème, chacune avec une cohérence interne réelle.

3. Donner des retours comme à un Senior UX Designer

C'est là que la méthode bascule. Je préférais l'UI de la variante C, mais plusieurs idées de la B étaient à creuser. J'ai fait mes retours comme je les ferais à un designer senior : ce qui marche, ce qui ne marche pas, et pourquoi dans chaque cas. Je lui ai demandé une quatrième variante qui prenne le meilleur des deux, en mobile et en desktop.

Cette posture est non-négociable. Si vous traitez Claude Design comme un générateur d'images, vous obtenez des images. Si vous le traitez comme un collaborateur, vous obtenez du design.

4. Demander un fichier par écran

Claude Design est récent. La vue globale qui empile mobile + desktop pour 30 écrans devient lente très vite — et illisible. J'ai demandé qu'il isole chaque écran dans son propre fichier (avec mobile et desktop côte à côte), accompagné de commentaires expliquant les subtilités d'interaction de chacun. Et un fichier markdown séparé qui liste tous les écarts vs design initial.

Ce découpage a deux vertus : on revoit chaque écran de façon focalisée, et le markdown sert plus tard de document de spec quand on passe au code.

5. Repasser dans Claude Code pour l'implémentation

J'ai exporté la quatrième variante en zip et je l'ai déposée dans le workspace Claude Code. Je lui ai demandé de regarder le travail, de challenger les choix de Claude Design quand ça lui semblait pertinent, et de proposer un plan d'implémentation. Il y a eu quatre ou cinq challenges réels — des points où le designer avait pris une décision que le code rendait fragile ou disproportionnée. À chaque challenge, j'ai tranché.

Ensuite, l'implémentation a été déléguée à des subagents par sprints, avec un harnais de tests E2E (plus de cinquante journeys au total). C'est le pattern décrit dans « 51 stories, 4 sprints, 0 régression ».

6. Boucler avec une nouvelle itération design

Une fois le code en place, j'ai redemandé à Claude Code de me préparer un nouveau prompt pour Claude Design — pour mettre à jour les maquettes avec les choix d'implémentation et ajouter quelques fonctionnalités sur le signup que j'avais en tête en cours de route. Phase classique de specification → review → développement → itération, sauf qu'aucune des deux parties n'est humaine.

7. Réinjecter dans le code

Dernier round : Claude Design met à jour les maquettes, je relis, je commente, et je redonne le tout à Claude Code pour implémenter. Avec les tests E2E qui valident chaque story.

Ce que ça donne en chiffres

Mon temps personnel sur l'ensemble : environ 2 à 3 heures, presque exclusivement passées à reviewer et à faire des copier-coller entre les deux instances de Claude. Le temps machine cumulé est plus important — quatre à cinq heures, surtout sur l'implémentation. À comparer aux plusieurs semaines qu'un produit de la complexité de Bouch.ee aurait demandées avec le process classique : ateliers UX, wireframes, validation, itérations en agence ou en interne.

Et le résultat n'est pas un mockup plat : c'est un design system documenté, trente écrans avec leurs variantes mobile/desktop, et un changelog qui explique chaque écart par rapport au plan initial.

→ Voir les maquettes Bouch.ee (variante D-2)

Les limites observées

Trois choses à savoir avant de se lancer.

D'abord, Claude Design n'est pas autonome. Sans une mémoire projet déjà structurée — BP, PRD, périmètre — il produit des maquettes génériques. La qualité du résultat est directement corrélée à la qualité de ce qu'on lui donne en entrée.

Ensuite, la fluidité de l'outil reste perfectible sur des projets de cette taille. Le découpage en fichiers par écran est aujourd'hui un workaround pour rendre les itérations supportables.

Enfin, un œil produit + designer est indispensable côté humain. Pas pour dessiner — pour arbitrer entre variantes, repérer ce qui ne tient pas, savoir à quel moment passer de l'exploration à la convergence. C'est là que les vingt ans d'expérience pèsent réellement, pas dans la production.

Conclusion

Cette pipeline — Claude Code pour la mémoire et le code, Claude Design pour l'UX, un humain expérimenté pour piloter — est l'une des chaînes les plus productives que j'ai utilisées depuis longtemps. Elle ne remplace pas un Senior UX Designer sur un produit complexe à long terme. Mais pour cadrer rapidement un MVP de fondateur en pré-seed, elle change le rapport temps/qualité de façon difficile à ignorer.