Des interfaces qui s'expliquent : 5 règles de design

Le design chez Anested tient en une phrase directrice : les interfaces doivent s'expliquer elles-mêmes. Tout le reste de notre pratique — chaque commentaire de revue, chaque maquette rejetée — est une conséquence de ce test unique. Si un utilisateur a besoin d'un manuel, le design n'est pas terminé.

Premièrement, la hiérarchie avant la décoration. Un écran est un argument hiérarchisé sur ce qui compte le plus. Si tout est en gras, rien ne l'est ; si chaque élément réclame l'attention, l'utilisateur n'en accorde à aucun. Nous fixons les échelles typographiques, les espacements et les alignements avant que quiconque soit autorisé à choisir une couleur, car la hiérarchie communique même quand le style échoue.

Deuxièmement, les états sont le design. États vides, états de chargement, états d'erreur, états de succès — c'est là que vivent réellement les utilisateurs, surtout la première semaine d'utilisation d'un produit. Nous les concevons en premier, pas en dernier. Un beau parcours idéal accroché à un état d'erreur cryptique n'est pas un beau produit ; c'est un produit cassé avec un bon marketing.

Troisièmement, l'animation doit mériter son coût de rendu. Nous avons retiré presque toutes les animations de notre propre site corporate, et ce qui a survécu est le retour visuel au survol, rien d'autre. Chaque animation est une créance sur l'attention de l'utilisateur et la batterie de l'appareil. La retenue, avons-nous constaté, se lit comme de la confiance.

Quatrièmement, l'accessibilité est un plancher, pas une fonctionnalité. Ratios de contraste, états de focus, navigation clavier et balisage sémantique sont exigés en revue de code exactement comme n'importe quel autre problème de correction. Une interface qui ne fonctionne que pour certains utilisateurs est une interface avec un bug.

Et cinquièmement : si nous nous surprenons à écrire un tooltip pour expliquer un contrôle, nous essayons d'abord de redessiner le contrôle. Parfois le tooltip gagne — mais il doit gagner le débat. Le manuel est le bug, et chaque principe ci-dessus n'est qu'une façon différente de ne pas l'écrire.