8 erreurs d'ergonomie évitables qui vous pourrissent un site web

Les petits problèmes d’interface sont souvent le plus grand frein à l’adoption d’un site ou d’une application web pourtant prometteuse. Ces erreurs entraînent agacement et frustration chez l’utilisateur qui finit tout simplement par aller voir ailleurs.
Je vous propose aujourd’hui de passer en revue 8 erreurs fondamentales d’interface facilement évitables, avec pour chacune d’entre elle des solutions aisément et rapidement applicables.

1. Pas de `<label />` sur les libellés de formulaires

Utiliser la balise <label /> permet à vos utilisateurs de placer le focus sur le champ de formulaire associé d’un simple clic sur le libellé associé au champ.

Cela peut sembler superflu. Cependant, associé à une fournée de boutons radio ou une case à cocher, on se rend très vite compte de la puissance de cette balise trop souvent sous-utilisée, y compris sur des sites web récents.

Exemple :

<label for='nom'>Votre nom</label>
<input type='text' name='nom' id='nom' />

Pire encore : une balise <label /> qui pointe vers le mauvais champ de formulaire.

2. Pas de message d’erreur

L’absence de message d’erreur est souvent catastrophique pour l’expérience utilisateur. 3 cas de figure se présentent :

L’utilisateur ne se rend pas compte que quelque chose s’est produit, et continue sa navigation quitte à perdre ses informations ou à rencontrer une erreur plus tard.
L’utilisateur se rend compte que quelque chose (ne) s’est (pas) passée et pense qu’il s’agit d’un bug.
L’utilisateur se rend compte que quelque chose (ne) s’est (pas) passée et pense qu’il s’agit d’une erreur de manipulation de sa part, mais ne sait pas laquelle.

Placez les messages de service toujours au même endroit, et distinguez les par des codes couleur et des visuels adéquats :

Les messages globaux en haut de la section principale de la page (hors header, menu…)
Les messages particuliers à côté ou en dessous des zones en erreur, principalement dans le cadre d’un formulaire.

Le site Fotolia spécialisé dans la vente d’images, par exemple, n’indique pas à ses utilisateurs que le mot de passe saisi est trop court, pas assez, ou trop complexe. Résultat : j’ai passé 20 minutes le mois dernier à tenter de m’enregistrer sans succès.

Pire encore : les messages d’erreur incompréhensibles façon Blue Screen of Death ou Kernel Panic.

3. Utiliser des `alert()` pour afficher erreurs, messages de service et demandes de confirmations

De nombreux sites web – récents – utilisent encore des alert() en Javascript afin d’afficher les erreurs, les messages de service ou les demandes de confirmation. C’est une erreur à plus d’un titre.

Sous Internet Explorer 6 et suivants, alert() est généralement associé à l’affichage des erreurs du navigateur, et notamment des erreurs Javascript. L’utiliser afin de transmettre des informations venant de votre site ou application reviendrait à mélanger les torchons et les serviettes.

Il n’est pas possible de personnaliser le look and feel de la boite d’alerte. Dans tous les cas, le symbole affiché sera le triangle jaune, impropre dans le cas de messages d’erreur.

L’utilisation de confirm() dans le cadre de la validation d’un formulaire ne vous permet pas de récapituler les données à envoyer de manière claire. Si vous souhaitez vraiment rester sur la même page, préférez des artifices de type lighbox, mais dans la plupart des cas, un écran de confirmation récapitulant les données saisies sera la meilleure solution.

Proscrivez également l’utilisation de la méthode prompt() tant que vous y êtes. Nous sommes en 2009 que diable !

4. Pas d’indication de chargement sur les actions en AJAX

Dès qu’une action nécessite un échange via AJAX et la mise à jour d’une zone de la page, pensez à utiliser un indicateur de chargement. Cela peut être le classique spinner d’Apple ou une barre de progression si celle-ci est mesurable.

Surtout, ne posez pas l’image en dur dans la page avant de la cacher en CSS. Posez la en Javascript au moment de lancer l’action, et supprimez la à la fin, c’est un critère d’accessibilité. Ceux qui n’utilisent ni Javascript ni CSS n’ont pas besoin de voir vos loaders.

