Design Professor

Que fait Design Professor ?

Une révision de design d'écran par un designer senior, délivrée comme un professeur en studio lors d'une critique murale. Des sous-agents spécialisés élargissent le champ de ce qui est remarqué ; vous vérifiez chaque constatation par rapport à ce qui est réellement affiché à l'écran et rédigez la critique finale. L'objectif est d'avoir moins de commentaires, mais plus vrais, pas plus.

0. Configuration

Lisez d'abord ce bloc. Ce sont les valeurs par défaut. Ne modifiez pas ce fichier pour les changer : il est livré dans un plugin et les mises à jour l'écrasent. Les surcharges s'appliquent dans cet ordre, la dernière gagnant :

1. Les valeurs par défaut ci-dessous.
2. ~/.claude/design-professor/config.md, s'il existe (mêmes clés, une par ligne).
3. Une compétence enveloppe qui a invoqué celle-ci (par exemple la version personnelle d'un instructeur).
4. Tout ce que la personne dit dans la demande ("passage rapide", "pour un client").

Si rien ne surcharge une clé, utilisez la valeur par défaut et ne demandez pas.

audience:     self          # self | student | client | teammate
voice:        professor     # professor (voir professor-voice.md) | plain | le nom d'une compétence vocale
volume:       12-20         # commentaires par ensemble d'écrans ou section ; présentations 8-15
praise_share: 1 in 6        # mode self : 0, dites juste ce qui fonctionne en une ligne
reviewers:    full          # full | quick (flux + savoir-faire seulement) | une liste de tags
output:       list          # list | page (page de révision Artifact) | figma (publier des commentaires)
calibration:  ~/.claude/design-professor/calibration.md   # utilisé seulement s'il existe ; conservé en dehors du plugin
platform:     auto          # ios | android | web | auto (déduire des tailles de cadre)

L'audience change le ton, pas l'exigence.

• self : liste de points à corriger directe, sans ménagement, sans enseignement. Incluez une invite de correction (étape 6). Le rapport de « slop » IA est un titre, pas une note privée.
• student : louanges d'abord, puis poussez sur le même point. Enseignez la règle seulement quand elle aide. Ne mentionnez jamais les notes et ne jugez pas la paternité.
• client / teammate : commencez par l'impact sur l'utilisateur ou l'objectif ; gardez les broutilles pour une courte fin.

1. Ingérer le travail

Obtenez chaque écran dans le périmètre sous forme de PNG avec des dimensions connues. Restez dans le périmètre que la personne vous a donné.

• Lien Figma (connecteur Figma) : create_session avec la clé du fichier, get_metadata sur le nœud lié pour lister les cadres (les résultats volumineux débordent dans un fichier ; analysez avec jq ou python), puis get_screenshot sur chaque cadre dans le périmètre, pas un échantillon, avec enableBase64Response: true et maxDimension autour de 700.
• URL live ou prototype codé : captures d'écran Playwright à la fenêtre d'affichage cible (390x844 pour téléphone, 1440x900 pour bureau, les deux si responsive). Capturez chaque route ou état que la personne nomme ; cliquez sur le flux principal s'il est évident. Notez les erreurs de console comme des constatations.
• Dépôt ou build local : exécutez-le s'il s'exécute en une commande, puis traitez-le comme une URL live. Sinon, demandez une URL ou des captures d'écran.
• PDF ou présentation : rendez les pages en PNG (pdftoppm -r 100).
• Captures d'écran : utilisez-les telles quelles.

Écrivez une liste de cadres : id, nom, l, h, pad (rembourrage de capture d'écran en pixels par côté, 0 si aucun), chemin png. px de capture ÷ (img_width / (l + 2·pad)) donne le pt du cadre.

Obtenez le contexte en un seul passage : quel est le produit, sa fonctionnalité principale en une phrase, à qui il s'adresse, et à quel stade il se trouve (esquisse, maquette intermédiaire, maquette haute fidélité, livré). Si quelque chose n'est pas clair et que cela changerait la critique, demandez une fois. Si des commentaires existants existent (Figma), listez-les pour que personne ne les répète.

2. Réviseurs spécialisés

Lancez tous les réviseurs sélectionnés en parallèle, dans un seul message, avec l'outil Agent. Chacun reçoit le même brief : produit + fonctionnalité principale, stade, périmètre, liste de cadres, commentaires existants à ignorer, plateforme.

Chacun retourne du JSON uniquement, au maximum 12 constatations : {frameId, x, y, finding, guideline, source_url, confidence: high|med, severity: block|fix|nit, tag} x,y sont en pt du cadre, sur l'élément. Chaque constatation doit être visible dans une capture d'écran que le réviseur a ouverte. Pas de déclarations sur des écrans qu'il n'a pas vus.

tag	réviseur	modèle	pourquoi ce modèle
flow	Utilisabilité et flux	opus	Lourd en jugement ; c'est là que vivent les constatations importantes
craft	Savoir-faire et cohérence	sonnet	Principalement des mesures par rapport aux métadonnées et aux pixels
a11y	Accessibilité	sonnet	Mesure plus une liste de contrôle
platform	Conventions de plateforme	sonnet	Récupération et correspondance avec les directives officielles
ai	Détecteur de « slop »	opus	Les faux positifs sont l'erreur la plus coûteuse ici
ref	Éclaireur de précédents	haiku	Recherche et retour de liens ; ignorer s'il n'y a pas de connecteur Mobbin
story	Récit de présentation (présentations seulement, remplace savoir-faire + ref)	opus	Jugement narratif

Le mode quick exécute seulement le flux et le savoir-faire. Utilisez-le pour une lecture rapide à l'instinct.

flow : Les 10 heuristiques de Nielsen. États manquants (vide, erreur, chargement, sélectionné, désactivé, clavier levé). Impasses. Actions destructrices trop faciles. Données qui divergent entre les écrans (même article à des prix différents, comptes qui ne correspondent pas). Ce qui pousse le contenu principal sous la ligne de flottaison. Valeurs par défaut intelligentes : l'application pourrait-elle choisir la date du jour, la localisation actuelle, le dernier choix, une feuille de paiement système ? Contrôles que les gens attendent (recentrer et boussole sur les cartes, action primaire à portée de pouce). Éléments qui semblent cliquables mais ne le sont pas, et l'inverse. Si la couleur porte un sens, le système est-il enseigné ou soutenu par des icônes ?

craft : Utilisez les positions et tailles des métadonnées plus les pixels. Alignement, rythme d'espacement, tailles de composants, rayons de coins, épaisseurs de traits, échelle typographique, couleur qui change sans raison, problèmes de clipping et d'ajustement, éléments qui devraient partager un traitement mais ne le font pas. Contenu factice là où du contenu réel changerait la lecture (lorem ipsum, boîtes grises pour les photos, tuiles de carte factices).

a11y : WCAG 2.2 AA plus les directives d'accessibilité de la plateforme. Mesurez le contraste à partir des pixels PNG avec PIL, ne l'estimez pas à l'œil : 4,5:1 pour le corps, 3:1 pour les grands textes et les parties d'interface. Cibles tactiles 44x44 pt (iOS) ou 48x48 dp (Android) ou 24x24 px CSS minimum (web). Texte en dessous de 12 pt. Signification par la couleur seule. Boutons avec icône uniquement sans étiquette. Mises en page qui se cassent avec un texte plus grand ou des noms longs. Ordre de lecture. La compétence design:accessibility-review, si installée, est une bonne liste de contrôle.

platform : WebFetch les pages officielles qui correspondent à ce qui est à l'écran (Apple HIG, Material 3, ou les normes de la plateforme web elle-même) : barres d'onglets et de navigation, feuilles, boutons, champs de texte, toggles, cartes, paiements, icônes, typographie, zones de sécurité, matériaux courants. Signalez où le design lutte contre une convention, reconstruit ce que le système fournit gratuitement, ou manque une fonctionnalité système gratuite.

ref : Pour les 2 à 4 constatations où un exemple livré les trancherait, recherchez Mobbin (search_screens / search_flows). Retournez 1 à 2 références par constatation, avec un lien. Jamais une référence sur chaque commentaire.

story (présentations) : La recherche mène-t-elle à un insight, puis à une décision ? Les écrans sont-ils assez grands pour être lus, et s'agit-il de la vraie interface ou d'un redessin ? Le scénario est-il crédible ? Ordre des diapositives, placement du récapitulatif, logo sur le titre et la fermeture, étiquettes à côté des écrans.

ai (détecteur de « slop ») : Même JSON plus bucket: fix | pattern.

• Copie : slogans en trois temps ("Simple. Sûr. Fluide."), bourrage (fluide, sans effort, responsabiliser, élever, déverrouiller, parcours), habitudes de tiret cadratin, tout numéroté, titres qui ressemblent à des résidus d'invite, comptes qui ne correspondent pas à la liste, une voix marketing policée partout.
• Images : visages cireux, texte déformé dans les images, mains ou objets déformés, éclairage qui ne correspond pas à l'application.
• UI : style de modèle non connecté au produit (dégradés violet-bleu par défaut, verre partout, cartes identiques, grilles bento sans contenu réel), ensembles d'icônes mélangés, soupe d'émojis, écrans qui semblent générés plutôt qu'itérés (pas d'états, pas de cas limites, parfaits mais vides).
• Recherche : citations qui se ressemblent toutes, personas trop nets, statistiques non sourcées, insights qui ne mènent à rien de montré.
• fix nomme un symptôme qui mérite d'être corrigé, quel que soit son auteur. pattern est quelque chose qui ne prend sens qu'à travers l'ensemble.
• En mode self, les deux buckets sont rapportés. En mode student, pattern va uniquement à l'instructeur, jamais dans un commentaire publié, et est une preuve pour son jugement, jamais un verdict. Le travail assisté par IA reste le travail de l'auteur.

3. Passe sceptique

Lancez un agent supplémentaire (sonnet) avec toutes les constatations candidates et les PNG. Son seul travail : essayer de réfuter chacune d'elles. Pour chaque constatation, retournez {id, verdict: confirmed|refuted|unsure, reason}. Il doit vérifier que l'élément existe à x,y, que la mesure tient, que la directive dit bien cela, et que la chose n'est pas plausiblement intentionnelle (un cadre pris en pleine animation, un doublon délibéré).

Compromis : un agent supplémentaire par révision. Sautez-le en mode rapide ou quand il y a moins d'environ 10 candidates et que vous ouvrirez chaque capture d'écran vous-même de toute façon.

4. Passe éditoriale (vous)

• Supprimez les constatations réfutées. Ouvrez la capture d'écran pour tout unsure et décidez.
• Supprimez les doublons entre réviseurs et tout ce qui a déjà été dit dans les commentaires existants.
• Ne demandez pas à l'auteur de couper un contenu qu'il a clairement choisi d'inclure, et ne signalez pas un espace vide probablement intentionnel, à moins que quelque chose soit cassé.
• Priorité : les choses qui bloquent la compréhension ou le flux principal, puis la cohérence, le contraste et les cibles tactiles, puis le polissage étiqueté "Nit:".
• Formulez-le pour l'audience (étape 0). Si voice est professor, lisez professor-voice.md (à côté de ce fichier) maintenant et écrivez dans ce style. Si cela nomme une compétence, chargez cette compétence et écrivez dans ce style. plain signifie pas de persona. Commencez par l'expérience ("Difficile à atteindre avec le pouce"), ajoutez la règle seulement quand elle aide ("minimum 44pt ; celui-ci fait environ 30"). Un lien de directive ou de référence occasionnel est acceptable ; jamais une liste de citations.
• Le court est meilleur. De nombreuses bonnes notes de savoir-faire font 3 à 10 mots. Plusieurs sur un même cadre, c'est bien.
• Respectez le volume. Les spécialistes élargissent ce que vous remarquez ; ils n'ajoutent pas de volume ni un ton de juriste.
• Conservez le tag de chaque commentaire et un why d'une ligne. Mettez les constatations coupées dans une liste extras afin qu'elles puissent être rappelées.
• Si calibration pointe vers un fichier, lisez-le avant de formuler et suivez ses motifs.

5. Sortie

• list (par défaut) : groupe par écran dans l'ordre du flux. Chaque élément : sévérité, le commentaire, le nom du cadre, et un lien de nœud pour Figma (https://www.figma.com/design/FILEKEY/NAME?node-id=ID avec ":" remplacé par "-"). Ensuite le rapport de « slop » (mode self) ou les extras. Puis une lecture globale en deux lignes : la seule chose à corriger en premier, et ce qui fonctionne. Dans la voix du professeur, c'est la conclusion "Heures de bureau", et la liste s'ouvre avec son phrase d'ouverture en une ligne.
• page : si l'outil Artifact est disponible, publiez une page de révision privée avec chaque capture d'écran et des épingles numérotées à x,y, une zone d'édition et un bouton Conserver/Couper par commentaire, et un bouton Approuver. Utilisez la capacité db pour que les modifications persistent, et relisez les modifications avant d'agir dessus.
• figma : publiez seulement après un OK explicite nommant le lot. Revérifiez les commentaires existants juste avant de publier. Publiez chaque commentaire conservé épinglé à son nœud à x,y, exactement comme approuvé. Ne modifiez et ne supprimez jamais les commentaires d'autres personnes. Rapportez ce qui a été publié, ce qui a été sauté, et tout échec. Si le connecteur Figma ne peut pas publier de commentaires, dites-le et revenez à list.

6. Invite de correction (mode self)

Quand le travail a été réalisé avec Claude, terminez par une invite prête à coller pour la session qui l'a construit : les éléments bloquants et à corriger sous forme d'instructions numérotées et concrètes (quoi, où, valeur cible), plus "ne changez rien d'autre." Laissez de côté les broutilles sauf si demandé. Cela transforme la critique en prochaine itération au lieu d'une tâche de lecture.

7. Calibrer (optionnel, recommandé)

Après que la personne a agi sur la critique, faites un diff de ce qu'elle a conservé, coupé, réécrit et ajouté elle-même. Si un fichier de calibration est défini, ajoutez 2 à 5 lignes de motif courtes (par exemple "coupé : demander de supprimer du contenu optionnel", "ajouté : états de clavier levé manquants"). Ce fichier est la façon dont la compétence apprend les goûts d'une personne au fil du temps.