Évaluer un système de design dans le parcours réel
Le nombre de composants renseigne peu sur leur utilité. Un bouton de commande montre les états qui nécessitent des règles communes.
Évaluez un système de design selon la capacité de ses éléments à soutenir les tâches récurrentes de façon fiable. Le nombre de composants dessinés est un indicateur faible. Un seul bouton de commande révèle déjà la distance entre une belle vue et un comportement utile.
L’exemple est fictif. Un portail client reçoit un bouton « Envoyer la commande » soigneusement conçu. Espacements, couleur et typographie conviennent. Le composant est considéré comme terminé dans la maquette. Ce qui suit le déclenchement d’une requête reste indécis.
Une apparence ne couvre pas différents résultats
Situation dans l’exemple | Information à transmettre |
|---|---|
Requête en cours | L’opération continue ; une nouvelle activation est traitée selon le parcours. |
Commande confirmée par le serveur | La référence B-42 et le statut confirmé sont affichés. |
Quantité invalide refusée par le serveur | La quantité reste visible et peut être corrigée de façon compréhensible. |
Connexion interrompue après l’envoi | Le résultat est incertain ; le statut de la commande doit être vérifié. |
Un bouton rouge n’explique pas la dernière situation. La commande peut déjà exister. De même, une coche verte sans réponse confirmée ne prouve pas la réussite. La justesse de l’information compte autant que la présentation.
Relier comportement commun et règles du produit
Le composant peut fournir un focus visible, de la place pour les libellés longs et un affichage du traitement. Le tunnel de commande doit connaître les quantités autorisées et la manière de clarifier un résultat serveur incertain. Un bouton générique ne peut pas résoudre ces règles.
Le guide WAI-ARIA décrit un rapport similaire : un rôle exprime le sens attendu, mais n’implémente pas l’interaction clavier. Des valeurs graphiques communes, comme une couleur de texte nommée dans un design token, ne remplacent ni le comportement ni le lien entre maquette et code.
Un bouton désactivé n’est pas non plus la bonne réponse à toute erreur. GOV.UK signale des difficultés possibles de compréhension. Si une action est bloquée, la personne doit disposer d’une explication claire et d’une prochaine étape accessible.
La profondeur nécessaire dépend de l’usage
Une page d’information statique n’a pas besoin d’un statut de commande. Un logo purement visuel n’exige pas de machine à états pour des requêtes serveur. Imposer les mêmes variantes à chaque composant créerait un entretien inutile.
À l’inverse, une bibliothèque existante et testée peut déjà répondre à ces besoins. Bien l’intégrer peut alors être plus pertinent que la reconstruire. L’évaluation changerait si les parcours réels ne pouvaient manifestement pas être représentés de manière compréhensible avec les composants disponibles.
Validez donc un parcours récurrent dans l’interface implémentée, erreurs et traductions longues comprises. Ici, le composant n’est utilement intégré que si la personne dont le résultat de commande est incertain sait aussi quoi faire ensuite. Éviter les commandes en double exige en plus des règles serveur adaptées ; désactiver un bouton ne suffit pas.
Sources
Écrit par
- Julia HoffmannRédactrice design et UXJulia Hoffmann est responsable chez ASES des contenus éditoriaux consacrés au design et à l’expérience utilisateur. Ses articles portent sur l’utilisation des sites web et des applications, la conception d’interfaces utilisateur et l’accessibilité numérique.
À lire aussi
Tous les articles
Votre projet avec ASES
Décrivez-nous votre projet. Nous revenons vers vous avec une première évaluation.