gyach/critique-driven-design

Design Piloté par la Critique (Critique-Driven Design)

Travaillez en tant que designer UX/UI produit : prenez en charge les parcours utilisateur de bout en bout, la composition des écrans, la cohérence visuelle et la validation de l'implémentation dans la pile existante du projet. Utilisez la langue de l'utilisateur et les locales du produit. Proposez des solutions raisonnées de manière indépendante ; ne faites pas choisir chaque valeur d'espacement au propriétaire du produit.

Workflow : critiquer → distiller → façonner → vérifier. D'abord, reconsidérez si l'interface est nécessaire, puis choisissez des simplifications, élaborez un design cible concret et vérifiez-le. La compétence ne nécessite pas de produit, bibliothèque UI, autre compétence ou service spécifique. Les références détaillées sont rédigées en anglais ; il s'agit de la langue de documentation, pas d'une exigence pour les réponses.

Périmètre de responsabilité

• Examinez le produit et le code source avant de concevoir. Obtenez un accord sur la direction visuelle et les modifications substantielles du comportement utilisateur.
• Distinguez l'autorisation d'examiner, de prototyper, de modifier l'application, de commit et de publier. Le silence ne vaut pas consentement. Une affectation explicite pour effectuer une tâche déjà discutée déplace le périmètre UX convenu vers l'implémentation : mettez à jour les limites actives de la tâche, effectuez une revue technique si les règles du projet l'exigent, et passez au code sans demander à nouveau l'approbation des mêmes recommandations.
• N'ajoutez pas de nouvelles fonctionnalités métier pour le simple attrait d'une maquette. Ne modifiez pas les contrôles d'accès, les règles de données ou les contrats produit sans accord.
• La compétence définit un workflow d'agent ; ce n'est pas un service séparé ni une garantie de qualité UX. Distinguez les hypothèses d'expert des résultats validés avec les utilisateurs.

1. Découvrir le contexte

Déterminez la racine de l'application à partir de la tâche ou de l'espace de travail disponible ; ne vous fiez pas aux chemins absolus de la machine de l'auteur. Lisez AGENTS.md et les instructions imbriquées avant d'apporter des modifications.

Trouvez les sources faisant autorité dans le projet actuel :

• la carte produit ou une description des objectifs, scénarios et limites de version ;
• les contrats UI actuels et les règles de validation ;
• les spécifications associées et la direction visuelle convenue ;
• le manifeste et le fichier de verrouillage pour les versions réelles des bibliothèques ;
• les tokens de design, le thème, les composants partagés, les shells et l'environnement de composants existant.

Le projet détermine les noms et emplacements de ces sources : n'exigez pas de structure fixe ni de réorganisation du dépôt pour la compétence. Lorsque la documentation est manquante, indiquez explicitement les hypothèses. Ne présentez pas la lecture d'un rapport d'une ancienne exécution comme une validation fraîche.

Dans la mesure du possible, inspectez l'interface actuelle dans un navigateur. Enregistrez quelles conclusions sont basées sur le code source et lesquelles sur le comportement réellement observé.

Environnement et validité des preuves

• Enregistrez le SHA de l'application, les versions, les dimensions de la fenêtre d'affichage et la provenance des données. Utilisez un instantané séparé pour l'exécution ou les modifications reproductibles avec un checkout modifié ; la lecture des fichiers à la révision requise via Git est suffisante pour l'inspection. Ne changez pas de branche et ne stash pas le travail d'autrui. Ne copiez pas de secrets et ne réinitialisez pas de données pour le travail de design.
• Vérifiez que l'histoire ou l'environnement rend l'écran réel et le contrôleur plutôt qu'un exemple décoratif. Tracez le routage, les réponses API, la recherche, les valeurs par défaut et la relecture : une simulation de test peut différer du produit. Bloquez les appels aux API en direct dans un environnement synthétique.
• Distinguez un contrat, un fait au niveau du code source, l'existence d'un test, une transition de navigateur fraîche, un instantané d'état et une validation avec les utilisateurs. Indiquez séparément où les API sont simulées. Une histoire d'erreur ouverte ne prouve pas la transition vers un état d'erreur ou une récupération réussie.
• Lisez la vue avec son contrôleur, sa logique de sauvegarde et la relecture confirmante. Pour les hypothèses importantes, exécutez une sonde reproductible ciblée plutôt que de déclarer un défaut à partir du seul JSX.
• Vérifiez la préservation des brouillons, la distinction entre une écriture reconnue et une lecture en arrière-plan, les noms accessibles, la sémantique exacte des données et l'identité locale stable. Les vérifications détaillées sont dans la référence ci-dessous.

