L’expérience utilisateur et l’ergonomie des sites web

Pour faire bonne impression sur les visiteurs, il suffit d’anticiper leurs besoins. Dans ce domaine, ce sont souvent les détails qui comptent le plus. Améliorer l’expérience utilisateur et adapter les fonctionnalités d’un site web en fonction des attentes de chacun permet de satisfaire : ceux qui veulent consulter un site web ergonomique offrant un contenu facilement accessible ; ceux qui veulent un design attractif ; et enfin, ceux qui veulent le grand jeu avec Ajax à tous les étages. Ce billet est ma traduction du dernier article d’Aaron Gustafson Ruining the user experience paru sur A List Apart le 27 mars dernier.

Ruiner l’expérience utilisateur

Pendant un récent voyage d’affaire à Seattle, j’ai passé deux soirées à déguster la cuisine locale. Je me suis régalé à chaque repas, mais je garde de l’un deux un souvenir bien plus marqué. Mais pourquoi ?

Les deux restaurants présentaient de nombreux points communs : les plats étaient alléchants et présentés avec goût ; l’atmosphère était sympathique et chaleureuse ; les menus offraient un large choix de plats tout deux à un prix raisonnable, et le personnel était aux petits soins. Alors qu’est-ce qui fait que le second restaurant m’a laissé un bien meilleur souvenir que le premier ?

Comme souvent dans la vie, ce sont les détails qui comptent le plus. Prenez un verre d’eau, par exemple. Un serveur négligent peut le servir glacé, ou pire encore, vous laisser mourir de soif avant de vous resservir. Alors qu’un serveur bienveillant s’assurera que le niveau de l’eau ne descendra jamais plus bas que la moitié du verre ; les meilleurs vous feront la surprise de trouver le verre que vous venez de finir, rempli à ras bord une nouvelle fois.

Pour nous les ergonomes du web, Il y a beaucoup à apprendre d’une chose aussi simple qu’un verre d’eau.

Qui est le client ?

Quand vous êtes serveur dans un restaurant, vous savez que les gens viennent avec certains besoins et, parfois même, avec quelques attentes. Souvent, le verre d’eau est le « premier contact » avec le client. S’il est rempli rapidement, vous marquez un point, mais ce n’est que le début. En effet, certaines personnes boivent plus vite que d’autres et demandent à être resservies plus souvent. Certains clients ne boiront pas avant d’avoir les plats devant eux. D’autres encore ne toucheront pas à leur bouteille d’eau… ou demanderont peut-être un peu de thé glacé, ou encore autre chose. Au départ, vous ne pouvez vraiment pas savoir à qui vous avez à faire. Et lorsqu’il s’agit d’une table de 4, 6 ou même 10 personnes il vaut mieux s’être préparé à l’avance…

Sur le web, c’est la même chose. Nous faisons de beaux sites qui (nous l’espérons) font une excellente première impression, mais nous devons nous assurer que chaque point d’interactivité renforce cet avis favorable tout au long de la navigation, sinon nous risquons de dilapider le peu de crédit acquis au départ. Ce type de pensée à donné naissance au concept d’amélioration progressive

Sur le web, nous ne savons rien à propos de la personne qui vient visiter notre site. Nous ne connaissons pas le navigateur utilisé. Nous ignorons si le serveur est interrogé depuis un téléphone portable. Nous ne savons pas si le clavier est préféré à la souris. Nous ne savons pas si Javascript (ou même CSS) est activé. Nous ne savons pas si la page doit être imprimée. Nous ne savons pas si l’utilisateur consulte le site à l’aide d’un lecteur d’écran. Nous ne savons vraiment rien…

Alors, que fait-on quand on ne sait rien ? On an-ti-ci-pe.

En tant que développeurs, nous devons pouvoir satisfaire les besoins de nos clients. Et si nous sommes assez pointus, nous pouvons régler leurs problèmes sans qu’ils ne se rendent compte de notre intervention.

Une douche froide ?

Lala.com est un site bâti autour d’une communauté de gens qui aiment la musique. Le système facilite l’échange de CD dans toute la communauté par la poste.

Je ne dirais pas que leur site web est attractif, mais il est utilisable… sauf si Javascript est désactivé.