5. Ne pas indiquer les champs obligatoires dans les formulaires

Indiquez de manière visible les champs obligatoires dans vos formulaires. Soit en mettant ces champs en valeur avec de la CSS, soit en faisant suivre chaque champ ou son libellé d’un astérisque rouge. Vous pouvez indiquer en bas de votre formulaire que la présence de l’astérisque indique un champ obligatoire, même si sa signification est maintenant communément admise.

Je suis personnellement à 100% pour la seconde méthode. La mise en valeur des champs obligatoire pénalise les handicapés visuels : aveugles, daltoniens… et sa signification n’est pas toujours évidente.

En cas d’erreur dans la saisie des champs, ramenez l’utilisateur à son formulaire, et pré remplissez les champs précédemment saisis. Indiquez en face ou en dessous de chaque champ en erreur les raisons de l’erreur à l’aide de messages clairs et circonstanciés. Préférez Le nom est obligatoire à Ce champ est obligatoire, ou L’e-mail est invalide à Ce champ est invalide. Vous pouvez également mettre ces champs en valeur d’un coup de CSS, par exemple en les entourant en rouge.

Pire encore : ne pas vérifier les erreurs avant de tenter d’enregistrer les données.

6. Bloquer le parcours ou la validation d’un formulaire au clavier

Cela ne vous est jamais arrivé de vouloir parcourir un formulaire un peu long au clavier, et de vous rendre compte que la touche tab ou enter ne fonctionnaient plus ?

Les formulaires utilisent de plus en plus de Javascript, que ce soit pour vérifier la validité d’un champ, la disponibilité d’un identifiant, ou pour remonter des informations dans le cadre d’une auto complétion à la Google Suggest. Malheureusement, cela s’accompagne souvent d’un blocage des touches de navigation, et rend le parcours du formulaire pénible, voire impossible pour certains.

Si vous devez offrir à vos utilisateurs un formulaire un peu complexe, et notamment un formulaire sur deux colonnes, pensez à utiliser l’attribut tabindex, qui vous permettra de guider le parcours au clavier.

Pire encore : utiliser des tabindex fantaisistes qui vous font parcourir le formulaire de manière (quasi) aléatoire.

7. Barrer les liens déjà visités

Barrer les liens déjà visités a connu une certaine mode en 2003 ou 2004. Une certaine logique voulait qu’on indique de cette manière que, le lien visité, il n’y avait plus besoin d’y retourner. Évidemment, c’était une connerie, et évidemment, elle a fini par céder aux coups de boutoirs du bon sens une fois n’est pas coutume : le texte des liens devenait carrément illisible. Certains levaient la sanction quand l’utilisateur passait la souris au dessus du lien, mais cela ne facilitait pas vraiment le confort de lecture.

Par défaut, les navigateurs identifient les liens déjà visités d’une couleur plus sombre que les liens standards : violet foncé et bleu. Choisissez de préférence une teinte plus sombre de vos liens non visités afin de suivre ce comportement par défaut familier aux (vieux) utilisateurs.

Pire encore : ne pas différencier liens et contenu.

8. Déclencher les médias au chargement

La mode des blogs, et la prise de possession du web par des non spécialistes a entraîné le retour d’un fléau que l’on croyait éteint depuis longtemps : le lancement d’une musique ou d’une vidéo au chargement de la page.

Cela risque de gêner votre visiteur qui écoute déjà probablement de la musique, ou se trouve dans un espace ouvert.

Pour peu que vous proposiez d’autres médias, votre visiteur devra trouver comment couper votre musique d’ambiance avant d’accéder à l’information qui l’intéresse.

Tout chargement d’une nouvelle page réinitialisera la musique, même quand l’utilisateur l’a coupée la page précédente.

Quand à moi, j’avoue sans honte l’avoir fait une fois avec un MP3 du si poétique ANPE – Va niquer ta mère ça lui fera un client de plus, mais c’était pour emmerder les gens qui bossaient en open space sans couper le son. Que voulez-vous, on n’a pas toujours 20 ans…

