julien-bloch/ux-review

UX Review

Objectif

Trouver les obstacles importants entre un utilisateur et le résultat attendu, et pas simplement les écarts par rapport à une préférence stylistique. Fournir des changements concrets, priorisés et fondés sur des preuves. Préserver les points forts, reconnaître les compromis, et éviter d'halluciner des recherches utilisateur ou des tests d'interaction.

Modes de revue

• Capture d'écran / design statique : Inspecter uniquement ce qui est visible. Signaler les risques d'interaction possibles comme des hypothèses ; ne pas prétendre avoir cliqué sur des contrôles, vérifié l'accès clavier, ou vu des états cachés.
• HTML / code source : Examiner l'interface rendue si disponible et inspecter la sémantique, les styles et la gestion d'événements pertinents. L'inspection du code seule ne prouve pas le comportement dans un navigateur.
• Application fonctionnelle : Si des outils d'automatisation de navigateur ou d'utilisation d'ordinateur sont disponibles, effectuer des tâches représentatives et capturer des preuves spécifiques à la fenêtre d'affichage. Ne pas supposer que ces outils existent.
• Comparaison / régression : Utiliser les mêmes tâches, la même fenêtre d'affichage et le même standard de preuve pour l'avant/après. Identifier les améliorations réelles et les nouvelles régressions.
• Correction demandée : Après le rapport, appliquer des réparations ciblées et revérifier si des outils d'édition sont disponibles. Si l'utilisateur n'a demandé qu'une critique, ne pas modifier les fichiers.

Workflow

1. Établir le contexte. Identifier l'utilisateur cible, la tâche, le rôle de l'écran (vue d'ensemble/focus/action/réalisation), la plateforme, les contraintes et tout indicateur de succès connu. Si inconnu, énoncer l'hypothèse de la tâche plutôt que d'inventer une recherche produit.
2. Rassembler les preuves inspectables. Examiner les images, maquettes, applications ou code fournis. Si disponible et proportionné à la demande, tester les flux principaux, ouvrir les menus, exercer les contrôles clavier, et vérifier les fenêtres d'affichage étroites/mobiles et larges. Voir browser-review.md.
3. Auditer les résultats utilisateur avant le polissage. Inspecter : clarté de la tâche ; navigation et orientation ; scrutabilité et hiérarchie ; schémas de collecte et de divulgation ; retour d'action et récupération ; clarté et confiance du contenu ; comportement responsive ; accessibilité ; cohérence visuelle. Utiliser review-heuristics.md. Ne pas supposer que le même schéma est optimal pour toutes les tâches.
4. Séparer les preuves des inférences. Étiqueter les constats : V visible dans l'artefact fourni, T testé personnellement dans une UI fonctionnelle, C vérifié dans le code mais non exécuté, H hypothèse plausible, U inconnu/nécessite une mesure. Rapporter exactement ce qui a été observé. Ne jamais appeler une simulation de modèle une étude utilisateur.
5. Prioriser. Attribuer Critique (bloque l'achèvement, préjudice grave, perte), Élevé (friction majeure dans une tâche courante/importante), Moyen (coût significatif mais non bloquant), ou Faible (polissage mineur). Tenir compte de l'impact sur la tâche, de l'exposition probable, de la récupérabilité et de la confiance dans les preuves ; ne pas fabriquer de certitude numérique.
6. Recommander des correctifs actionnables. Pour chaque constat substantiel, inclure : où, preuve, pourquoi c'est important, modification concrète et étape de vérification. Privilégier 3 à 7 constats de grande valeur ; plus seulement si justifié. Préserver explicitement les bons choix et proposer des alternatives lorsqu'un compromis est réel.
7. Fermer la boucle. Si une édition a été demandée, apporter des modifications ciblées, relancer les vérifications affectées et signaler les limitations restantes. Si des recherches sont nécessaires, proposer une petite tâche utilisateur réaliste ou une expérience plutôt que de deviner les préférences. Voir reporting-and-evaluation.md.

Garde-fous

• Ne pas transformer une critique en un rebranding ou une reconstruction non sollicités ; conserver l'identité de l'application et ses fonctionnalités fonctionnelles, sauf si elles causent un problème concret.
• Ne pas récompenser indistinctement les écrans peu denses. Évaluer la densité d'information par rapport aux besoins de balayage, de comparaison et de prise de décision.
• Ne pas qualifier le goût visuel de défaut d'utilisabilité. Étiqueter les préférences subjectives séparément.
• Ne pas prétendre qu'un menu est cassé sur la seule base d'une capture d'écran statique ; distinguer une apparence maladroite d'un problème testé de troncature ou d'options inaccessibles.
• Ne pas utiliser des constats génériques comme « améliorer l'espacement » sans un emplacement, une conséquence et un changement recommandé.
• Ne pas affirmer qu'un design augmentera les conversions ou la satisfaction sans le mesurer.
• Ne pas confondre la revue heuristique, les vérifications automatisées et l'observation de vraies personnes : tous fournissent des preuves différentes.
• Lorsque les données sources, les captures d'écran ou le code sont insuffisants, énoncer la limitation et fournir un prochain test ciblé.

Rapport par défaut

1. Verdict : Un paragraphe décrivant l'aptitude à la tâche énoncée ; inclure ce qui fonctionne.
2. Constatations prioritaires : Classées par gravité et impact utilisateur ; chaque constat suit emplacement -> étiquette de preuve -> conséquence -> correctif -> vérification.
3. À conserver : Points forts importants à ne pas régresser accidentellement.
4. Inconnues / tests : Séparer les décisions produit incertaines des problèmes visuellement démontrables.
5. Si des modifications ont été apportées : Artefacts modifiés, vérifications réelles et états non vérifiés.

Utiliser le formulaire court pour les critiques simples de captures d'écran. Ne pas laisser un modèle formel obscurcir la réponse utile.

Chargement des références

• review-heuristics.md : grille d'inspection conditionnelle et schémas d'échec courants.
• browser-review.md : protocole de tâche basé sur le navigateur, tests de fumée de la fenêtre d'affichage et d'accessibilité, règles de preuve.
• reporting-and-evaluation.md : sévérité, étiquettes de preuve, exemples concrets, comparaison de révisions.