Directives de conception UI/UX

Flux de travail

1. Identifier le but, le problème utilisateur, l'audience/les appareils, la plateforme, le framework, la bibliothèque de composants, le système de design/tokens existant, les breakpoints, les besoins en mode sombre et les contraintes d'accessibilité.
2. Sélectionner la branche de plateforme ci-dessous. Appliquer les règles partagées plus ses exigences.
3. Préserver les motifs établis sauf si le brief demande un changement. Implémenter la plus petite solution conforme.
4. Valider les tokens, le comportement responsive, la sémantique, l'utilisation au clavier/lecteur d'écran, le contraste, le focus, les zones tactiles, les états et le mouvement réduit.

Branches de plateforme

Web et desktop

• Utiliser le HTML sémantique avant ARIA ; maintenir l'ordre de focus logique, le focus visible et la parité pointeur/clavier.
• Valider les breakpoints, les longueurs de ligne lisibles, l'absence de débordement horizontal et les zones cibles minimales de 44×44px.
• Préserver la bibliothèque de composants/système de layout ; préférer le mouvement en CSS seul.

iOS

• Suivre la HIG Apple pour la navigation, les icônes système, les sheets/modales, le feedback et les gestes.
• Gérer les safe areas, l'encoche/Dynamic Island, les indicateurs de statut/accueil, le clavier et le paysage.
• Supporter VoiceOver, Dynamic Type et le mouvement réduit. Zones cibles : ≥44pt avec ≥8pt de séparation.
• Préférer SF Pro/police système actuelle et les couleurs de feedback système ; mapper les rôles sémantiques partagés aux tokens iOS.
• Utiliser le timing spring approprié ; associer les haptics au feedback visuel ou textuel.

Android

• Suivre Material 3 pour les barres d'app/navigation ou rails, FABs, cartes, dialogues, navigation et états appuyés.
• Gérer les barres de statut, la navigation gestuelles, le clavier, les cutouts, portrait et paysage.
• Supporter TalkBack, la mise à l'échelle des polices et le mouvement réduit. Zones cibles : ≥48dp avec ≥8dp de séparation.
• Préférer Roboto/police système actuelle et les couleurs Material 3/tokenisées ; utiliser la couleur dynamique seulement si approprié.
• Utiliser les tokens d'élévation/mouvement et le feedback de pression/état accessible.

Mobile multiplateforme

• Partager les tokens sémantiques et la hiérarchie contenu/interaction. Mapper uniquement les différences de plateforme authentiques (navigation, typographie, élévation/ombres, safe areas, gestes, feedback système, haptics) via Platform.select ou un adaptateur framework ; ne jamais dupliquer les designs entiers pour des différences superficielles.
• En React Native, Expo ou Flutter, préférer la bibliothèque de composants/thème actuel, puis StyleSheet.create ou le thème framework. Ne jamais utiliser les styles inline pour les valeurs statiques.
• Supporter la mise à l'échelle du texte iOS/Android sans coupure ni masquage des actions requises.

Vérifications mobiles partagées

• Utiliser une grille 8pt sauf si le système de design définit une échelle compatible.
• Tester les cutouts/barres système/indicateurs d'accueil, le chevauchement du clavier, les conflits gestuels, la portée, la rotation, le défilement, la performance, l'ordre du lecteur d'écran et le texte volumineux.
• Définir les états de chargement, vide, erreur, actualisation, contenu, sélectionné, désactivé et actif.
• Fournir les valeurs de label d'accessibilité, rôle, indice et état requises par le framework.

Conformité DESIGN.md

Utiliser le format alpha Google DESIGN.md :

1. Frontmatter YAML : version, name, description, colors, typography, rounded, spacing, components.
2. Ordre de prose canonique : ## Overview, ## Colors, ## Typography, ## Layout, ## Elevation & Depth, ## Shapes, ## Components, ## Do's and Don'ts.
3. Couvrir la justification de marque ; la palette sémantique ; la hiérarchie typographique ; l'espacement/grille/largeurs de conteneur ; les niveaux de surface ou alternative plate ; les rayons/bordures ; les définitions de composants ; les garde-fous pratiques.

Chaque valeur components: YAML DOIT être une {token.ref}—jamais une couleur inline, un espacement, une dimension ou toute autre valeur brute. Exécuter npx @google/design.md lint DESIGN.md quand disponible.

Esthétique frontend