Publié le 22 juillet 2009 à 09h10 Publié sous Ergonomie web et logicielle

Mots clés web, utilisabilité, html, liste, javascript, ui, interface

Si cet article vous a plu, n'hésitez pas à me suivre sur Twitter.

12 commentaires sur 8 erreurs d'ergonomie évitables qui vous pourrissent un site web »

Par Valéry le 22 juillet 2009 à 06h34 :

“Utiliser des alert() pour afficher erreurs, messages de service et demandes de confirmations”

Il m’a fallu plusieurs années pour enlever ce réflexe aux développeurs avec lesquels je travaille. L’usage de la fenêtre modale est désormais généralisé heureusement.

J’espère que d’ici quelques années le captcha aura subit le même sort que les liens barrés…
Par Nicolas F. le 22 juillet 2009 à 07h56 :

Une piqure de rappel fait toujours du bien. D’ailleurs, je dois trouver le temps d’indiquer les champs requis avec une astérisque plutôt qu’un effet visuel.

Je twitte l’article ;)
Par toupil le 22 juillet 2009 à 08h15 :

Très bon article. Les 8 erreurs ne sont en général pas difficiles à corriger, mais cela prend beaucoup de temps :s

Les liens barrés ?!! personnellement, je n’ai jamais rencontré çà.
Par NiKo le 22 juillet 2009 à 08h38 :

Que du bon sens, effectivement.

Un petit lien assez complet au passage : http://www.userfocus.co.uk/resources/guidelines.html
Par Thomas le 22 juillet 2009 à 09h53 :

Sur un long formulaire avec des champs en majorité obligatoire je préfère dans ce cas indiquer quels sont ceux facultatifs pour ne pas l’alourdir. Par exemple en rajoutant (facultatif) à côté du libellé.
Par Mère Teresa le 22 juillet 2009 à 10h22 :

Petite remarque : je vois pas le rapport entre les liens barrés et les formulaires. Sinon, bonnes remarques.

Cela me rappelle quelque chose de pas tout neuf : http://www.fredcavazza.net/files/doc/tutoriels/formulaire/SVF_intro.htm
Par Olivier G. le 22 juillet 2009 à 10h31 :

“Vous pouvez indiquer en bas de votre formulaire que la présence de l’astérisque indique un champ obligatoire” : depuis récemment, je met cet astérisque dans un balise abbr avec un title=”champ obligatoire”.
Par Jean-Sébastien Mansart le 22 juillet 2009 à 11h11 :

Pour les label, il me semble aussi que tu peux faire en sorte que la balise engloble la balise input et t’affranchir du for=”“.

Par contre, je ne sais pas quelle écriture est préconisée…
Par Mère Teresa le 23 juillet 2009 à 15h51 :

Thomas > Tu indiques bien que TOUS les champs sont obligatoires, en ce cas ?
Par Thomas le 26 juillet 2009 à 17h15 :

Je ne suis pas sur de bien comprendre. Si ils sont TOUS obligatoires, oui je l’indique au début.

Si il y a un mélange de champs facultatifs/obligatoires j’indique la minorité : -soit directement dans le libellé pour les champs facultatifs -soit avec une étoile qui renvoit à une explication pour les champs obligatoires
Par raph le 30 juillet 2009 à 19h44 :

Ya aussi les sites de e-commerce qui demandent le numéro de carte bleue avant d’afficher le total à payer.
Par Annabel le 09 février 2010 à 12h55 :

Bonjour, La fin du billet m’a bien fait rigoler :). Plus sérieusement, je vous invite à compléter ces piqures de rappel par l’excellente compilation des bonnes pratiques en matière de formulaire. L’auteur Luke Wroblewski a réalisé un travail remarquable de précision sur les différents problèmes ergonomiques des formulaires et les solutions : http://www.lukew.com/ff/entry.asp?602. La compilation date de 2007 mais cela reste très d’actualité. Bonne journée ! Annabel