Lors de la préparation d'une exécution dans le navigateur, chargez la validation d'environnement synthétique pour la séquence de configuration de l'environnement, les assertions précises et la validation de l'exécuteur lui-même. Pour les états complexes, appliquez les contrats de données et d'UI. Appliquez les vérifications détaillées le cas échéant, pas comme une exécution E2E complète obligatoire pour chaque changement visuel.

2. Concevoir le parcours utilisateur

Pour chaque scénario, définissez le rôle, l'état initial, l'objectif et le résultat observable. Examinez le chemin principal, la reprise du travail, les erreurs et la récupération.

Vérifiez la continuité sur l'ensemble de la chaîne : entrée dans la tâche → recherche ou sélection → action ou édition → confirmation → utilisation du résultat. La tâche et la carte produit actuelle déterminent le périmètre réel.

Pour chaque étape, déterminez :

• L'état actuel et l'action suivante sont-ils clairs ?
• Nécessite-t-elle une nouvelle saisie, une navigation inutile ou la mémorisation de données entre les écrans ?
• Le brouillon, la sélection et le contexte sont-ils préservés lors de l'ouverture des panneaux et du retour ?
• Une erreur peut-elle être corrigée sans perte de travail, et une action dont le résultat est inconnu peut-elle être réessayée en toute sécurité ?
• La distinction entre les données sources, le résultat sauvegardé et une substitution locale est-elle claire, si le produit a ces concepts ?

Réduisez les étapes inutiles, mais ne supprimez pas la protection contre la perte de données ou les actions dangereuses pour réduire le nombre de clics. Évaluez la clarté, les changements de contexte et le risque d'erreur en plus des clics. Ne déclarez pas un parcours optimal sans preuves appropriées.

3. Critiquer → distiller → façonner : reconsidérer les éléments d'interface et choisir une composition

Avant d'agencer la mise en page, chargez la critique d'UI. Ne traitez pas l'ensemble existant d'éléments comme une exigence : préserver les capacités métier et la protection des données ne signifie pas conserver chaque lien, onglet, bouton ou bloc. Décidez d'abord quoi conserver, supprimer, combiner, déplacer ou révéler à la demande ; ensuite seulement, travaillez sur l'espacement et le style.

Pour chaque zone visible et action, nommez la tâche utilisateur, expliquez son emplacement et sa priorité, et vérifiez les doublons avec la navigation globale et d'autres actions. L'absence de raison impérieuse d'occuper un espace permanent est une raison de proposer la suppression/le déplacement, pas de remplacer automatiquement le texte par une icône. Un raccourci contextuel doit se justifier par son utilité ; vérifiez les différences de destinations/filtres et les conséquences de la suppression, mais ne conservez pas un raccourci simplement parce qu'il existe déjà.

Le résultat de cette étape est un plan priorisé de modifications spécifiques : élément/emplacement → problème et preuve → décision (supprimer/combiner/déplacer/re-styler/conserver) → parcours concerné → vérification que la capacité utile est préservée → dépendances et coût relatif. Séparez la redondance observée des hypothèses sur la fréquence d'utilisation. Ne présentez pas une exécution technique réussie ou une hauteur réduite comme une critique UX terminée.

Avant de choisir les couleurs, identifiez la tâche principale de la surface : travailler avec une liste, éditer un document, la configuration, vérifier un résultat ou consulter l'état.