Vous apprécierez le fait qu’il y a un message indiquant un Chargement en cours alors que rien ne se charge.

Pour régler le problème (la copie d’écran ci-dessus a été prise entre le moment où j’ai commencé à me servir du site comme exemple de ce qu’il ne fallait pas faire et la finalisation de l’article), tout ce qu’ils ont été capable de faire, c’est de ressortir ce vieux message au parfum entêtant datant de la dernière guerre des navigateurs.

Le problème ici n’est pas que le site utilise Javascript, mais qu’il ne fonctionne pas sans. La raison ? Et bien, apparemment, les concepteurs se font plaisir en Ajax-isant tout le contenu. Dans leur précipitation, ils ont entassés tous les trucs du web 2.0 sous le capot et se sont aliénés une bonne partie des utilisateurs du web 1.0, et une part importante du marché des appareils mobiles. Et ils ne sont pas les seuls.

Pensez à ceci : vous êtes un utilisateur de Lala.com, vous êtes proche d’un magasin de disque et vous vous arrêtez sur l’album des Fatals Picards [« Arcade Fire » dans la version originale, NdT]. Vous n’avez pas réalisé qu’il était sorti et voulez l’ajouter à votre liste de souhaits avant de l’oublier. Si votre téléphone mobile ne supporte pas Javascript (ou si vous l’avez désactivé pour réduire le temps/coût de chargement), vous allez vous retrouver devant un écran qui vous donne des informations pertinentes sur Lala, suivies malheureusement du message indiquant que Javascript est nécessaire pour utiliser le site.

Vous ne pouvez pas accéder à votre liste de souhaits ou à quoi que ça soit d’autre, d’ailleurs. Même le champs de recherche (en bas de la page) ne fonctionne pas. Pour une application de type intranet, cela peut être acceptable, mais pour un site web grand public, c’est un désastre.

Réfléchissez avant de servir

Nous avons déjà établi qu’en tant que développeur web nous sommes généralement dans le brouillard quant aux desiderata de nos utilisateurs. Le mieux que nous puissions faire est d’anticiper ce que pourrait être leurs besoins et s’assurer qu’ils sont pris en compte à tout les niveaux pour apporter la meilleure expérience possible. C’est là que l’amélioration progressive entre en scène. Nous devons penser aux besoins des différents types d’utilisateurs et leur apporter une réponse.

1. Niveau 1 : pas de fioriture

   Certains utilisateurs veulent seulement accéder au contenu. Ils peuvent surfer depuis un appareil mobile, chercher à imprimer quelques informations, ou utiliser toutes sortes de périphériques d’assistance pour naviguer. Ils peuvent même avoir désactivé l’affichage des images. En gardant un marquage propre et bien-ordonné et en respectant la sémantique associée aux balises HTML, vous répondrez aux besoins de ces utilisateurs qui veulent consommer léger et afficher les pages rapidement, sans chichi.

2. Niveau 2 : faites joli

   D’autres, aiment les belles vitrines (ou une tranche de citron). Pour eux, concevez un design graphique visuellement attractif. Vous pouvez même ajouter quelques fioritures visuelles (ou un peu de Flash) et ils seront contents. Aussi longtemps qu’il n’y a pas de confusion entre les éléments de décoration et le contenu de la page, que vous avez réalisé tout vos tests sur les navigateurs (ou que vous fournissez quelques styles basiques pour les médias alternatifs), ça devrait le faire.

3. Niveau 3 : c’est la fête !

   D’autres encore, veulent le grand jeu. Pour ceux-là, vous pouvez faire sauter le bouchon et créer une merveilleuse application web 2.0 avec fondu-enchainé, widget en veux-tu en-voilà, et Ajax en abondance.

   Gardez toutefois à l’esprit, que ces niveaux ne sont pas toujours aussi clairement identifiables. Un palier intermédiaire entre les niveaux 1 et 2 sera peut-être nécessaire pour donner à Netscape 4.x et IE5/Mac quelques styles typographiques spécifiques. Ou vous pouvez avoir envie d’offrir des raffinements Javascript selon les navigateurs, ou encore injecter un peu de crème au nougat entre les niveaux 2 et 3…

Passer inaperçu

Une fois que vous avez décidé des niveaux à prendre en compte, vous pouvez construire votre site.

