Dans une équipe produit, chacun prend des décisions de design au quotidien : le développeur qui choisit la taille d'un bouton, le product manager qui valide un parcours, le tech lead qui arbitre entre deux approches d'interface. Pourtant, rares sont les équipes où tout le monde partage un vocabulaire commun. C'est pour combler ce manque que nous avons créé un guide complet "UX & Design d'Applications Web — Pour les Nuls", pensé pour les équipes travaillant sur des applications SaaS/Rails. Voici une synthèse des points essentiels.
UX vs UI : une distinction fondamentale
La confusion entre UX et UI est probablement le malentendu le plus fréquent dans nos équipes. L'UX (User Experience) désigne l'expérience globale vécue par l'utilisateur : la facilité d'utilisation, la satisfaction, l'efficacité du parcours. L'UI (User Interface) concerne la couche visuelle : boutons, couleurs, typographie, disposition.
Pensez à un restaurant. L'UX, c'est toute l'expérience — le temps d'attente, l'amabilité du serveur, le goût du plat. L'UI, c'est la présentation de l'assiette et le design de la salle. Une belle UI ne rattrape jamais une mauvaise UX : un formulaire aux couleurs magnifiques mais avec 15 champs obligatoires sera abandonné.
Les heuristiques de Nielsen : 30 ans et toujours d'actualité
Jakob Nielsen a formulé en 1994 dix principes d'évaluation d'une interface qui restent la référence absolue. Parmi les plus critiques pour nos projets Rails :
Visibilité de l'état du système — L'utilisateur doit toujours savoir ce qui se passe. Quand il soumet un formulaire, un spinner et un message "Enregistrement en cours…" sont indispensables. Avec Turbo/Hotwire, pensez à désactiver le bouton au submit.
Prévention des erreurs — Mieux vaut empêcher l'erreur que la signaler après coup. Les confirmations avant suppression, la validation côté client en temps réel, les champs désactivés quand une action n'est pas possible : autant de garde-fous simples à implémenter.
Reconnaissance plutôt que rappel — Ne forcez pas l'utilisateur à mémoriser des informations. Affichez des placeholders, des valeurs par défaut, des suggestions contextuelles. Un select avec recherche (combobox) plutôt qu'un champ libre quand les options sont connues.
Les lois UX que tout développeur devrait connaître
La loi de Fitts nous dit que plus une cible est grande et proche, plus elle est facile à atteindre. Concrètement : vos boutons d'action principaux doivent être suffisamment grands (minimum 44px en mobile) et placés dans des zones accessibles.
La loi de Hick établit que le temps de décision augmente avec le nombre d'options. Pour un formulaire long, découpez-le en étapes (wizard/stepper) plutôt que de tout afficher d'un coup.
La loi de Miller (le fameux "7 ± 2") rappelle que notre mémoire de travail est limitée. Regroupez vos éléments de navigation, limitez les onglets principaux, utilisez des catégories logiques.
La loi de Jakob stipule que les utilisateurs s'attendent à ce que votre site fonctionne comme les autres sites qu'ils connaissent. N'innovez pas sur les conventions établies : le logo ramène à l'accueil, le panier est en haut à droite, le menu principal est en haut ou à gauche.
Le langage visuel : hiérarchie, typo et couleurs
La hiérarchie visuelle guide l'œil de l'utilisateur. Les trois leviers principaux sont la taille (ce qui est grand attire l'attention), le contraste (ce qui se démarque capte le regard) et l'espacement (ce qui est isolé paraît important).
En typographie, la règle d'or est de ne pas dépasser deux familles de polices et de respecter une échelle cohérente. La longueur de ligne optimale pour la lisibilité se situe entre 45 et 75 caractères.
Les couleurs ont une sémantique universelle dans les interfaces web : vert pour le succès/validation, rouge pour le danger/suppression, orange pour les avertissements, bleu pour l'information/actions principales. Ne jamais utiliser la couleur comme seul vecteur d'information (pensez aux daltoniens).
Avec Tailwind CSS, cette cohérence est facilitée par les classes utilitaires : p-4 (16px de padding), gap-2 (8px d'espacement), text-sm / text-base / text-lg pour l'échelle typographique.
Le vocabulaire des composants UI
Un des objectifs clés du guide est de doter l'équipe d'un vocabulaire partagé. Voici les composants les plus courants dans une application SaaS :
Navigation : la sidebar (menu latéral permanent), la navbar (barre de navigation horizontale), le breadcrumb (fil d'Ariane), les tabs (onglets de contenu).
Overlays : le modal/dialog (fenêtre superposée bloquante), le drawer (panneau glissant depuis le bord), le popover (bulle contextuelle), le tooltip (info-bulle au survol).
Feedback : le toast/snackbar (notification temporaire non bloquante), l'alert/banner (message persistant important), le skeleton (placeholder animé pendant le chargement), le spinner (indicateur de chargement).
Formulaires : le combobox (select avec recherche), le toggle/switch (interrupteur on/off), le date picker, les radio buttons vs checkboxes.
Actions : le kebab menu (⋮ trois points verticaux), le FAB (bouton d'action flottant), le dropdown menu, la command palette (⌘K).
Le Design System : construire la cohérence
Un Design System est un ensemble de composants réutilisables, de guidelines et de principes qui permettent de construire des interfaces cohérentes à grande échelle. Il repose sur le concept d'Atomic Design de Brad Frost : atomes (bouton, input) → molécules (champ de recherche) → organismes (header complet) → templates → pages.
Les Design Tokens sont les variables fondamentales du système : couleurs, espacements, tailles de police, border-radius, ombres. Avec Tailwind, votre fichier tailwind.config.js est de fait votre source de tokens.
Pour la collaboration avec les designers, Figma est l'outil de référence. Les développeurs n'ont pas besoin de maîtriser Figma, mais doivent savoir utiliser le mode Inspect pour récupérer les valeurs CSS, les espacements et les couleurs.
Bonnes pratiques SaaS / Rails
Les applications SaaS partagent des patterns récurrents qu'il est utile de standardiser :
Les data tables (tableaux de données) sont omniprésentes. Les bonnes pratiques incluent : aligner les nombres à droite, les textes à gauche, prévoir la pagination ou le scroll infini, et toujours offrir un tri et un filtrage.
Pour les formulaires Rails, l'erreur la plus courante est d'afficher les erreurs uniquement en haut de page après un submit. Préférez la validation inline en temps réel, les messages d'erreur à côté du champ concerné, et des libellés clairs au-dessus (pas à l'intérieur) des champs.
Les empty states (états vides) sont souvent négligés. Quand une liste est vide, ne montrez pas juste "Aucun résultat" : guidez l'utilisateur avec un message explicatif et un call-to-action ("Créez votre premier projet").
Accessibilité : un minimum vital
L'accessibilité (a11y, contraction de "accessibility" avec 11 lettres entre le a et le y) n'est pas optionnelle. Les bases à retenir :
Le ratio de contraste minimum WCAG AA est de 4.5:1 pour le texte normal et 3:1 pour le texte large. Utilisez les outils de vérification intégrés dans Chrome DevTools.
La règle d'or ARIA est "No ARIA is better than bad ARIA" : n'ajoutez des attributs ARIA que si vous savez ce que vous faites. Un HTML sémantique bien structuré (nav, main, button, label) est toujours préférable.
Testez la navigation au clavier : tout élément interactif doit être focusable et activable au clavier. L'indicateur de focus ne doit jamais être masqué (outline: none sans alternative est une erreur fréquente).
Pour aller plus loin
Ce résumé ne couvre qu'une fraction du guide complet. Celui-ci inclut également un glossaire A-Z de tous les termes, une checklist d'évaluation rapide, des exercices pratiques, et des ressources recommandées. Un QCM de 40 questions est également disponible dans le module 5 pour valider l'acquisition de ces compétences.
L'objectif n'est pas de transformer chaque membre de l'équipe en designer, mais de créer un socle commun qui améliore la communication, la qualité des revues de code, et in fine l'expérience de vos utilisateurs.
