critique

Vue d’ensemble de la skill critique

Ce que fait la skill critique

La skill critique propose un workflow structuré de revue UX et design produit pour évaluer une page, une fonctionnalité ou un composant comme une véritable expérience utilisateur, et pas seulement comme une maquette visuelle. Elle pousse le modèle à examiner la hiérarchie visuelle, l’architecture de l’information, le ton émotionnel, la charge cognitive, les heuristiques d’utilisabilité et les frictions propres à certains personas, puis à transformer tout cela en retours actionnables.

À qui la skill critique convient

Cette skill critique est particulièrement adaptée aux product designers, ingénieurs frontend, fondateurs et builders IA qui disposent déjà d’un écran, d’un prototype ou d’une interface en production, et veulent une revue plus affûtée qu’un simple prompt du type « donne-moi ton avis sur cette UI ». Elle est particulièrement utile si vous cherchez une critique pour des travaux de UX Audit, pour une design QA avant lancement, ou pour obtenir un second avis sur une interface qui semble générique, confuse ou trop lourde.

Le vrai besoin auquel elle répond

La plupart des utilisateurs ne veulent pas seulement des opinions. Ils veulent savoir :

• ce qui dégrade l’expérience en priorité
• si l’UI paraît dérivative ou « générée par IA »
• quels problèmes sont cosmétiques et lesquels bloquent réellement la conversion
• comment prioriser les corrections sans équipe design complète

Cette skill a été pensée autour de ce besoin. Elle aborde la critique comme un outil d’aide à la décision, pas comme un simple commentaire de style.

Ce qui différencie cette critique

Son principal différenciateur, c’est son exigence de contexte et son étape de détection de « AI slop ». Au lieu de passer directement à des remarques de surface, elle attend d’abord un contexte design et vérifie explicitement si l’interface reprend des patterns courants des produits IA de 2024–2025 : grilles de cartes génériques, dark modes surchargés d’effets lumineux, hiérarchie faible, composition qui ressemble à un template.

Elle dépasse aussi le point de vue d’un seul reviewer en combinant :

• une critique de niveau design director
• une analyse de la charge cognitive
• un scoring heuristique
• des tests basés sur des personas

Point important avant adoption

critique n’est pas totalement autonome. Le repository impose frontend-design comme dépendance obligatoire pour les principes et la collecte de contexte, et précise qu’il faut lancer teach-impeccable d’abord si ce contexte design n’existe pas encore. Si vous cherchez une installation de critique sans préparation, cette chaîne de dépendances est le point principal à connaître avant de l’adopter.

Comment utiliser la skill critique

Installer le contexte avant de s’appuyer sur critique

Ce repository place critique dans .claude/skills/critique, et le texte de la skill dépend explicitement de /frontend-design. En pratique, l’usage de critique fonctionne mieux quand l’ensemble de skills impeccable est installé, plutôt que lorsqu’on traite ce dossier comme un simple fichier de prompt isolé.

Si votre runner de skills prend en charge l’installation depuis GitHub, installez-la depuis le repository puis vérifiez que critique, frontend-design et teach-impeccable sont tous disponibles.

Lisez d’abord ces fichiers

Pour décider rapidement si l’installation vaut le coup, lisez :

• SKILL.md
• reference/cognitive-load.md
• reference/heuristics-scoring.md
• reference/personas.md

Ce parcours vous donne presque tout l’essentiel : les prérequis, le workflow de revue, le modèle de scoring et l’angle retenu pour les tests utilisateurs.

Quels inputs la skill critique attend

La skill critique donne de bien meilleurs résultats si vous fournissez :

• l’artefact d’interface : capture d’écran, mockup, URL ou description de composant
• la zone à évaluer : page, flow, modal, dashboard, onboarding, settings, etc.
• l’objectif utilisateur principal
• le contexte produit et le public visé
• les contraintes : mobile/desktop, B2B/B2C, accessibilité, conversion, limites techniques

Sans ce contexte, le modèle peut toujours commenter la mise en page et l’esthétique, mais il ne peut pas juger si l’interface est réellement adaptée à la tâche.

Transformer une demande vague en prompt critique solide

Prompt faible :

• « Critique cette UI. »

Usage critique plus solide :

• « Use the critique skill on this onboarding flow. The product helps finance teams close books faster. Primary goal: get a first report generated in under 5 minutes. Audience: mid-market accounting teams. Constraint: desktop web app, dense data is acceptable but first-time clarity matters. Please evaluate AI-slop signals, hierarchy, cognitive load, heuristic score, and test it as a first-timer and power user. »

Cette version fonctionne mieux parce qu’elle donne à la skill un objectif à optimiser, au lieu de simplement lui demander de réagir.

