Quand un fondateur me demande de jeter un œil à son produit existant, les problèmes sont rarement exotiques. Les mêmes huit problèmes expliquent l’essentiel de ce qui fait qu’une interface paraît inachevée, et tous sont peu coûteux à corriger au regard de tout ce qu’ils changent dans l’impression que donne le produit.
Rien de tout cela n’est une question de goût. Chaque point ci-dessous s’accompagne d’un test concret que vous pouvez faire sur vos propres écrans cet après-midi.
Trop de tailles de typographie, trop peu de hiérarchie
Comptez les tailles de police distinctes de votre produit. Si le nombre dépasse huit, certaines ne servent à rien. Le schéma habituel, ce sont des tailles qui diffèrent d’un seul pixel (15 et 16, 13 et 14), ce qui se lit comme une incohérence plutôt qu’une hiérarchie, parce que l’œil n’arrive pas à résoudre la différence mais enregistre bien que quelque chose cloche.
Le correctif, c’est une échelle fixe avec des sauts évidents entre les paliers, et l’usage de la graisse et de la couleur pour créer les distinctions les plus fines plutôt que la taille. Une étiquette en gris atténué de la même taille que le texte courant se distingue parfaitement sans nouvelle taille dans l’échelle.
L’erreur connexe, ce sont les niveaux de titre choisis d’après leur apparence. Choisissez le niveau de titre selon la structure du document et stylez-le pour qu’il rende bien ; les lecteurs d’écran comme les moteurs de recherche lisent la structure, pas la taille en pixels.
Un espacement uniforme au lieu d’être groupé
Les interfaces qu’on a du mal à parcourir du regard sont généralement espacées de façon uniforme : le même écart de 16px entre une étiquette et son champ qu’entre deux sections sans rapport. La proximité est le signal de regroupement le plus fort qui soit, et l’utiliser de manière uniforme le gaspille.
Corrigez cela en décidant d’abord des relations. Une étiquette se tient près de son champ, les champs se tiennent plus éloignés les uns des autres, et une rupture de section reçoit deux ou trois fois cet écart. Quand l’espacement est bon, vous pouvez plisser les yeux devant l’écran et voir encore la structure.
Pendant que vous y êtes, choisissez une unité de base (4px est une bonne valeur par défaut) et cessez d’utiliser des valeurs hors de l’échelle. L’espacement arbitraire est de loin la source la plus fréquente de cette impression que « quelque chose ne va pas tout à fait » que les clients signalent sans pouvoir la diagnostiquer.
Un contraste qui échoue sur les écrans réels
Le texte en gris clair sur fond blanc paraît raffiné sur le moniteur calibré d’un designer dans une pièce peu éclairée. Il est illisible sur un portable en extérieur, et il ne satisfait pas aux exigences d’accessibilité. Le seuil à respecter est un rapport de contraste de 4.5:1 pour le texte courant et 3:1 pour le grand texte, les icônes et les bordures des contrôles interactifs.
Passez un vérificateur de contraste sur votre texte atténué, votre texte de placeholder, vos états disabled et vos bordures. Le texte de placeholder est l’échec le plus fréquent, et il porte souvent une information qui aurait de toute façon dû être une étiquette.
L’autre moitié, c’est de ne pas s’en remettre à la seule couleur. Une bordure rouge sur un champ invalide ne signifie rien pour une personne daltonienne sans une icône et un message. Les erreurs ont besoin de texte, toujours.
Des états vides, de chargement et d’erreur laissés sans design
Le premier écran que voit un nouvel utilisateur est généralement l’écran vide, et c’est généralement l’écran le moins conçu du produit. Un état vide qui dit "Aucun projet pour l’instant" gâche le moment ; un état qui explique ce qu’est un projet et propose le bouton pour créer le premier, c’est de l’onboarding.
Les états de chargement méritent la même attention. Un squelette qui a la forme du contenu à venir réduit l’attente perçue et évite que la mise en page saute à l’arrivée des données. Un spinner centré ne fait ni l’un ni l’autre.
Pour les erreurs, écrivez des messages qui nomment le problème et l’action suivante. "Une erreur est survenue" ne dit à l’utilisateur qu’une chose : que vous n’avez pas pensé à ce cas.
Des formulaires qui se battent contre la personne qui les remplit
Les placeholders utilisés comme étiquettes disparaissent dès que l’on tape, si bien que quiconque est interrompu doit vider le champ pour se rappeler ce qu’il demandait. Utilisez une étiquette persistante au-dessus du champ et gardez le placeholder pour des exemples de format, si tant est qu’il y en ait.
Validez à la perte du focus plutôt qu’à chaque frappe, pour ne pas annoncer à l’utilisateur que son e-mail est invalide alors qu’il en est encore au troisième caractère. Placez le message d’erreur directement sous le champ, en texte, et dites comment le corriger.
Réduisez les champs. Chaque champ facultatif est une petite taxe sur l’achèvement, et la plupart des formulaires en ont au moins deux qui existent parce que quelqu’un a un jour pensé que la donnée pourrait servir. Quatre champs est un bon objectif pour un formulaire de contact.
Les zones tactiles et la pensée desktop d’abord
Les boutons à icône seule conçus à 24px sur une maquette desktop deviennent des zones tactiles de 24px sur un téléphone. Le minimum pratique tourne autour de 44px de surface tactile, que vous pouvez obtenir avec du padding sans changer la taille visuelle de l’icône.
Vérifiez aussi l’espace entre les zones adjacentes : une rangée d’icônes espacées de 4px provoque des touchers ratés quelle que soit la taille individuelle. Et placez les actions principales à portée du pouce sur mobile, plutôt que de les épingler dans un coin en haut à droite hérité de la mise en page desktop.
Concevoir avec du contenu qui n’existera jamais
Le lorem ipsum a une longueur de mot commode et uniforme. Les vraies données d’un produit, non. Les mises en page bâties sur du faux texte cassent avec le client dont le nom d’entreprise fait quarante caractères, avec le total de facture qui compte deux chiffres de trop, et avec la notification qui arrive sans aucun texte de corps.
Utilisez du contenu réaliste dès le départ, puis mettez-le à l’épreuve : la chaîne la plus longue plausible, la plus courte, le cas vide. Si le design ne tient qu’à la longueur idéale, c’est une image d’interface et non une interface.
Pas de focus visible et pas de parcours au clavier
Les composants personnalisés sont fréquemment livrés avec l’anneau de focus du navigateur supprimé et rien à la place, ce qui rend le produit inutilisable au clavier et invisible pour quiconque navigue sans souris. Concevez un style de focus qui s’accorde au langage visuel au lieu de supprimer celui par défaut.
Ensuite, parcourez vous-même un flux clé à la touche Tab. Vous trouverez la modale qui ne piège pas le focus, le menu déroulant qu’on ne peut pas ouvrir sans un clic, et l’ordre dans lequel les éléments reçoivent le focus sautant partout sur l’écran. Ce sont des correctifs de vingt minutes à la conception et des réécritures après le lancement.
