Que fait UX Playbook ?
Construisez une interface utilisateur correcte pour l'entreprise, facile à utiliser et cohérente. Mantine fournit les composants ; ce playbook vous dit quand utiliser lequel, quels états un écran nécessite et comment vérifier le résultat. Lisez uniquement les pages nécessaires à votre tâche.
Hiérarchie
Lorsque les sources sont en désaccord, la plus haute l'emporte :
- Les exigences métier : le cahier des charges, le ticket ou les instructions du responsable. Ne les modifiez jamais silencieusement.
- Les propres règles du produit :
AGENTS.md/CLAUDE.md, sa documentation UX et design, ses composants existants. - Ce playbook.
- La documentation et les valeurs par défaut de Mantine.
Si 2 et 3 sont en désaccord, suivez 2. Si vous pensez que 2 ou 1 est erroné, suivez-le quand même et soulevez une proposition UX.
Avant tout travail d'interface utilisateur, recherchez les règles UX du produit (parcourez les docs du dépôt pour "UX", "UI", "conception", "panneau"). S'il n'y en a pas, rédigez-les à l'aide du modèle de brief produit et proposez le brouillon dans le plan ou la PR, en étiquetant chaque supposition [Hypothèse].
Choisissez le niveau
| Niveau | La modification | Ce que vous faites |
|---|---|---|
| S | Petite modification sur un écran existant : un champ, un bouton, un message, une colonne | Lisez la page du composant que vous modifiez. Exécutez sa checklist. Prenez des captures d'écran si la disposition a changé. |
| M | Un nouvel écran, dialogue ou formulaire, ou une modification importante de l'un d'eux | Rédigez d'abord une brève spécification UX. Construisez-le. Effectuez la vérification visuelle. Auto-révisez avec la rubrique. |
| L | Un nouveau flux sur plusieurs écrans, une nouvelle zone fonctionnelle, ou une modification de la navigation | Réalisez une note de recherche avec 2 à 3 options. Construisez l'option sûre A. Traitez ensuite chaque écran comme un niveau M. |
Détails et livrables pour chaque niveau : workflow.
Trouvez la page
| Vous décidez... | Lisez |
|---|---|
| Structure de page, hiérarchie, espacement, mise en page responsive | decisions/layout |
| Boutons, primaire vs secondaire, boutons d'icône, menus d'action | decisions/actions |
| Modal vs Drawer vs Popover vs en ligne, infobulles | decisions/overlays |
| Navigation de l'application, onglets, fil d'Ariane, steppers, pagination, lien vs bouton | decisions/navigation |
| Tableaux, listes, cartes, étiquettes de statut, dates, texte long | decisions/data-display |
| Toasts, alertes, bannières, messages en ligne | decisions/feedback |
| Quel composant pour un choix : case à cocher, commutateur, radio, contrôle segmenté, menu déroulant, combobox, chips | decisions/selection |
| Formulaires, étiquettes, validation, champs obligatoires | patterns/forms |
| Boutons Enregistrer, sauvegarde automatique, modifications non sauvegardées | patterns/saving |
| Rien à afficher encore, aucun résultat | patterns/empty-states |
| Attente de données ou de la fin d'un travail | patterns/loading |
| Options avancées, "afficher plus", détails à la demande | patterns/progressive-disclosure |
| Présentation d'une fonctionnalité, première exécution, astuces | patterns/feature-onboarding |
| Serveur indisponible, hors ligne, échec partiel, permission manquante | patterns/degraded-experiences |
| Suppression, réinitialisation, révocation, écrasement | flows/destructive-actions |
| Étiquettes, texte des boutons, texte d'erreur, texte d'état vide | writing |
| Clavier, focus, étiquettes, contraste, ARIA | accessibility |
| Recherche d'une API Mantine, des jetons de thème, des versions | mantine |
| La raison derrière une règle | principles |
Toujours
- Utilisez les composants existants du produit et Mantine avant d'écrire les vôtres. Utilisez un composant par tâche.
- Donnez à chaque vue de données ses états chargement, vide et erreur. Donnez à chaque action un état en attente et un résultat.
- Conservez une action primaire par vue. Les actions secondaires sont plus discrètes. Les actions rares vont dans un menu.
- Une action actuellement indisponible reste visible et indique pourquoi, dans un texte accessible au clavier et au toucher, pas uniquement dans une infobulle. Préférez un aspect inactif (
data-disabled) à l'attributdisabled, et ne désactivez jamais un bouton de soumission : actions. - Confirmez ou permettez l'annulation pour tout ce qui détruit des données. Ne perdez jamais la saisie de l'utilisateur lors d'une erreur.
- Chaque saisie a une étiquette visible. La signification n'est jamais portée uniquement par la couleur. Tout est accessible au clavier.
- Vérifiez le résultat en largeur téléphone et en largeur ordinateur de bureau, en mode clair et sombre : vérification visuelle.
- Les exemples ici utilisent des chaînes littérales en anglais. Utilisez l'internationalisation du produit à la place.
Quand vous pensez que cela pourrait être mieux
Vous pouvez, et devez, proposer de meilleurs flux et composants. La règle est construire la solution sûre par défaut, joindre la proposition :
- Construisez ce que demande le cahier des charges, en utilisant les modèles ici.
- Ajoutez votre idée sous forme de proposition UX dans le plan ou la PR, au format fixe.
- Arrêtez-vous et demandez avant de construire uniquement lorsque le cahier des charges entraînerait une perte de données, exposerait un secret, bloquerait un utilisateur qui dépend d'un clavier ou d'un lecteur d'écran, ou se contredit.
Rapport
Terminez chaque tâche d'interface utilisateur par une section Notes UX dans la PR ou le rapport :
## Notes UX
- Niveau : M — nouvel onglet "Mods"
- États : chargement ✓ vide ✓ erreur ✓ désactivé-avec-raison ✓
- Captures d'écran : 1280 clair/sombre, 390 clair/sombre (jointes)
- Rubrique : tout réussi ; s/o : destructeur (aucun)
- Hypothèses : [Hypothèse] la liste des mods est courte (< 50), donc pas de pagination
- Propositions UX : 1 (voir ci-dessous)