Respecter la préparation exigée par le repository

La skill est explicite : il faut lancer /frontend-design d’abord et suivre son protocole de collecte de contexte. Si aucun contexte design n’existe, il faut exécuter /teach-impeccable avant critique. Autrement dit, le workflow prévu est le suivant :

1. collecter le contexte design
2. comprendre ce que l’interface cherche à accomplir
3. lancer critique par rapport à cet objectif
4. renvoyer un feedback priorisé

Si vous sautez l’étape 2, la sortie devient souvent générique, parce que le modèle ne peut pas distinguer une densité intentionnelle d’un mauvais design.

Utiliser critique pour des travaux de UX Audit

Pour des usages de critique orientés UX Audit, ne demandez pas seulement du « feedback ». Demandez :

• les principaux problèmes par niveau de gravité
• un résumé du scoring heuristique
• les points de décrochage utilisateur probables
• les modes d’échec propres à certains personas
• des recommandations de refonte concrètes

Cela fait passer le résultat d’un simple commentaire à un livrable de niveau audit, exploitable par des parties prenantes.

Ce que le workflow vérifie réellement

D’après le repository, la skill critique est particulièrement forte pour examiner :

• l’uniformisation typique des designs générés par IA
• les problèmes de hiérarchie visuelle
• la surcharge cognitive
• une architecture de l’information faible
• des patterns d’interaction peu clairs
• des lacunes sur les heuristiques d’utilisabilité
• un décalage entre le ton de l’interface et les besoins des utilisateurs

Elle est donc plus pertinente pour évaluer une UI réaliste ou déjà livrée que pour brainstormer des concepts greenfield.

Workflow d’usage recommandé pour critique

Workflow pratique :

1. récupérer l’écran et l’objectif
2. préciser le type d’utilisateur et les critères de réussite
3. invoquer critique sur une zone précise, pas sur tout le produit d’un coup
4. examiner d’abord les 3 problèmes les plus graves
5. demander des recommandations révisées après clarification des contraintes
6. répéter sur le flow suivant

Utiliser la skill critique page par page ou flow par flow donne généralement un meilleur signal qu’une demande de revue globale du produit en une seule passe.

Comment bien cadrer la demande

Périmètres adaptés :

• flow d’inscription
• page pricing
• dashboard analytics
• panneau de settings
• empty state
• checkout mobile

Périmètres peu adaptés :

• « toute l’app »
• « notre design system »
• « tout le site web »

La skill est assez détaillée pour qu’un périmètre trop large produise une sortie superficielle. Réduire la zone de revue améliore la précision et la priorisation.

Conseils pratiques pour améliorer la qualité des sorties

Pour un meilleur usage de critique, incluez :

• une phrase sur l’objectif business
• une phrase sur le niveau d’urgence côté utilisateur
• une phrase sur ce qui définit le succès
• toute contrainte connue que vous ne voulez pas voir le modèle « faire disparaître »

Exemple :

• « This page exists to get a team admin to invite coworkers immediately after signup. Speed matters more than education. We cannot remove required compliance messaging. »

Ce type d’input aide la skill à distinguer les vrais défauts d’une complexité nécessaire.

FAQ sur la skill critique

critique est-elle meilleure qu’un prompt UX classique ?

En général oui, si vous cherchez une méthode de revue reproductible. La valeur de la skill critique ne vient pas d’un goût magique en design ; elle vient de sa structure intégrée : contexte préalable, détection d’anti-patterns, scoring heuristique, cadrage par la charge cognitive et tests par personas. Un prompt classique peut produire des avis corrects, mais il sera moins cohérent et plus facile à faire dériver vers des compliments génériques.

critique est-elle adaptée aux débutants ?

Globalement oui, avec un point d’attention : la dépendance à frontend-design et parfois à teach-impeccable. Les débutants peuvent tout à fait utiliser critique, mais ils doivent s’attendre à passer quelques minutes à comprendre le workflow prévu, au lieu de lancer un unique prompt sans préparation.

Dans quels cas critique n’est-elle pas adaptée ?

Évitez cette skill critique si :

• vous avez davantage besoin de génération de code que de revue design
• vous n’avez qu’une idée produit vague, pas d’interface
• vous avez d’abord besoin de brand strategy ou de copywriting
• vous ne pouvez fournir aucun contexte utilisateur ou produit

Elle peut toujours commenter l’aspect visuel seul, mais ce n’est pas là que la skill se différencie le plus.

critique fonctionne-t-elle seulement sur des UI abouties ?

Non. Elle peut aussi être utile sur des wireframes, des maquettes sommaires et des composants précoces, notamment pour la hiérarchie et la charge cognitive. En revanche, les tests par personas et le scoring heuristique gagnent en crédibilité lorsque le modèle d’interaction est suffisamment visible pour être évalué.

