Design d’interface et outils de maquettage

Syllabus

1. Description

2. Objectifs

3. Validations de compétences

4. Public cible

   Aucun public cible spécifié pour ce module.

5. Besoins techniques

6. Prérequis

   • Aucun prérequis

7. Niveau

8. Historique du module

   Aucune action enregistrée

Design d’interface et outils de maquettage

Concevoir une interface avant de la coder : arborescence des besoins, hiérarchie visuelle, système de composants, prototypes testables, puis transfert fiable vers le développement. Les outils servent la méthode, ils ne la remplacent pas.

Ce que l’outil ne remplace pas

Un outil de maquettage est un support, pas une méthode. Il rend rapide ce qui doit l’être — visualiser une intention, partager une variante, tester une hypothesis — et il ne décide de rien : ni du bienfondé d’un écran, ni de la hiérarchie, ni de ce qu’un utilisateur comprendra.

La conséquence pratique : un fichier exported sans intention n’est qu’un dessin. Ce qui distingue une maquette utile d’une maquette agréable, c’est la trace du raisonnement — pourquoi cet ordre, pourquoi ce libellé, pourquoi cet état est prévu. Cette trace est ce qui se transmet, et elle n’existe dans aucun outil.

Le second piège : croire que la maquette est une étape avant le code. Sur une interface complexe, la maquette et le code se contaminent mutuellement — une contrainte technique révèle un problème de conception, et une solution de conception révèle une contrainte technique.Traiter la maquette comme une preuve jetable et le code comme la vérité conduit à jetable deux fois le travail.

Intention : « l’utilisateur doit voir l’action principale sans chercher » → hiérarchie : titre court, une action primaire, détails repliés.

Du besoin à la hiérarchie visuelle

Une interface commence par une tâche, pas par une page. La première question est : qu’est-ce que la personne vient faire ? La réponse tient en un verbe et un objet. Tout ce qui ne sert pas cette tâche est déplacé, retiré ou rendu disponible ailleurs.

De cette tâche découle la hiérarchie : une action principale par écran, visible sans défilement et sans que l’utilisateur ait à deviner la priorité. Les actions secondaires ne disparaissent pas, elles changent de poids — un lien au lieu d’un bouton, une icône avec une étiquette plutôt qu’un bouton pleine largeur.

Regrouper l’information par décision plutôt que par composant technique : l’utilisateur ne pense pas « formulaire », il pense « je valide ma commande ». Un écran qui suit une décision se lit ; un écran qui suit l’arborescence du backend se devine.

Titre → résumé de l’état → action principale → détails repliés → aides contextuelles

Composants et états : ce qui rend une interface tenable

Un écran dessiné isolément est une dette. La question à poser à chaque élément nouveau est : existe-t-il déjà un composant qui fait ce travail, et si non, ce composant est-il général ? Un bouton est un composant ; « bouton bleu de Validation » est une page.

Le composant n’est pas seulement son aspect. Il est son ensemble d’états — repos, survol, focus, actif, désactivé, chargement, erreur — parce que ce sont les états non dessinés qui produisent les défauts en production. Un bouton sans état de chargement fait doublon-cliquer ; un champ sans état d’erreur fait remplir seize fois.

Nommer les composants et documenter leurs variantes dès leur création. Un composant non nommé est dupliqué sous six noms différents en un an, et personne ne sait lequel corriger.

Bouton : repos / survol / focus visible / actif / désactivé / chargement / erreur

Prototyper les états, pas l’écran feliz

La maquette d’écran complet et réussi est la moins utile des maquettes, parce qu’elle ne teste rien. Ce qui trompe, ce sont les états non maquettés : le chargement qui dure, l’erreur réseau, la liste vide, la saisie invalide, le double-clic. Ce sont ces moments que le code réel produit et que la maquette omet.

Prototyper un état critique demande de répondre à des questions concrètes : que voit l’utilisateur pendant l’attente, comment l’erreur se présente-t-elle, que perd-il si l’opération échoue, comment récupère-t-il ? Une maquette qui ne répond pas à ces questions n’est pas prête pour le développement.

Le niveau de fidélité se choisit selon la question posée. Une question d’enchaînement et de compréhension se teste en fil de fer, très tôt, très bon marché. Une question de lisibilité ou de contraste demande la maquette au pixel près. Utiliser la maquette haute fidélité pour tester un enchaînement, c’est payer cher une information que le fil de fer donnait.

Attente : squelette ou indicateur, texte expliquant la durée. Erreur : message + action « Réessayer », saisie conservée.

Du design au développement : perdre le moins possible

La maquette se dégrade à chaque étape de transfert : une police remplacée par une approximation, une marge arrondie, un état interactif oublié, un contraste non respecté parce qu’il était induit par le fond du fichier. Chaque perte est petite ; leur somme est une interface qui ne ressemble plus à rien de prévu.

La parade n’est pas un fichier plus détaillé, c’est un transfert explicite : des valeurs réelles plutôt que des exemples (la police réellement utilisée, la couleur du texte réel, la taille réelle), les états documentés, et un lien explicite entre chaque élément de la maquette et son composant. L’inspecteur de l’outil ne remplace pas cela — il exporte ce qui est dans le fichier, y compris les valeurs d’exemple.

Le sens du transfert se vérifie dans les deux sens : le développeur doit pouvoir reconstruire la maquette sans poser de question, et le designer doit pouvoir vérifier la conformité sans refaire la maquette. C’est un test de passation, et il se fait en montrant l’écran réel à côté de la maquette.

Police réelle, pas « Inter fallback » · écart 16/8/4 · tous états documentés · lien maquette ↔ composant

Tester avant de coder : ce que le test corrige

Un prototype se teste peu importe la qualité de sa présentation, mais surtout avec des personnes qui n’ont pas participé à sa création. Un test dirigé par le designer reconstruit le raisonnement qu’il veut prouver ; un test libre le met en défaut.

La méthode tient en peu de choses : une tâche, un point de départ, aucune explication. Observer sans guider. Le silence est une donnée : il traduit une incompréhension, pas une lenteur de la personne testée. Noter la hesitation, l’erreur, la demande de précision — chaque hesitation est un défaut d’interface localisé, et donc corrigeable.

Trois ou cinq personnes suffisent pour faire apparaître la majorité des défauts de compréhension d’un écran. Le résultat n’est pas une mesure statistique, c’est une liste de points de blocage ordonnée par fréquence, et cette liste est un plan de correction beaucoup plus fiable qu’un avis d’esthétique.

Méthode

1. Écrire la tâche en une phrase, sans nommer les boutons.
2. Observer la personne tester à froid, sans intervenir.
3. Noter chaque hesitation et chaque demande de précision, avec le moment où elle survient.
4. Corriger le premier point de blocage, retester.

Livrables et validation

Le livrable doit montrer une compréhension personnelle, des choix explicités et une vérification par un cas de test ou une procédure reproductible.

• Une arborescence des besoins et un parcours, chaque écran justifié par la tâche principale qu’il sert.
• Un système de composants documenté, avec pour chacun ses états — repos, survol, focus, actif, désactivé, chargement, erreur.
• Un prototype des parcours critiques incluant chargement, erreur, liste vide et saisie invalide, testé avec au moins trois personnes.
• Un dossier de transfert : valeurs réelles, lien entre chaque élément de la maquette et son composant, et la liste des décisions explicitées.
• Le compte rendu des tests : point de blocage principal, sa fréquence, la correction appliquée et le résultat du retest.

Exercices, examens et projets