Concevoir une interface qui se comprend

Une interface utilisateur (UI) est la partie visible et manipulable d’un produit : structure, texte, contrôles, couleurs, mouvement et réponses du système. Elle ne se juge pas seulement à son apparence. Une bonne interface réduit le travail de devinette entre une intention et une action.

Question de départ — Que doit comprendre et faire la personne maintenant, et comment saura-t-elle que le système a reçu son action ?

Ce cours suit un exemple unique : une personne ouvre une session de révision de flashcards, répond à une carte, puis reprend la session après une interruption. Chaque principe devient une décision observable.

UI et UX : deux angles du même problème

• UX (expérience utilisateur) : le problème, le contexte, les attentes, le parcours, les émotions, les contraintes et le résultat de l’usage.
• UI (interface utilisateur) : les éléments qui rendent ce parcours visible et manipulable.

La distinction aide à poser les bonnes questions, mais ne doit pas séparer les métiers. Une navigation mal nommée est un problème d’architecture et de microcopy ; un bouton impossible à atteindre au clavier est un problème d’interface et d’expérience.

Le modèle mental avant le style

Une personne arrive avec une représentation de ce qu’elle pense pouvoir faire. Elle cherche des indices, formule une prédiction, agit et compare le résultat à son attente. L’interface devient claire lorsque ces quatre moments s’enchaînent sans surprise inutile :

1. Orientation : où suis-je et quel est l’objectif de cet écran ?
2. Choix : quelles actions sont possibles, et laquelle est prioritaire ?
3. Action : comment l’élément indique-t-il son usage ?
4. Retour : qu’est-ce qui a changé, et que puis-je faire ensuite ?

Le rôle d’un designer n’est pas de deviner les pensées privées d’une personne. Il consiste à rendre les indices, les états et les règles suffisamment observables pour que le comportement soit compréhensible.

Une hiérarchie qui guide l’œil

La hiérarchie visuelle est l’ordre de lecture que la composition suggère. Elle vient de relations cohérentes, pas d’un effet isolé.

1. Donner un objectif à la zone

Chaque écran ou bloc important doit avoir un objectif principal. Pour une session de révision : « répondre à la carte courante » est prioritaire ; le tri, les réglages et l’historique peuvent rester secondaires.

2. Utiliser les différences avec intention

• Position : placer l’objectif et l’action associée dans le même trajet de lecture.
• Taille et poids : réserver le contraste typographique aux niveaux de contenu réellement différents.
• Espace : rapprocher ce qui appartient à la même décision ; séparer les groupes distincts.
• Couleur et forme : signaler une action ou un état, jamais décorer chaque élément au point de supprimer les priorités.
• Répétition : un même rôle doit garder un même aspect et un même comportement.

Si tout est grand, coloré et en relief, rien n’est prioritaire. Le design doit retirer du bruit avant d’ajouter du style.

Mise en page : une carte, pas un labyrinthe

Commence par une structure simple : un conteneur lisible, une grille, des groupes et des espaces réguliers. Une grille n’est pas une prison graphique ; elle évite que chaque écran invente ses propres distances.

Pour une page de cours, pense en couches :

page
├── navigation et emplacement
├── objectif de l’écran
├── contenu principal
│   ├── question ou information
│   ├── action principale
│   └── aide, état ou résultat
└── actions secondaires et retour

La largeur de lecture doit être assez courte pour que l’œil ne perde pas la ligne. Les colonnes supplémentaires sont utiles lorsqu’elles réduisent un aller-retour, pas lorsqu’elles remplissent l’espace disponible.

Typographie : le texte est une interaction

La typographie doit répondre à quatre questions :

• la personne peut-elle lire le texte sans zoomer ou lutter contre le fond ?
• sait-elle distinguer titre, explication, aide et erreur ?
• les lignes sont-elles assez courtes et espacées pour suivre l’idée ?
• les labels décrivent-ils le résultat de l’action ?

Une échelle simple suffit souvent : titre, sous-titre, corps, label et aide. Définis les tailles, hauteurs de ligne et poids dans des tokens. N’utilise pas les capitales, l’italique ou le faible contraste comme unique signal d’un état.

Le bouton « Enregistrer la réponse » est plus utile que « OK », car son texte annonce le résultat. Le microcopy fait partie de l’UI : il explique la règle, réduit l’hésitation et offre une sortie en cas d’erreur.

Couleur et contraste : signaler sans exclure

Une couleur peut renforcer un message, mais elle ne doit jamais le porter seule. Un état « correct » peut combiner :

• un texte explicite (« Réponse enregistrée ») ;
• une icône ou une forme stable ;
• une bordure ou une position cohérente ;
• une couleur dont le contraste a été vérifié.

Sépare les couleurs par intention : accent, information, succès, avertissement et erreur. Évite d’utiliser le rouge comme simple décoration : il doit annoncer un problème ou une action dangereuse. Vérifie le contraste du texte, des contrôles, du focus et des éléments non textuels dans leur état réel.

Les composants sont des contrats

Un composant n’est pas seulement un rectangle réutilisable. Sa spécification doit dire :

1. quel problème il résout et quelle action il représente ;
2. quel élément HTML exprime naturellement ce rôle ;
3. quelles propriétés sont nécessaires et lesquelles sont interdites ;
4. quels états existent : repos, survol, focus, pressé, chargement, succès, erreur, vide, désactivé ;
5. quel nom accessible et quel retour sont exposés ;
6. comment il se comporte à 320 px, avec du texte long et au clavier.