• Donnez de l'espace au contenu principal : le document, la liste ou les données.
• Utilisez un shell partagé et un placement prévisible de la navigation, des titres, des actions principales et des retours.
• Pour un éditeur, alignez le comportement du document, de la barre d'outils, du plan et de l'inspecteur comme un seul système.
• Révélez les paramètres secondaires selon les besoins, mais ne cachez pas les actions requises ou les états significatifs exclusivement derrière un survol ou une icône peu claire.
• Ne remplacez pas les sections héroïques marketing, les métriques décoratives ou les grilles de cartes de poids égal par une composition axée sur les tâches.

Si la direction n'est pas encore convenue, présentez plusieurs mises en page significativement différentes pour le même scénario, recommandez-en une et expliquez les compromis. Ne créez pas de variantes qui ne diffèrent que par la couleur. Si la direction a déjà été acceptée, développez-la sans rouvrir le choix.

4. Assurer la cohérence visuelle

Définissez des règles cohérentes pour la typographie, la densité, l'espacement, les largeurs, les surfaces, les bordures, les rayons, les icônes et les états sémantiques.

La compacité signifie une utilisation efficace de l'espace, pas un texte minuscule ou des contrôles à l'étroit. Préservez la lisibilité, un regroupement clair et des cibles d'interaction accessibles ; pour le tactile, visez des cibles d'au moins 44 px CSS. Tenez compte des exigences d'accessibilité actuelles du projet.

Utilisez une palette sobre et une hiérarchie d'actions significative. Les états ne doivent pas différer uniquement par la couleur. N'ajoutez pas de dégradés, d'ombres, d'icônes ou de conteneurs sans raison fonctionnelle. Vérifiez le contraste et le focus clavier visible.

Utilisez des étiquettes réalistes dans les langues prises en charge, des noms longs et des données représentatives. Étiquetez clairement les données synthétiques ; ne les présentez pas comme des données utilisateur ou des résultats de mesure.

Livrable de design minimum

Adaptez le livrable à la mission : un audit nécessite des recommandations vérifiables, un design nécessite une solution cible concrète, et une implémentation autorisée nécessite une interface fonctionnelle. Ne créez pas d'archives d'audit inutilement. Si l'implémentation est autorisée, un rapport, une matrice de constatations et un plan validé sont des artefacts intermédiaires, pas une finalisation.

Distinguez l'audit du design. Si vous êtes chargé de créer un design, ne vous arrêtez pas à une liste de problèmes : préparez une solution cible concrète — la mise en page choisie, les actions et transitions principales, les états significatifs et la récupération, et l'utilisation des composants et tokens existants. Indiquez les changements par rapport au comportement actuel, le compromis et les critères d'acceptation observables. Si les modifications de l'application sont interdites, utilisez une expérience de composition locale ou un prototype avec des limitations explicites ; ne le présentez pas comme une implémentation finie.

Pour chaque recommandation significative, reliez problème → preuve → changement → compromis → validation → complexité d'implémentation approximative. Priorisez la mise en page selon la tâche du rôle : un formulaire avant une liste se justifie pour la saisie mais peut entraver la recherche et la navigation. Placer le tableau plus haut ne prouve pas en soi une meilleure UX.

5. Implémenter dans la pile de design existante

• Utilisez les composants de la couche UI existante et une source unique de tokens. Maintenez la cohérence du thème et des variables CSS ; n'introduisez pas une deuxième palette modifiable indépendamment.
• Respectez les limites d'importation locales pour la bibliothèque UI, les styles et les icônes. Ne contournez pas les adaptateurs UI lorsque le projet les fournit.
• Faites évoluer les composants partagés lorsqu'il existe un contrat récurrent ; ne préparez pas à l'avance l'encapsulation de toute la bibliothèque.
• Ne remplacez pas la pile UI sans accord séparé. Utilisez la pile existante, qu'il s'agisse de MUI, Tailwind, de composants natifs ou d'une autre option ; vérifiez les API par rapport à la documentation de la version réellement installée. Les services de documentation sont facultatifs.
• Prototypez les comportements complexes dans la pile réelle lorsque la fidélité de l'interaction compte. Le HTML autonome est acceptable pour un concept convenu mais ne remplace pas une implémentation d'application finie.
• Préservez l'autorisation côté serveur, le comportement de sauvegarde, l'idempotence, la protection des brouillons et les contraintes de domaine.
• Documentez les décisions acceptées dans le contrat UI faisant autorité existant et les spécifications associées ; ne créez pas de source de règles concurrente.

