Principes
Les principes définissent notre façon de concevoir et de construire. Ils guident chaque décision de design et de développement, des plus grandes aux plus petites.
Nos principes
Accessibilité d'abord
Nos interfaces doivent être utilisables par tous, quelles que soient les capacités de l'utilisateur. L'accessibilité n'est pas une option ou une étape finale, c'est une contrainte de départ.
- Contraste minimum 4.5:1 pour le texte normal
- Navigation complète au clavier
- Attributs
aria-*sur tous les composants interactifs - Taille de texte minimale : 12px
Aller à l'essentiel
Chaque élément présent à l'écran doit avoir une raison d'être. On retire avant d'ajouter. Une interface simple à comprendre est une interface que l'utilisateur n'a pas besoin d'apprendre.
- Un seul appel à l'action principal par écran
- Pas de décoration sans sens
- Hiérarchie visuelle claire et lisible en un coup d'œil
- Les informations secondaires ne concurrencent pas les primaires
Cohérence entre produits
Un utilisateur qui passe d'EasyCheck à EasyMonithor ne doit pas avoir à réapprendre l'interface. Les mêmes patterns, les mêmes composants, les mêmes comportements, seule la couleur primaire change.
- Même composant = même comportement sur tous les produits
- Même usage = même couleur, même spacing, même typographie
- Les tokens garantissent la cohérence sans rigidité
- Jamais de valeur brute dans un composant
Toujours donner du feedback
L'utilisateur doit toujours savoir ce qui se passe. Chaque action déclenchée doit avoir une réponse visuelle, qu'elle soit instantanée ou différée.
- États hover, focus, active sur tous les éléments interactifs
- Loading visible dès qu'une action prend du temps
- Messages d'erreur clairs et actionnables
- Confirmation explicite après une action réussie
Construire pour durer
Chaque composant, chaque token, chaque décision doit pouvoir évoluer sans tout casser. On conçoit des systèmes, pas des pages. La scalabilité commence dans le nommage et la structure.
- Tokens organisés en base → sémantique → composant
- Composants Twig indépendants et réutilisables
- BEM pour un CSS prévisible et maintenable
- Privilégiez Tailwind pour les petites retouches
Réutiliser avant de créer
Avant de créer un nouveau composant, vérifier que le besoin ne peut pas être couvert par un composant existant ou une combinaison de composants existants. Chaque ajout au DS est un engagement de maintenance.
- Consulter la liste des composants avant toute création
- Proposer l'ajout via le process de contribution
- Un composant trop spécifique à un seul écran n'est pas un composant DS
- Privilégier les props aux variantes infinies