Un bouton, une carte, un champ, une alerte et une barre de progression doivent garder leur contrat d’un écran à l’autre. Si une variante n’a pas d’intention identifiable, c’est probablement une décoration déguisée.

Concevoir les états, pas seulement l’écran idéal

Une interface réelle traverse des états. Pour une session de révision :

État	Ce que la personne doit comprendre	Sortie utile
Repos	La question et l’action disponible	Révéler ou répondre
Chargement	L’action a été reçue	Attendre, sans double soumission
Succès	La réponse est enregistrée et la session avance	Continuer ou revoir
Vide	Il n’y a plus de carte dans ce filtre	Modifier le filtre ou créer une carte
Erreur de saisie	Ce qui doit être corrigé	Revenir au champ concerné
Erreur réseau	Le serveur n’a pas répondu	Conserver le brouillon et réessayer
Accès refusé	Une session ou permission manque	Se reconnecter, sans perdre la saisie

Un message d’erreur utile décrit le problème dans le vocabulaire de la tâche, indique l’emplacement et propose une action. « Une erreur est survenue » ne permet ni de corriger ni de diagnostiquer.

Formulaires : réduire l’hésitation

• Utilise un <form> et un bouton type="submit" lorsque la personne envoie un ensemble de champs.
• Associe chaque champ à un label visible ; l’espace réservé n’est pas un label.
• Explique les contraintes avant l’envoi quand elles sont prévisibles.
• Valide au bon moment : ne punis pas une personne pendant qu’elle compose, mais ne laisse pas une erreur inconnue jusqu’après une longue séquence.
• Place le focus sur la première erreur et relie le message au champ.
• Conserve la saisie pendant une erreur réseau ou une reconnexion.
• Désactive temporairement l’action pendant un envoi, tout en annonçant ce qui se passe.

Responsive : changer la priorité, pas seulement la taille

Un écran mobile ne peut pas garder la même hiérarchie dans une largeur réduite. Décide ce qui reste visible, ce qui peut être regroupé et ce qui peut attendre.

• Une colonne est souvent préférable à deux colonnes comprimées.
• Les actions principales restent atteignables sans précision excessive.
• Les cibles tactiles doivent être espacées et suffisamment grandes.
• Les menus secondaires ne doivent pas cacher une information nécessaire à la décision.
• Le zoom à 200 % et un texte plus long ne doivent pas casser le parcours.
• L’information ne doit pas dépendre d’un survol, indisponible sur tactile et au clavier.

Exemple appliqué : la carte courante

Avant : un titre discret, une carte centrée, quatre boutons sans distinction et une barre de progression sans texte.

Après :

<main aria-labelledby="session-title">
  <h1 id="session-title">Session de révision</h1>
  <p>Carte 3 sur 10 · 4 minutes restantes</p>

  <article aria-labelledby="question-title">
    <h2 id="question-title">Qu’est-ce qu’un modèle mental ?</h2>
    <button type="button" aria-controls="answer" aria-expanded="false">
      Révéler la réponse
    </button>
    <p id="answer" hidden aria-live="polite">
      Une représentation qui aide à prévoir le fonctionnement d’un système.
    </p>
  </article>

  <p role="status" aria-live="polite"></p>
</main>

La structure porte déjà une grande partie du sens : titre de page, titre de carte, bouton natif, relation entre le contrôle et la réponse, annonce du résultat. Le CSS peut ensuite rendre la hiérarchie visible sans remplacer ces relations.

Atelier FlashLearning

Avant de lire l’exemple, réponds avec tes propres mots :

1. Quel est l’objectif principal de l’écran ?
2. Quelle information permet de choisir l’action ?
3. Comment la personne sait-elle que l’action a réussi ?
4. Que peut-elle faire si le réseau échoue ?

Comparer avec une réponse solide

L’objectif est de répondre à la carte courante. La question, le numéro de la carte et le bouton nommé sont proches dans le trajet de lecture. Un retour visible et annoncé confirme l’enregistrement. En cas d’échec, la saisie reste présente et l’action « Réessayer » permet de récupérer l’état sans recommencer.

Checklist de livraison UI

• L’objectif principal est compréhensible en cinq secondes.
• Les titres et labels annoncent le contenu ou le résultat de l’action.
• Le HTML exprime le rôle avant le CSS et les attributs ARIA.
• Chaque composant possède ses états normaux, focus, chargement, succès, vide et erreur.
• Les erreurs indiquent où agir et comment revenir à un état sûr.
• Aucun état ne dépend uniquement de la couleur ou du survol.
• La page reste utilisable à 320 px, au zoom et avec du texte long.
• Le parcours clavier suit l’ordre visuel et garde un focus visible.
• Les contrastes, alternatives et annonces ont été testés dans leur état réel.
• Le design utilise les tokens et composants partagés du projet.

Annexes : sources de référence

• W3C — Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI — ARIA Authoring Practices Guide
• MDN — Accessibilité du Web
• GOV.UK Design System — composants et contenu
• Nielsen Norman Group — 10 heuristiques d’utilisabilité

Pour pratiquer les décisions dans l’ordre, ouvre le parcours UI/UX interactif. Pour les détails CSS, consulte CSS pour une interface ; pour le processus complet, lis le cycle de conception.