L'IA et Claude Code transforment le design moderne

L'IA au service du design : une nouvelle méthode de travail

Dans le domaine du design, gérer un flux constant d'informations est un défi majeur. Entre la synthèse de recherche, les métriques produit, et les retours des parties prenantes, le suivi devient vite complexe. Traditionnellement, les outils d'IA se concentrent sur la génération visuelle, mais une approche plus réfléchie est possible.

Travailler sur un problème de design complexe signifie devoir gérer beaucoup d'informations. La synthèse de recherche, les métriques produit, un fil Slack avec les retours des parties prenantes, les commentaires Figma, les décisions prises lors de la dernière itération. Multipliez cela par le nombre d'itérations, et il devient difficile de suivre.

La plupart des outils d'IA se concentrent sur la génération visuelle. Interfaces utilisateur plus rapides, maquettes attrayantes, prototypes basés sur l'ambiance. C'est rapide et esthétique. Mais cela néglige la partie difficile. J'ai toujours pensé que le design consistait à résoudre des problèmes.

Alors, que se passerait-il si l'IA pouvait m'aider à réfléchir au problème plutôt ? Conserver tout le contexte du projet et faire ressortir la bonne information au bon moment. Quelque chose qui accumule le contexte tout au long de la vie d'un projet. Comme un palais de la mémoire ?

Une fois configuré, je peux passer d'un problème bien défini à quelques prototypes de code informés par les données rapidement. Pas une interface utilisateur basée sur l'ambiance. Des concepts ancrés dans le problème réel et le contexte du projet. Et je n'utilise pas un chat IA classique ou Projects.

Un contexte centralisé pour une meilleure réflexion

L'idée est de permettre à l'IA de conserver le contexte du projet, facilitant ainsi l'accès aux informations pertinentes au bon moment. En utilisant Claude Code, un système de gestion de mémoire a été mis en place pour centraliser toutes les données du projet, de la recherche initiale aux prototypes HTML fonctionnels.

Le contexte du projet est éparpillé à travers différents documents, outils et personnes. La recherche se trouve à un endroit, les métriques produit à un autre, les retours des parties prenantes dans des fils Slack que j'ai manqués. Chaque session de design commence par une réassemblage manuel du contexte. J'ai donc construit une banque de mémoire à partir de cela. Ensuite, j'ai appris à Claude Code à l'utiliser.

• my-project/
  • .claude/ : compétences spécifiques au projet
  • data/ : synthèse de recherche et métriques
  • design/ : explorations et retours par itération
  • project-context/ : détails figés du projet
  • handoffs/ : spécifications techniques
  • prototypes/ : prototypes fonctionnels
  • design-system/ : tokens et composants
  • CLAUDE.md : instructions personnalisées
  • MEMORY.md : index de contexte évolutif

CLAUDE.md personnalise Claude Code pour ce projet. MEMORY.md est l'index en cours de tout le contexte, des données et des décisions. Pensez-y comme une table des matières qui évolue constamment. Lorsque Claude a besoin d'informations, ce fichier lui indique où chercher.

design-system/ permet aux prototypes de ressembler au produit réel. Ma configuration est simple : des tokens de design (espacement, couleur, typographie) en tant que variables CSS. L'objectif à ce stade est de valider les flux et l'expérience utilisateur, pas l'exactitude visuelle. Je pourrais connecter ce projet à mon code de système de design, mais la configuration semblait trop chronophage.

Je stocke toutes les informations du projet au format markdown. Elles sont formatées de manière cohérente pour que l'IA puisse les récupérer plus facilement. Les notes brutes sont acceptables à l'entrée. Claude peut les aider à se structurer. Tout ce qui est confidentiel, je l'obscurcis d'abord.

Automatisation et personnalisation des processus

L'automatisation des processus répétitifs a été un autre axe d'amélioration. Des compétences telles que explore, brainstorm, synthesize, et prototyping ont été développées pour faciliter les itérations de design. Ces outils permettent de passer d'un problème défini à des prototypes de code, tout en intégrant les retours et en testant les directions selon les normes du projet.

Une fois que le projet avait tout son contexte, j'ai remarqué un autre problème. Je devais constamment réexpliquer les mêmes flux de travail : "Lisez le ticket, vérifiez la recherche, donnez-moi trois directions" à chaque fois. J'ai donc automatisé ces étapes avec des compétences.

• explore : aide à passer par une itération de design complète. Je lui donne un problème : un ticket, un brief ou une déclaration, et il lance une itération, en croisant les données disponibles et génère des prototypes de code pour chacun.

• brainstorm : pour déterminer quelles directions valent la peine d'être explorées.

• synthesize : prend de nouvelles données brutes et les intègre correctement dans le projet. Aide également à connecter de nouvelles découvertes aux données existantes.

• prototyping : construit des prototypes de code autonomes ancrés dans le système de design.

• design-partner : hautement personnalisé selon ma manière de travailler. Je l'utilise pour tester une direction par rapport à mes propres normes et aux objectifs du projet.

Je recommande vivement de prendre le temps d'ajuster ces compétences à votre style de travail, en particulier design-partner.

Connexion en temps réel aux outils de travail

Pour rester à jour, des protocoles de contexte modèle (MCPs) ont été mis en place pour extraire des informations en temps réel de plateformes comme Slack, Figma, et Linear. Bien que la configuration soit complexe, elle permet de maintenir un flux de travail fluide et de réduire les interruptions.