Commencez par le contenu. Quelquefois, les webdesigners et les développeurs oublient que les gens viennent surtout pour ça. Travaillez-le avec amour sans noyer vos visiteurs sous les informations. N’empilez pas les blocs comme pour un buffet. La production du contenu demande toujours beaucoup de travail. Mettez-le en valeur.

Lorsque le contenu est balisé, il est temps d’établir le look and feel du site. Concevez un design adapté à vos utilisateurs en utilisant pour chaque niveau les différentes techniques à votre disposition : cachez certains fichiers CSS aux navigateurs les plus anciens et donnez des styles spécifiques à ceux qui demandent un peu plus d’attention. Les commentaires conditionnels sont réellement vos amis pour la vie en la matière. Mais n’oubliez pas les vieilles recettes comme les règles @import et les combinaisons pour les médias spécifiques qui permettent d’offrir sélectivement un parfum différent pour les navigateurs collés au radiateur du fond de la classe.

Vérifiez la présentation de votre contenu à l’impression et son affichage sur les périphériques mobiles. A ce propos, envisagez-vous une mise en pages spécifique ou seulement un traitement basique en terme de couleur ou de typographie ? Quel sort réservez-vous aux images et aux formulaires ? Essayez d’anticiper les fonctionnalités qu’un utilisateur mobile voudrait, et ôtez le superflu ! Si vous utilisez la pseudo-classe :hover sur un lien, n’oubliez pas de considérer également la pseudo-classe :focus, et les utilisateurs de claviers ou d’appareils mobiles vous remercieront.

Lorsque le design est validé, ajoutez quelques étincelles avec une pincée de Javascript non-intrusif. Vous connaissez déjà les méthodes de détection pour savoir si un script peut fonctionner sur tel navigateur ? Considérez aussi comment vos scripts peuvent interférer avec les interactions communes aux navigateurs telles que « bookmarker » un lien ou utiliser le bouton retour. Et n’oubliez pas l’interdépendance qui peut exister entre des scripts différents : votre site deviendrait-il inutilisable si un script fonctionnait et pas un autre ?

Si vous créez un widget ou autre interface de contrôle, générez le marquage additionnel quand avez déterminé qu’il est prêt à être utilisé, et que tout le reste fonctionne encore. Et si vous séparez les CSS liées à votre widget de votre code Javascript comme un bon petit soldat des standards, assurez-vous que les styles ne sont pas actifs tant que le script n’a pas indiqué que le widget peut être utilisé. Une bonne pratique est d’utiliser l’échange de classe (cf. Table 1) :

Au final, si vous envisagez d’utiliser Ajax, faites-le avec discernement : il n’est pas nécessaire de charger l’ensemble de la page via des appels asynchrones qui finissent par devenir une barrière entre l’utilisateur et votre contenu. Paradoxalement, cela peut entraîner une augmentation de la charge serveur, rendre votre contenu invisible pour les moteurs de recherche, et rendre votre site inutilisable pour quiconque utilise un lecteur d’écran ou un mobile.

Ne me faites pas dire ce que je n’ai pas dit, Ajax a sa place, mais il est important de savoir laquelle, et plus encore, de savoir où elle n’est pas.

Conclusion

Anticipez les besoins de l’utilisateur avec précaution et occupez-vous d’eux en vous faisant remarquer le moins possible. C’est la clé pour laisser une première bonne impression. Comme avec un verre d’eau, vos utilisateurs ne devraient jamais avoir à réclamer pour être servi.

Crédits et remerciements

Traduit avec la permission de A List Apart Magazine et de l’auteur.

Malgré tout le soin apporté à cette traduction, il est possible que des erreurs préjudiciables à la pensée de l’auteur se soient glissées : je vous conseille vivement de lire l’article original. Profitez-en pour me signalez les erreurs ou les contresens, ou tout simplement les améliorations que vous jugez utiles pour coller au plus près de l’article. D’ailleurs, ce billet reste en version bêta quelques temps 😉

Merci à Véro pour son coup de main quand j’étais « Lost in translation » 😉

Note du 24/05/07 : Merci à Goulven pour sa relecture et les améliorations qu’il a apportées à cette traduction.

PS : d’autres traductions d’articles sur les sujets du web sont disponibles dans la catégorie Traductions.