• Ancrer les briefs sous-spécifiés dans un sujet concret, une audience et une tâche principale. Dériver le contenu réel et les indices visuels de ses matériaux, outils et vocabulaire—pas d'un thème réutilisable.
• Choisir une direction cohérente et un élément signature défendable. Concentrer la boldness là ; garder le support retenu et éliminer la décoration sans but.
• Faire un héros web démontrer l'idée centrale du produit par le contenu ou l'interaction caractéristique ; éviter les compositions métriques/gradient en boîte sauf si justifié.
• Utiliser la numérotation, les diviseurs, les labels et les sourcils seulement pour communiquer la hiérarchie, la séquence ou la catégorie.
• Adapter l'exécution à la direction : le maximalisme a besoin de profondeur/détail ; le minimalisme a besoin de typographie, espacement et alignement exacts. Réviser tout ce qui pourrait appartenir à n'importe quel produit.
• Préserver la typographie, layout, surfaces, effets, composants, listes, icônes et navigation existants par défaut. Ne pas rejeter les polices standard, les surfaces solides ou les grilles prévisibles sans une raison spécifique à la tâche.
• Choisir une paire affichage/corps distinctive seulement si requis ; charger les polices via l'approche du projet. Valeurs mobiles par défaut : SF Pro sur iOS, Roboto sur Android. Utiliser les polices partagées mappées seulement pour le branding multiplateforme (par exemple, expo-font, react-native-google-fonts ou ressources embarquées).
• Utiliser les tokens/variables CSS existantes. Appliquer 60-30-10 seulement si cela correspond au système de design.

Stratégie de couleur (Mode sombre)

• Inverser les surfaces tout en préservant le contraste du texte ; garder les accents distinguables et remplacer les ombres lourdes par une lueur/contraste de surface retenu si approprié.
• Valider chaque rôle sémantique dans les deux thèmes. Partager les rôles entre plateformes et les mapper aux tokens de plateforme ; ne jamais hard-coder les palettes séparées.
• Utiliser le noir vrai OLED seulement quand c'est approprié pour le produit et compatible avec les tokens. Sur Android, utiliser le thème sombre Material 3 ou les tokens équivalents.

Mouvement et animation

• Orchestrer le mouvement au chargement de page ; ne pas animer tout. Définir les durées/easing cohérentes.
• Préférer CSS sur web/desktop. Sur mobile, utiliser les springs de plateforme ou les tokens Material et mapper la progression du geste à l'état.
• Chaque animation non-essentielle DOIT supporter le mouvement réduit en supprimant, raccourcissant ou remplaçant le mouvement sans perdre l'information ou la complétude de la tâche. Les haptics NE DOIVENT PAS être le seul feedback.

Innovation de layout

Autorisée quand justifiée : grilles asymétriques, chevauchement contrôlé/marges négatives/z-index, flux bento ou diagonal, média full-bleed avec contenu contenu, listes mobiles de hauteur variée, snap scrolling, contrôles flottants atteignables et bottom sheets conscientes des safe areas. Les garder responsives, lisibles, accessibles au clavier et libres de débordement horizontal involontaire.

Accessibilité et états

• Contraste : ≥4,5:1 pour le texte normal ; ≥3:1 pour le texte volumineux et les éléments UI qualifiants. Les indicateurs de focus doivent avoir un contraste suffisant.
• Utiliser le HTML sémantique avant ARIA précis et nécessaire. Assurer l'accès au clavier et l'ordre de focus logique.
• Zones cibles : ≥44×44px web/desktop, ≥44pt iOS, ≥48dp Android.
• Tester VoiceOver/TalkBack et la mise à l'échelle du texte sans coupure ni masquage du contenu essentiel.
• Ne jamais communiquer par mouvement seul. Valider les états vide, chargement, erreur, survol, focus, actif, désactivé et sélectionné.

Priorité de style

Appliquer dans l'ordre :

1. Configuration de la bibliothèque de composants/thème global.
2. Props de la bibliothèque/props thématisées (par exemple NativeBase, React Native Paper, Tamagui).
3. StyleSheet.create (React Native) ou thème framework (Flutter), en utilisant les tokens.
4. Platform.select seulement pour les différences authentiques comme les ombres, polices ou espacement.
5. Les styles inline seulement pour les valeurs runtime-dynamiques—JAMAIS les valeurs statiques.

Règles

• Greenfield UI par défaut moderne, professionnel, cohérent, responsive, accessible et distinct. Préserver le langage visuel établi et les handoffs approuvés sauf refonte explicite.
• Éviter les grilles de cartes interchangeables, conteneurs/pills inutiles, gradients/glassmorphism gratuits, arrondi excessif, icônes ornementales, copie de remplissage et mouvement décoratif. Chaque traitement DOIT supporter la hiérarchie, la marque, l'affordance ou le feedback.
• Utiliser les tokens DESIGN.md et StyleSheet.create ; aucun style hardcoded ou inline statique.