Au fur et à mesure que les projets évoluent, de nouveaux contextes émergent d'abord lors de réunions ou d'outils comme Slack, Figma ou Linear. Je préfère rester immergé dans le problème. J'utilise donc les MCPs (Model Context Protocol) pour extraire des informations de ces outils. La configuration prend du temps avec l'authentification et les autorisations. Mais une fois en marche, cela reste discret.

• Linear : Lorsque le problème se trouve dans un ticket, je pointe /explore dessus pour que Claude puisse rassembler le contexte, lire l'activité la plus récente et aussi aider à le maintenir à jour.

• Figma : Claude fait référence aux maquettes pour générer des prototypes précis. Figma MCP écrit également sur le canevas, ce qui est utile. Plus le Figma est structuré, mieux cela fonctionne. J'ai constaté de bons résultats en donnant à Claude une section bien définie et délimitée de maquettes plutôt que le lien vers l'ensemble du fichier.

• Slack : Les retours des parties prenantes, les nouvelles décisions, les changements de calendrier arrivent sur Slack avant d'atteindre un ticket. Apprendre à Claude où chercher le maintient à jour (et moi aussi).

Tous ces éléments sont optionnels. Mon projet a commencé sans aucun d'eux. Je voulais qu'il fonctionne de manière autonome d'abord. Les MCPs sont venus plus tard, lorsque j'ai remarqué des schémas dans mon flux de travail qui valaient la peine d'être automatisés. Plus de connexions signifient plus de choses qui peuvent se casser, donc il y a un équilibre à trouver.

Une nouvelle dynamique de collaboration

L'approche centrée sur l'IA a transformé la manière dont les prototypes sont perçus. Contrairement aux maquettes statiques, les prototypes de code encouragent une discussion axée sur l'expérience utilisateur plutôt que sur les détails visuels. Cela permet d'identifier rapidement les idées inefficaces et d'améliorer la collaboration avec les parties prenantes.

Une exécution de /explore est le début, pas la fin. La plupart des problèmes nécessitent plusieurs itérations. J'ai remarqué que plus je suis clair, moins j'ai d'aller-retour avec l'IA.

/explore enchaîne les compétences de brainstorming, de synthèse et de prototypage en une seule commande. Une invite déclenche une itération complète.

L'IA fait émerger des directions que j'utilise comme points de départ. Ces propositions sont loin d'être prêtes à être partagées ou expédiées. Je lui demande donc de faire ressortir des points de données pertinents. Mais je dirige ce qu'elle doit construire. Je reprends avec des maquettes Figma si nécessaire pour l'aider.

Une session typique. Certaines commandes sont des compétences, d'autres du langage naturel. Je lui parle comme à un collaborateur. Pas de réexplication. Elle connaît le projet.

Où en suis-je avec ce projet ? Sur quoi devrais-je me concentrer ensuite ?

• /explore le problème des états de chargement
• /design-partner évaluer les dernières solutions d'états de chargement
• /synthesize les retours des parties prenantes pour la révision 2 : [copie brute des retours collée]

Ma dernière itération pour les états de chargement est complète. Publiez une mise à jour. (cela enverra un message Slack et un commentaire Linear si le MCP fonctionne)

Entre les commandes, il y a le véritable travail de design. Esquisses, raisonnements, documents de spécifications, formation d'un point de vue avant de faire revenir Claude. Cela peut même signifier des maquettes rapides dans Figma.

/design-partner teste mes réflexions par rapport au problème. Une fois que je verrouille les directions, Claude les construit en prototypes de code. Bruts par choix. L'objectif est d'aligner sur la direction, pas de polir. Avant que quoi que ce soit ne soit envoyé à l'équipe, je le valide par rapport à la déclaration de problème originale (/design-partner peut aider).

Remise

Une fois aligné sur un prototype, je conçois des maquettes Figma pour les moments clés du flux. Ensuite, j'écris une spécification décrivant le flux : les étapes, avec des cadres Figma pour les moments clés.

Une fois la spécification écrite, Claude a un ancrage pour générer différents résultats à partir de celle-ci : prototype haute fidélité, carte de parcours ou plan de mise en œuvre.

Rédiger la solution est également un contexte pour l'IA. Cela devient l'ancre pour tout le reste. Claude peut l'utiliser pour construire un prototype haute fidélité, rédiger une carte de parcours, générer un plan de mise en œuvre pour le code. C'est aussi ce qui l'empêche d'halluciner, surtout avec des flux complexes.

Ce qui a changé

J'ai arrêté de repartir de zéro. Chaque session reprenait là où la dernière s'était arrêtée avec des décisions, des impasses, tout cela. Je pouvais passer d'un problème bien défini à des prototypes cliquables rapidement. Le changement de contexte a diminué. Je pouvais rester concentré sur le problème.

Les prototypes de code ont changé la dynamique des retours. Contrairement aux maquettes Figma statiques, ils n'étaient pas polis et pourtant cela a aidé. Les gens ont cessé de se concentrer sur les détails visuels et ont commencé à parler de l'expérience utilisateur. C'est la conversation que je veux plus tôt. Les mauvaises idées meurent plus vite aussi, avant que j'investisse trop.

Je suis les décisions par round dans le dossier design/. Plus besoin de fouiller dans les fils de commentaires Figma pour me souvenir pourquoi nous avons pris une décision il y a trois semaines. Synchroniser les parties prenantes ne ressemblait plus à de la gestion de projet. Claude lit les tickets Linear, les fils Slack et les dernières recherches. Je ne résume plus manuellement. Il sait déjà.

Résumé

La durée du projet a augmenté, plus d'informations ont été accumulées, et la collaboration est devenue plus fluide.