Puis-je utiliser critique sur un seul composant ?

Oui, à condition que ce composant ait un vrai rôle dans son contexte. Un panneau de filtres, une modal, un tableau ou un formulaire peuvent tous bénéficier d’un usage de critique. Expliquez simplement où il apparaît, qui l’utilise et ce que cette personne cherche à accomplir.

Que faut-il attendre en sortie ?

Une bonne sortie de critique devrait fournir :

• les principaux risques UX
• leur gravité ou leur niveau de priorité
• les raisons précises pour lesquelles ces problèmes comptent
• des exemples concrets de modifications à apporter
• une distinction claire entre polish superficiel et problèmes structurels d’UX

Si le résultat se limite surtout à des adjectifs, c’est probablement que le prompt manquait de contexte.

Comment améliorer la skill critique

Donner à critique un indicateur de réussite, pas seulement un écran

Le moyen le plus rapide d’améliorer les sorties de critique est d’indiquer le résultat utilisateur visé. « Review this dashboard » est moins utile que « Review this dashboard for whether a new manager can spot blockers in under 30 seconds. » Les indicateurs de réussite affinent tous les jugements qui suivent.

Fournir le public visé et la maturité du produit

Une même interface peut être :

• pertinente pour des utilisateurs experts dans un outil B2B dense
• inadaptée à des consommateurs qui découvrent le produit
• acceptable dans un outil interne
• trop faible pour un produit premium orienté client

Si vous précisez le public et le niveau de maturité du produit, la skill critique peut juger les arbitrages au lieu de retomber sur des conseils UX trop génériques.

Demander explicitement la sélection des personas

Le repository inclut plusieurs personas, mais tous ne sont pas pertinents à chaque fois. Pour améliorer critique dans des tâches de UX Audit, indiquez quels types d’utilisateurs comptent le plus, par exemple :

• first-timer
• power user
• cautious admin

Cela évite que la sortie disperse son attention sur des modes d’échec peu utiles.

Forcer une priorisation après la première passe

Un mode d’échec fréquent consiste à obtenir une longue liste d’observations sans vraie valeur décisionnelle. Après la première critique, demandez :

• « Which 3 issues most threaten task completion? »
• « Which issue is most likely to reduce trust? »
• « What should be fixed before launch versus later? »

Cela transforme l’analyse en plan d’action.

Fournir les contraintes que le modèle doit respecter

Si l’interface doit rester :

• dense en données
• d’apparence enterprise
• conforme
• alignée à la marque
• mobile-first
• avec un faible effort d’ingénierie

dites-le clairement. Sinon, critique risque de proposer des refontes plus propres sur le papier, mais irréalistes.

Surveiller les sur-corrections liées au « AI slop »

L’un des points forts de cette skill critique est de détecter les patterns génériques produits par l’IA. Mais il ne faut pas sur-réagir et supprimer toute convention moderne juste pour paraître original. La meilleure question n’est pas de savoir si le design est simplement différent, mais s’il est distinctif et approprié. Utilisez cette section pour repérer une uniformité paresseuse, puis validez les corrections au regard de l’utilisabilité.

Améliorer les inputs avec des itérations avant/après

Bonne pratique :

1. lancer critique sur le design actuel
2. appliquer ou simuler 2 à 3 changements majeurs
3. relancer critique sur la version révisée
4. comparer si les principaux risques ont réellement diminué

La skill devient beaucoup plus utile lorsqu’elle s’inscrit dans une boucle de design itérative plutôt que comme verdict unique.

Raisons fréquentes pour lesquelles la sortie de critique paraît faible

En général, il manque l’un de ces éléments :

• aucun objectif utilisateur
• aucun contexte produit
• un périmètre trop large
• aucune contrainte
• un artefact pas assez exploitable pour être inspecté
• une demande de simples « thoughts » au lieu d’une structure de revue définie

Quand ces points sont corrigés, le guide critique devient nettement plus actionnable.

Un modèle de prompt solide pour un meilleur usage de critique

Utilisez un prompt de ce type :

• « Use the critique skill on [area].
• Product: [what the product does]
• Audience: [who this is for]
• Primary task: [what the user needs to do]
• Success metric: [what success looks like]
• Constraints: [platform, compliance, technical, brand]
• Review for: AI-slop signals, hierarchy, cognitive load, heuristics, and 2 relevant personas.
• Output: top issues, severity, why they matter, and concrete fixes.”

Ce modèle correspond de près à la manière dont le repository attend que critique soit utilisée, et produit en général un signal plus utile qu’une demande ouverte.