Comment utiliser Claude dans le design : briefs, textes UI, critique et handoff

Claude peut accepter une image, donc tu peux déposer une capture d'écran d'un cadre Figma, d'un wireframe ou d'un écran livré et lui poser des questions directement : cette hiérarchie a-t-elle du sens, l'action principale est-elle évidente, est-ce cohérent avec le motif utilisé sur l'écran précédent.

Il lit les pixels à la manière d'une personne qui parcourt une capture d'écran, pas en analysant la structure des calques ou les propriétés des composants de ton fichier Figma. Il ne connaîtra pas tes tokens de design, ta bibliothèque de composants, ni quel cadre est le « vrai » à moins que tu ne le lui dises. Traite-le comme une seconde lecture rapide, pas comme un relecteur qui connaît ton design system.

La version la plus utile de cet usage est étroite : un écran, une question précise. « L'état d'erreur est-il clair ici » donne une réponse plus affûtée que « revois tout ce flux », de la même façon qu'un coéquipier donne une meilleure réponse quand tu lui demandes quelque chose de précis plutôt que de lui tendre tout le fichier.

Imagine qu'un projet démarre comme la plupart : un fil Slack avec un product manager, une conversation de couloir à moitié oubliée, et quelques lignes dans un ticket qui ne s'accordent pas tout à fait entre elles. Plutôt que de fixer un modèle de brief vide, colle tout ça dans Claude comme matière première et demande-lui de trier le signal du bruit.

Demande directement les éléments dont un brief a besoin : quel est le vrai problème à résoudre, quelles contraintes ont déjà été mentionnées (une échéance, une limitation de plateforme, une règle de marque), ce qui compterait comme un succès, et ce qui reste non résolu. Claude fait souvent remonter une contradiction que tu avais manquée, comme une contrainte mentionnée une fois tôt dans le fil puis abandonnée plus tard.

Le résultat n'est pas final. C'est un premier jet déjà organisé plutôt qu'une page blanche, ce qui veut dire que le travail d'édition que tu fais ensuite affine du contenu réel au lieu d'inventer une structure à partir de rien. C'est là le vrai gain de temps : pas l'écriture en elle-même, mais le fait de sauter l'étape de la page blanche.

Lire sur ces workflows et les exécuter réellement sont deux compétences différentes. Le parcours de démarrage ci-dessous est conçu pour combler cet écart en trois courtes leçons, dans cet ordre.

Commence par « Les trois façons d'utiliser Claude » du cours Les trois modes, une leçon de cinq minutes qui couvre la différence entre un échange rapide, une session de co-travail plus longue en aller-retour, et Claude Code. La plupart du travail de design, qu'il s'agisse d'une question de critique, d'une passe de textes ou d'un brief, vit dans les deux premiers modes, donc cette leçon t'aide à choisir le bon au lieu de te limiter à l'onglet qui se trouve être ouvert.

Passe ensuite à « Le contexte, c'est tout » du cours Prompting stratégique, aussi cinq minutes. C'est la leçon qui transforme un brief générique en un brief qui reflète ton vrai projet : elle couvre ce qu'il faut coller (tes vraies notes, ton ton de marque, l'écran précis) pour que Claude ne devine pas un contexte qu'on ne lui a jamais donné.

Termine avec « La boucle d'itération » du cours Maîtriser les fondamentaux, une leçon de six minutes sur le fait de traiter la première réponse de Claude comme un brouillon plutôt qu'un verdict. Pour un designer, c'est la différence entre accepter le premier jeu d'options de texte UI qu'il te donne et vraiment réduire huit options à deux à travers quelques tours de suivi.

L'écart entre une réponse générique et une réponse utile, c'est presque toujours le contexte que tu lui as donné. Pour le travail de design en particulier, ça veut dire coller les éléments qui vivent dans ta tête ou tes fichiers mais qui n'arrivent jamais dans un prompt court : les vraies notes de réunion plutôt que ton souvenir de celles-ci, tes règles de ton de marque si tu les as écrites quelque part, et la capture d'écran précise plutôt qu'une description d'un écran.

Ça veut aussi dire être précis sur le périmètre. « Revois ce flux » invite une réponse vague et éparpillée. « Regarde l'écran de confirmation et dis-moi si l'action secondaire concurrence la principale » invite une réponse utile. Plus la question est étroite, plus elle vaut la peine d'être posée.

Si tu vas poser le même type de question à répétition, comme la même vérification d'accessibilité sur chaque nouvel écran ou la même consigne de ton pour chaque texte UI, ça vaut le coup d'écrire ce contexte une fois et de le réutiliser, plutôt que de réexpliquer ton ton de marque dans chaque conversation.

Claude ne génère pas d'UI prête pour la production, ne manipule pas ton fichier Figma, et ne connaît pas tes règles de marque par cœur à moins que tu ne les colles. Il ne peut pas non plus valider la finition visuelle comme le ferait un œil entraîné ; il raisonne sur la structure, la hiérarchie et la clarté à partir de ce qui est visible dans l'image, pas sur le fait qu'une chose « sonne juste » au niveau du pixel.

Pour l'accessibilité, traite ses vérifications comme une première passe, pas comme une validation. Le vrai travail d'accessibilité demande des outils de vérification de contraste, des tests avec lecteur d'écran, et souvent une relecture par un spécialiste, surtout pour tout ce qui est livré à un large public. Ne dis pas à une partie prenante ou à un relecteur de conformité qu'un design a été vérifié pour l'accessibilité parce que Claude a regardé une capture d'écran.

La même prudence s'applique avant que quoi que ce soit parte vers un client, un utilisateur ou un coéquipier : relis ce que Claude a produit avant de l'envoyer. Un doc de handoff avec une note d'interaction fausse mais formulée avec assurance est pire que l'absence de doc, parce qu'un ingénieur va construire à partir de lui.

Il n'est aussi bon que ce qu'on lui donne. Un brief écrit à partir d'un prompt de deux lignes sonnera générique ; un brief écrit à partir d'une vraie transcription de conversation ou de vraies notes reflétera réellement le projet.