Claude pour le
Design UX.

Tu es un UX researcher senior avec 15 ans d'expérience. Je vais te coller [X] transcriptions d'entretiens utilisateurs pour [produit/contexte]. Analyse-les et produis : 1. TOP 5 DES PAIN POINTS RÉCURRENTS — classés par fréquence. Pour chacun : cite verbatim au moins 2 participants, sévérité (1-5), et quel segment d'utilisateurs est le plus touche. 2. PATTERNS COMPORTEMENTAUX — regroupe les utilisateurs par comportement, pas par données démographiques. Nomme chaque pattern. Décris le déclencheur, l'action et le résultat attendu. 3. BESOINS NON SATISFAITS — ce que les utilisateurs veulent mais n'ont pas explicitement demandé. Lis entre les lignes. 4. OPPORTUNITÉS — améliorations produit concrètes classées par impact vs effort. 5. DÉCOUVERTES SURPRENANTES — tout ce qui contredit nos hypothèses. Format : markdown structuré. Pas de blabla. Chaque insight doit être appuyé par une citation directe.

A partir des résultats de recherche suivants, crée 3 personas comportementaux. Chaque persona doit inclure : - Prenom (réaliste, pas "Marie la Marketeuse") - Role + contexte (pas juste un intitulé de poste) - Objectif principal (ce qu'il/elle cherche à accomplir) - Frustration cle (le problème n°1 qui le/la bloque) - Pattern comportemental (comment il/elle résout le problème actuellement) - Citation (verbatim réaliste issu de la recherche) - Aisance tech (1-5) - Style de décision : impulsif / méthodique / délégateur - Ce qui le/la ferait adopter notre produit - Ce qui le/la ferait partir NE CRÉE PAS de personas aspirationnels. Ils doivent refléter des comportements RÉELS observés dans les données de recherche ci-dessous : [colle tes résultats de recherche]

A partir des données de recherche ci-dessous, extrais des Jobs-to-be-Done en utilisant exactement ce format : "Quand [situation], je veux [motivation], pour pouvoir [résultat attendu]." Règles : - Minimum 8 énoncés JTBD - Regroupe-les par : jobs fonctionnels, jobs emotionnels, jobs sociaux - Chacun doit être lie à une vraie citation des données - Classe par fréquence (combien de participants ont exprime ce besoin) - Identifie les 3 premiers comme "jobs principaux" — ceux qui orientent les décisions produit Données de recherche : [colle tes transcriptions ou notes]

J'ai besoin de valider ces résultats qualitatifs avec un sondage quantitatif : [colle tes résultats] Génère 15 questions de sondage qui : - Utilisent un langage neutre, sans orientation - Melangent les types : echelle de Likert (5 points), choix multiples, classement, questions ouvertes (2 max) - Testent chaque résultat sans reveler notre hypothèse - Incluent 1 question de filtrage et 1 question d'attention - Maintiennent un temps de complétion sous 4 minutes - Sont ordonnées du facile/large au spécifique/sensible Pour chaque question, note entre parentheses quel résultat elle valide.

Crée un script de test d'utilisabilité modere pour [produit/fonctionnalité]. Contexte : [décris ce que tu testés et pourquoi] Le script doit inclure : 1. INTRO (2 min) — consentement, notice d'enregistrement, instruction "pense à voix haute" 2. ÉCHAUFFEMENT (3 min) — 2-3 questions de contexte sûr leur comportement actuel 3. TACHES (20 min) — 4-5 tâches réalistes, ordonnées par complexite - Chaque tâche : scénario (pas des instructions), critères de succes, limite de temps - Questions de relance pour chaque tâche (quoi demander s'ils galerent / s'ils reussissent) 4. POST-TÂCHE (5 min) — évaluation SUS ou SEQ + questions ouvertes 5. DEBRIEFING (5 min) — impression generale, comparaison avec les alternatives, autre chose à ajouter Total : 35 minutes. Ton : conversationnel, pas clinique.

J'ai des notes de recherche brutes de [X] sessions. Organise-les en diagramme d'affinité. Règles : - Crée 5-8 thèmes de niveau supérieur - Chaque thème a 3-6 sous-clusters - Chaque sous-cluster contient les notes regroupées logiquement - Nomme les thèmes avec des labels orientés action (pas juste "Navigation" — dis "Les utilisateurs perdent le contexte pendant la navigation") - Identifie les thèmes qui apparaissent dans 3+ sessions comme "signaux forts" - Identifie les thèmes d'une seule session comme "signaux faibles — à valider" Notes brutes : [colle toutes tes notes]

Je démarre une phase de discovery pour [type de projet] chez [type d'entreprise]. Je dois interviewer ces stakeholders : - CEO / Fondateur - Head of Product - Head of Engineering - Head of Sales/Marketing Pour chacun, génère 6 questions qui : - Revelent leur definition du succes pour ce projet - Font émerger les contraintes cachees (budget, délais, politique interne) - Exposent les désaccords entre stakeholders - Identifient les vrais KPIs (pas les vanity metrics) - Comprennent leur perception de l'utilisateur final Ton : d'égal a égal, pas de consultant a client. Pas de jargon.

Crée une cartographie du parcours utilisateur pour [persona] qui essaie de [objectif] en utilisant [produit]. Pour chaque étape (Découverte → Considération → Onboarding → Première valeur → Rétention → Recommandation) : - Action utilisateur : ce qu'il/elle fait concrètement - Point de contact : où se passe l'interaction (site web, app, email, humain) - Pensée : ce qui lui traverse l'esprit - Émotion : frustre / neutre / ravi (et pourquoi) - Pain point : ce qui est casse à cette étape - Opportunité : ce qu'on pourrait améliorer Format en tableau. Identifie les 3 plus gros risques d'abandon avec "CRITIQUE".

On est sur le point de designer [fonctionnalité/produit]. Avant de commencer, cartographie nos hypothèses. Pour le contexte projet ci-dessous, liste : 1. FAITS ÉTABLIS — choses dont on a les preuves 2. HYPOTHÈSES — choses qu'on croit vraies mais qu'on n'a pas validées 3. INCONNUES — choses sûr lesquelles on n'a même pas d'hypothèse Pour chaque hypothèse, évalue : - Risque si fausse (1-5) : c'est grave à quel point si cette hypothèse est fausse ? - Confiance (1-5) : on est surs à quel point ? - Méthode de validation : comment tester ça rapidement et à moindre coût ? Trie par : risque le plus élevé + confiance la plus basse = à tester en premier. Contexte projet : [décris le projet]

Résume les résultats de recherche suivants en un résumé exécutif d'une page pour des décideurs C-level qui ont 2 minutes pour lire. Structure : 1. UNE PHRASE : le résultat le plus important 2. TROIS BULLETS : les insights cles qui orientent les décisions 3. LE RISQUE : ce qui se passe si on ignore cette recherche 4. L'OPPORTUNITE : impact business estimé si on agit 5. PROCHAINE ETAPE RECOMMANDEE : une action concrète Règles : pas de jargon, pas de mots prudents ("pourrait", "éventuellement", "potentiellement"). Sois direct. Utilise des chiffres. Écris comme un CFO lit — le résultat final d'abord. Résultats complets : [colle le rapport]

Je vais te décrire les écrans/flux principaux de [produit concurrent]. Analyse-les en tant que product designer senior. Pour chaque écran : - Ce qui fonctionne bien (et pourquoi, du point de vue des principes UX) - Ce qui est casse ou confus - Ce qui manque et dont les utilisateurs ont probablement besoin - Une chose qu'on devrait reprendre (ethiquement) - Une chose qu'on devrait faire différemment A la fin, fournis : - Leur stratégie UX apparente en 1 phrase - 3 faiblesses qu'on peut exploiter dans notre produit - Leur différenciateur le plus fort qu'on doit egaler ou depasser Écrans : [décris ou colle les descriptions de captures d'écran]

Je démarre un nouveau projet sûr [sujet]. Fouille dans les résultats de recherche passés suivants et fais remonter tout ce qui est pertinent. Pour chaque résultat pertinent : - Le projet d'origine - L'insight spécifique - Comment il s'applique au projet actuel - Niveau de confiance (c'etait basé sur 5 utilisateurs ou 500 ?) - S'il a besoin d'être revalide (si plus vieux que 6 mois) Recherches passées : [colle ton repository de recherche / notes] Contexte du projet actuel : [décris le nouveau projet]

Documente le composant suivant du design system pour les développeurs et les designers : Composant : [nom, ex. "Button"] Variantes : [liste des variantes] Props/paramètres : [liste] Génère une documentation avec : 1. DESCRIPTION — ce que c'est et quand l'utiliser (2 phrases) 2. ANATOMIE — identifié chaque partie du composant 3. VARIANTES — quand utiliser chaque variante (format tableau) 4. ÉTATS — default, hover, active, focus, disabled, loading 5. DIMENSIONS — dimensions, padding, spacing pour chaque taille 6. À FAIRE / À NE PAS FAIRE — 3 à faire et 3 a ne pas faire avec des exemples précis 7. ACCESSIBILITE — rôles ARIA, comportement clavier, gestion du focus 8. EXTRAIT DE CODE — exemple React/HTML pour chaque variante 9. COMPOSANTS LIES — quoi utiliser à la place dans les cas limites Ton : concis, scannable. Écris pour un développeur le lundi a 9h.

Documente les design tokens suivants pour notre design system : [colle ta liste de tokens — couleurs, espacement, typographie, etc.] Pour chaque catégorie de tokens, génère : 1. TABLEAU DES TOKENS — nom, valeur, variable CSS, contexte d'utilisation 2. EXPLICATION DU NOMMAGE SEMANTIQUE — pourquoi ce nom et pas un autre 3. RÈGLES D'UTILISATION — quand utiliser chaque token (avec exemples) 4. ANTI-PATTERNS — erreurs courantes à éviter 5. NOTES D'ACCESSIBILITE — ratios de contraste pour les paires de couleurs, tailles minimales Ajoute une fiche "référence rapide" en haut pour les développeurs qui veulent juste les valeurs.

Documente le pattern UX suivant pour notre pattern library : Pattern : [ex. "État vide", "Flux d'onboarding", "Gestion des erreurs", "Filtrage de tableau de données"] Inclus : 1. PROBLEME RESOLU — le besoin utilisateur que ce pattern adresse 2. QUAND L'UTILISER — scénarios précis (liste 3-5) 3. QUAND NE PAS L'UTILISER — quoi utiliser à la place 4. ANATOMIE — description schematique de la structure du pattern 5. COMPORTEMENT — flux d'interaction étape par étape 6. GUIDELINES DE CONTENU — quel texte inclure, ton, longueur 7. RESPONSIVE — comment il s'adapte sur mobile vs desktop 8. EXEMPLES — 2 bonnes implementations, 1 mauvaise implementation (et pourquoi) 9. METRIQUES — comment mesurer si ce pattern fonctionne

On met à jour [composant] de la v1 à la v2. Génère un guide de migration. v1 : [décris la version actuelle] v2 : [décris la nouvelle version] Inclus : 1. CE QUI A CHANGE — résumé visuel des differences 2. POURQUOI — la logique design derrière chaque changement 3. BREAKING CHANGES — ce qui cassera si les équipes ne mettent pas à jour 4. ÉTAPES DE MIGRATION — étapes exactes, avec code avant/apres 5. CALENDRIER — déploiement progressif recommande 6. FAQ — anticipe 5 questions que les équipes vont poser

Rédige des guidelines de contribution pour notre design system. On a [X] designers répartis sûr [Y] équipes produit. Inclus : 1. QUAND proposer un nouveau composant vs utiliser un existant 2. COMMENT soumettre : branche Figma → review → approbation → merge 3. CRITÈRES DE REVIEW : ce que l'équipe DS vérifie (nommage, tokens, a11y, docs) 4. CONVENTIONS DE NOMMAGE pour les composants, variantes, calques 5. CHECKLIST QUALITE avant de soumettre 6. SLA : combien de temps prend une review 7. ESCALADE : quoi faire si tu as besoin de quelque chose en urgence Ton : utile, pas bureaucratique. Donne envie aux gens de contribuer.

Génère un changelog du design system a partir de ces changements : [liste tes changements recents] Formate chaque entrée comme suit : - Nom du composant + version - Type : NOUVEAU / MIS À JOUR / DÉPRÉCIÉ / BREAKING - Description en une ligne de ce qui a change - Note de migration (si breaking) - Visuel : placeholder "voir lien Figma" Regroupe par date de release. Le plus recent d'abord. Ajoute une section "temps forts" en haut avec les 3 changements les plus importants.

Audite la structure de la bibliotheque Figma suivante et suggere des améliorations : Pages actuelles : [liste des pages] Nommage actuel des composants : [exemples] Structure actuelle des variantes : [exemples] Vérifie : 1. Coherence du nommage (PascalCase ? kebab-case ? mixte ?) 2. Variante vs composant : certaines variantes devraient-elles être des composants séparés ? 3. États manquants (hover, focus, disabled, error, loading, empty) 4. Nommage des calques à l'intérieur des composants ("Frame 47" générique = mauvais) 5. Utilisation de l'auto-layout (tout devrait être en auto-layout ? oui.) 6. Calques de documentation manquants (description, notes d'utilisation) 7. Restructuration suggérée avec justification

On a besoin de 5-7 principes de design pour [produit/marque]. Contexte : [décris le produit, les utilisateurs, les valeurs de marque] Règles pour de bons principes : - Chacun doit être TRANCHE (si le contraire sonne bete, le principe est trop générique) - Chacun doit aider a TRANCHER DES DEBATS ("on ajoute cette feature ?" → check le principe n°3) - Chacun a besoin d'un vrai EXEMPLE d'application - Chacun a besoin d'un CONTRE-EXEMPLE de ce que ça donne quand on le viole - Utilise la voix active, le present, max 8 mots par principe Mauvais : "Garder les choses simples" (trop générique) Bon : "Moins de choix, plus de certitude" (tranche, actionnable)

Crée un système complet de messages d'erreur pour [produit]. Pour chaque type d'erreur (validation, serveur, permission, introuvable, timeout, hors ligne, rate limit) : 1. TITRE : ce qui s'est passe (max 6 mots) 2. CORPS : pourquoi c'est arrive + ce que l'utilisateur peut faire (max 2 phrases) 3. BOUTON D'ACTION : la solution (pas "OK" — l'action reelle) 4. TON : empathique mais pas excessivement desole. Pas de "Oups !" — on est des professionnels. Règles : - Ne blame jamais l'utilisateur - N'utilise jamais de jargon technique (pas de "Erreur 403" ou "Payload invalide") - Propose toujours une prochaine étape - Utilise la voix du produit : [décris la voix] Crée aussi un arbre de décision : "Quand [type d'erreur] arrive → affiche [ce pattern]"

Rédige les textes d'état vide pour ces écrans dans [produit] : [liste des écrans : dashboard, boîte de reception, résultats de recherche, favoris, etc.] Pour chaque état vide : 1. SUGGESTION D'ILLUSTRATION : quel visuel montrer (1 ligne) 2. TITRE : motivant, pas triste (max 5 mots) 3. CORPS : explique la valeur de remplir cet état (1-2 phrases) 4. CTA : l'action pour le remplir (label du bouton) Règles : - Les états vides sont des OPPORTUNITÉS, pas des impasses - Montre la valeur : "Tes designs sauvegardes apparaitront ici" et non "Rien ici pour l'instant" - Le CTA doit être la prochaine étape la plus logique - Respecte la voix du produit : [décris]

Rédige les textes pour un flux d'onboarding en [X] étapes pour [produit]. Contexte utilisateur : [qui ils sont, pourquoi ils se sont inscrits] Pour chaque étape : 1. TITRE D'ECRAN (max 4 mots) 2. CORPS (max 2 phrases — explique pourquoi cette étape compte) 3. LABELS DES CHAMPS + PLACEHOLDERS (si formulaire) 4. BOUTON CTA (orienté action, pas "Suivant") 5. OPTION PASSER (si on peut passer — formule-la honnetement) 6. INDICATEUR DE PROGRESSION ("Étape 2 sûr 4" ou quelque chose de plus humain) Règles : - Chaque étape doit apporter de la valeur ou creer de la confiance - Commence par l'étape la plus facile (reduis la friction des le debut) - Ne demandé jamais une information dont tu n'as pas besoin immédiatement - Le CTA de la derniere étape doit donner le sentiment d'une arrivee, pas d'une soumission

Génère 5 alternatives de label de bouton CTA pour ce contexte : Page : [décris la page] CTA actuel : [label actuel] Objectif : [ce qui se passe quand ils cliquent] État d'esprit de l'utilisateur : [ce qu'il pense/ressent à ce moment] Pour chaque alternative : 1. Le label (max 4 mots) 2. Pourquoi ça fonctionne (1 phrase — principe psychologique/UX derrière) 3. Lift de conversion predit vs actuel : faible / moyen / fort 4. Risque : une audience qui pourrait reagir negativement Classe du plus sûr au plus audacieux. Inclus au moins une option non-conventionnelle.

Crée un système de textes de notifications pour [produit]. Types de notifications : [liste : bienvenue, action requise, mise à jour de statut, rappel, accomplissement, social, marketing] Pour chaque type, rédige : 1. Notification PUSH (max 50 caractères titre + 100 caractères corps) 2. Toast IN-APP (max 1 ligne) 3. OBJET d'email (max 50 caractères, pas de clickbait) Règles : - Chaque notification doit être ACTIONNABLE ou INFORMATIVE — jamais juste "hey !" - Niveaux d'urgence : immediat (push) / digest quotidien (email) / passif (in-app) - Personnalise avec [prenom] et [contexte de l'action] - Inclus un texte de désinscription pour les notifications marketing

Crée un guide de voix et de ton pour [produit/marque]. Personnalite de la marque : [décris en 3-5 adjectifs] Utilisateurs cibles : [décris] Ton des concurrents : [décris comment ils sonnent] Inclus : 1. VOIX (constante) — 4 piliers avec "on est / on n'est pas" pour chacun 2. TON (varie selon le contexte) — comment la voix s'adapte pour : succes, erreur, onboarding, upsell, état vide 3. VOCABULAIRE — mots préférés vs mots à éviter (tableau de 15+) 4. RÈGLES DE GRAMMAIRE — contractions ? Virgule d'Oxford ? Points d'exclamation ? 5. EXEMPLES — réécris 5 chaines d'interface courantes dans ta voix (avant/apres) 6. LE TEST "CA SONNE COMME" — "Si notre produit etait une personne, ce serait [X], pas [Y]"

Lance une évaluation heuristique sur l'interface suivante en utilisant les 10 heuristiques d'utilisabilité de Nielsen. Pour chaque heuristique : 1. SCORE (1-5) 2. PREUVE — ce que tu as concrètement observé (sois précis, référénce les éléments) 3. SÉVÉRITÉ — cosmétique / mineure / majeure / catastrophe 4. CORRECTIF — une amélioration précise Description de l'interface : [décris l'interface en detail, ou colle une représentation textuelle de l'UI] A la fin, fournis : - Score d'utilisabilité global (moyenne des 10 heuristiques) - Top 3 des quick wins (sévérité la plus haute + correctif le plus facile) - Un problème structurel qui nécessite un redesign

Analyse la charge cognitive de cet écran/flux : [décris l'interface] Evalue : 1. COMPLEXITE VISUELLE — nombre d'éléments distincts, clarté de la hiérarchie visuelle 2. POINTS DE DECISION — combien de choix l'utilisateur doit faire 3. CHARGE MEMORIELLE — ce que l'utilisateur doit retenir vs ce qui est affiche 4. DENSITE D'INFORMATION — densité de texte, densité de données, ratio d'espace blanc 5. COUT D'INTERACTION — clics, scrolls, inputs nécessaires pour atteindre l'objectif Pour chaque dimension : - État actuel : faible / moyen / élevé - Elements spécifiques qui contribuent à la charge - Une stratégie de réduction Recommandation finale : la plus grosse réduction de charge cognitive possible.

Audite ce formulaire sur l'UX, l'accessibilité et la conversion : [décris le formulaire : champs, labels, mise en page, validation, etc.] Vérifie : 1. NOMBRE DE CHAMPS — certains peuvent-ils être supprimés ou combinés ? 2. LABELS — au-dessus ou a côté ? Placeholder comme label ? (mauvais) 3. TYPES D'INPUT — bons types HTML utilises ? (email, tel, etc.) 4. VALIDATION — inline ou à la soumission ? Temps réel ou différée ? 5. MESSAGES D'ERREUR — utiles ou génériques ? 6. PROGRESSION — l'utilisateur sait-il où il en est ? 7. MOBILE — tailles des zones tactiles, types de clavier, autofill 8. CONFIANCE — y a-t-il de la preuve sociale pres du bouton de soumission ? 9. FRICTION — qu'est-ce qui ferait abandonner ce formulaire ? Fournis une structure de formulaire révisée avec tous les correctifs appliques.

Simule un test de 5 secondes sur cette page. Imagine que tu es un visiteur qui arrive pour la première fois. Apres 5 secondes de scan, reponds : 1. De quoi parle cette page ? (1 phrase) 2. C'est pour qui ? 3. Quelle est l'action principale que je suis cense faire ? 4. Est-ce que je fais confiance à cette page ? Pourquoi ou pourquoi pas ? 5. Qu'est-ce qui manque et que j'aurais besoin de voir avant d'agir ? 6. Qu'est-ce qui a capte mon attention en premier ? 7. Qu'est-ce qui m'a embrouille ? Description de la page : [décris la mise en page, le texte, les images, le CTA] Ensuite : note la page de 1 à 10 sur la clarté, la confiance et la motivation à agir.

Audite ce tunnel de conversion pour les risques d'abandon : Étapes : [liste chaque étape : landing page → tarifs → inscription → onboarding → première action] Pour chaque étape : 1. FRICTION — qu'est-ce qui pourrait empecher quelqu'un de continuer ? 2. MOTIVATION — qu'est-ce qui le pousse en avant ? 3. ANXIETE — qu'est-ce qui l'inquiete à ce moment ? 4. RISQUE D'ABANDON — faible / moyen / élevé 5. CORRECTIF — un changement précis pour réduire l'abandon A la fin : - Identifie l'étape qui "fuit" le plus - Suggere un A/B test par étape - Estime le lift de conversion potentiel si tous les correctifs sont implementes

Crée une matrice de comparaison des fonctionnalités pour [catégorie de produit]. Concurrents : [liste 4-6] Pour chaque concurrent, évalue ces dimensions : [liste les fonctionnalités/capacites cles] Notation : present (complet) / partiel / absent Ajoute une colonne "différenciation" : ce qui est unique à chaque concurrent et que personne d'autre n'a. Formate en tableau. En bas, ajoute : - Trous du marche : fonctionnalités que personne ne propose bien - Table stakes : fonctionnalités que tout le monde a (ne competitionne pas la-dessus) - Differenciateurs : la où se joue la vraie bataille

Analyse ces pages tarifs concurrentes d'un point de vue UX + persuasion : [décris 3-4 pages tarifs de concurrents] Pour chacune, identifié : 1. ANCRAGE — comment ils encadrent l'option "meilleure" 2. LEURRE — y a-t-il un plan concu pour rendre un autre plus attractif ? 3. PREUVE SOCIALE — quels signaux de confiance sont proches du CTA ? 4. REDUCTION DE FRICTION — essai gratuit ? Garantie remboursement ? Sans carte bancaire ? 5. RARETE/URGENCE — une pression temporelle ? 6. HIÉRARCHIE DE L'INFORMATION — qu'est-ce qui est mis en avant vs cache ? Ensuite recommande la structure de notre page tarifs basee sur les meilleurs patterns trouves.

Compare l'expérience d'onboarding de ces [X] produits : [décris chaque flux d'onboarding : étapes, écrans, textes, temps avant la première valeur] Pour chacun : 1. TEMPS AVANT LA VALEUR — combien de temps avant que l'utilisateur ait son premier "aha moment" ? 2. NOMBRE D'ÉTAPES — combien d'écrans avant de pouvoir utiliser le produit ? 3. PERSONNALISATION — posent-ils des questions pour personnalisér l'expérience ? 4. METRIQUE D'ACTIVATION — quelle action marque un onboarding "reussi" ? 5. RISQUE D'ABANDON — où les utilisateurs quitteraient-ils le plus probablement ? Classe-les du meilleur au pire. Identifie les patterns gagnants qu'on devrait adopter.

Positionne ces concurrents sur une matrice 2x2 : Concurrents : [liste] Suggere 3 paires d'axes possibles qui reveleraient un positionnement intéressant : (ex. simple↔complexe x pas cher↔premium, self-serve↔accompagnement x horizontal↔vertical) Pour la meilleure paire d'axes : - Place chaque concurrent sur la carte avec justification - Identifie les quadrants vides (opportunités d'espace blanc) - Recommande ou on devrait se positionner et pourquoi Un paragraphe sur l'implication stratégique de ce positionnement.

Lance un audit d'accessibilité WCAG 2.2 Niveau AA sur cette interface : [décris l'interface : structure HTML, couleurs, interactions, formulaires] Vérifie ces catégories : 1. PERCEPTIBLE — contraste des couleurs (4.5:1 minimum), texte alternatif, sous-titres, taille du texte 2. UTILISABLE — navigation clavier, indicateurs de focus, pas de pièges clavier, zones tactiles (44px minimum) 3. COMPRÉHENSIBLE — identification des erreurs, labels, navigation coherente 4. ROBUSTE — HTML sémantique, rôles ARIA, compatibilite lecteur d'écran Pour chaque problème trouve : - Numero du critère WCAG (ex. 1.4.3) - Severite : A / AA / AAA - Ce qui ne va pas - Comment corriger (exemple de code si pertinent) Résumé : taux de conformite (X/Y critères respectés) et top 3 des correctifs critiques.

Simule un lecteur d'écran (VoiceOver/NVDA) lisant cette page : [décris la structure HTML, titres, liens, boutons, images, formulaires] Pour chaque élément, écris exactement ce que le lecteur d'écran annoncerait : - Annonce du type d'élément (ex. "titre niveau 2") - Contenu lu à voix haute - État (deplie, sélectionné, requis, etc.) - Eventuelles surcharges ARIA Identifie les problèmes : - Annonces manquantes (images sans alt, boutons sans labels) - Ordre de lecture confus - Annonces redondantes - Regions landmark manquantes Fournis le HTML corrige pour chaque problème.

Crée une checklist de design inclusif pour [produit/fonctionnalité]. Couvre ces contextes utilisateurs : - Visuel : basse vision, daltonisme, cécité - Moteur : dextérité limitee, utilisation à une main, tremblements - Cognitif : faible littératie, difficultés d'attention, langue non-maternelle - Situationnel : plein soleil, environnement bruyant, connexion lente, petit écran Pour chaque contexte : 1. Le defi spécifique qu'ils rencontrent avec notre produit 2. Une solution design 3. Comment la tester (outil ou méthode) Ajoute une section "quick wins" : 5 changements qui prennent moins d'1 heure chacun mais améliorent significativement l'accessibilité.