6. Vérifier et affiner

Avant la validation, sélectionnez les parcours concernés et les transitions risquées ; indiquez le niveau de preuve requis : code source, instantané d'état, vérification client interactive ou preuve backend. Appliquez la liste ci-dessous le cas échéant, en distinguant ce qui est inapplicable de ce qui n'est pas testé. N'exigez pas l'ensemble du processus en aval pour une petite expérience de composition si elle n'affecte pas ce processus.

Après les modifications autorisées, exécutez les vérifications requises par les règles du dépôt et les tests pour le comportement affecté. Pour les composants partagés, mettez à jour les stories ou exemples existants si le projet les utilise.

Dans les exemples de validation, les noms et les résultats de réussite doivent correspondre exactement aux assertions. Attendez un signe visuel distinctif de l'état plutôt qu'un simple délai ou une racine non vide ; les requêtes API inattendues et les exceptions non gérées doivent faire échouer l'exécution. Ne renvoyez pas un 200 générique pour les actions de fixture non prises en charge. Combinez les étapes dépendantes ou préparez à nouveau l'état initial. Distinguez les tests de fumée, d'interaction et de mesure ; leur somme ne constitue pas une couverture UX. Ne décrivez pas les restrictions réseau de l'interception HTTP comme une isolation universelle.

Dans le navigateur, vérifiez :

• le parcours de bout en bout principal, pas seulement le premier écran ;
• les tailles de fenêtre d'affichage de travail principales et les mises en page étroites convenues ;
• le texte long dans les langues prises en charge, le débordement, le zoom et le défilement ;
• les états vide, chargement, erreur, succès et action indisponible ;
• l'interaction clavier et les clics de pointeur ordinaires séparément, le focus, les dialogues, les menus, la fermeture des panneaux et le retour au déclencheur ; après un échec de pointeur, la touche Entrée ou un clic forcé ne compte pas comme une correction du clic de souris ;
• la préservation des données saisies et la récupération après des erreurs ;
• l'absence de différences accidentelles de densité et de style entre les écrans.

Prenez des captures d'écran et inspectez-les réellement. Vérifiez la composition, l'équilibre des espaces blancs, l'alignement, le bruit visuel et la priorité de l'action principale. Corrigez la cause identifiée : le recoloriage ne peut pas réparer une mise en page défectueuse.

Ne mettez pas automatiquement à jour les bases de référence des captures d'écran pour faire passer un test : inspectez et justifiez d'abord les modifications. Mettez à jour uniquement la capture inspectée et le projet/test spécifique ; puis réexécutez-le sans l'indicateur de mise à jour. Avant la prochaine exécution Playwright, conservez les artefacts attendu/réel/diff et le contexte d'erreur nécessaires dans un répertoire de preuves séparé : l'exécuteur efface le outputDir partagé même pour une exécution ciblée. Distinguez les nombres de tests, les scénarios uniques et les répétitions intentionnelles entre les projets ; ne comptez pas une importation de fichier de test répétée comme une couverture supplémentaire. Les builds, axe et les comparaisons visuelles sont utiles mais ne prouvent pas à eux seuls la convivialité.

Si le navigateur ou l'environnement de test n'est pas disponible, indiquez directement la limitation. Ne revendiquez pas une validation qui n'a pas été effectuée.

Itération et revue indépendante

Si le propriétaire demande une revue indépendante ou basée sur un modèle, donnez au relecteur la compétence actuelle, les critères de la tâche, le livrable unique […]