J’ai eu l’occasion d’effectuer l’autre jour un rapide audit d’utilisabilité sur une application web développée par un ami. Il s’agissait pour moi de mettre en avant ses principaux défauts, afin de pouvoir les corriger avant la sortie d’une prochaine alpha.

J’aime bien cet exercice, même si je le trouve frustrant. S’il permet d’améliorer les points les plus visibles, il ne va cependant pas au fond des choses, laissant souvent de côté les problèmes les plus importants.

Après quelques clics exploratoires et 2 ou 3 remarques d’intérêt général, je lui faisais remarquer le grand nombre de bulles et de messages d’aide disséminés dans l’application. Bien que graphiquement discrets, on trouvait cependant apposés de manière systématique près de chaque fonctionnalité importante. Mon ami était assez fier de ce système, lequel devait permettre – disait-il – à n’importe quel imbécile d’utiliser son projet sans aucun problème. Outre le nombre impressionnant d’aides, ces dernières avaient été rédigées par un cabinet spécialisé pour être les plus claires possibles. Il a assez rapidement compris le problème. Si vous devez placer des bulles et des messages d’aide un peu partout dans votre application, c’est qu’elle est trop complexe, trop obscure, mal conçue ou probablement les trois à la fois. Notre rapide passe ergonomique autour d’une bière allait se transformer en une nuit blanche de travail.

Si vous vous heurtez un jour à ce type de problèmes, vous relèverez probablement trois types de problèmes :

• Des problèmes de nomenclature.
• Des problèmes liés à l’interface elle-même.
• Des problèmes liés aux fonctionnalités proposées.
• Ce qui se conçoit bien s’énonce clairement et les mots pour le dire viennent aisément, Boileau

Pour commencer, soyez certain d’utiliser une nomenclature unifiée. Tous les items d’un type doivent être désignés par le même mot tout au long de l’application. Il m’est ainsi arrivé de voir employé les mots rayons sur la partie front d’un site de e-commerce, et catégories dans le back office des utilisateurs.

Soyez simples, et allez au plus direct. J’aime beaucoup l’exemple donné par Steve Krug dans Don’t make me think à propos des sites d’offre d’emplois, où il comparait 3 nomenclatures différentes pour désigner une même page :

• Offres d’emploi.
• Offres de recrutement en ligne.
• Job-o-rama

Enfin, employez des verbes d’action quand cela est possible pour désigner les liens correspondants : télécharger au lieu de téléchargement, s’abonner au lieu d’abonnement. En plus d’indiquer clairement une action, ils ont une valeur incitative non négligeable.

Si vous avez besoin d’expliquer comment fonctionne votre interface, c’est que vous l’avez probablement mal pensée. J’ai eu un jour ce soucis avec l’interface de saisie des billets de Typo, le blogware open source dont je m’occupe sur mon temps libre. Elle permettait de faire plein de choses très utiles, mais elle était très difficilement utilisable sans un doctorat en recherche d’aiguille dans une meule de foin.

Outre la nomenclature, les options et le fonctionnement proposés sont particulièrement importants. J’aime particulièrement le formulaire de recherche d’Amazon, dont le modèle a été repris un peu partout.

Il est arrivé à un moment où le formulaire de recherche standard vous demandait de chercher non seulement dans une section donnée du site, mais également sur des champs précis des articles : auteur, titre ou description. Le formulaire d’Amazon simplifiait cela en classant les tris par ordre de pertinence au lieu d’exiger des utilisateurs qu’ils le fassent eux-même.

L’application sur laquelle nous travaillions n’avait pas de gros problèmes de zoning général. Elle présentait en revanche des soucis de cohérence localisés. L’ordre dans lequel les champs apparaissent dans un formulaire est particulièrement important. Non seulement pour un soucis de cohérence, mais également de reproduction de ce qui est familier ailleurs.

Enfin, ne négligez pas l’iconographie, elle joue un rôle déterminant dans la compréhension de votre application. S’il est bon d’innover, il faut cependant respecter les codes en vigueur.

Google spreadsheet est une application web que nous pourrons qualifier de complexe, et pas seulement du point de vue de Madame Michu. Sa toolbar se suffit pourtant à elle-même, grâce à l’emploi d’une iconographie simple et familière, et à une utilisation adéquate des attributs alt.

Toutes les fonctionnalités proposées par défaut à vos utilisateurs sont-elles nécessaires ? À force de vouloir en faire trop, on a tendance, et ce sera mon dernier point, à vouloir charger la mule fonctionnelle histoire de proposer plus que les autres.

Il faut bien différencier trois types de fonctionnalités :

• Les fonctionnalités indispensables ou nécessaires au fonctionnement et à l’utilisation de l’application.
• Les fonctionnalités superflues, parfois gadget, utilisables par tout un chacun et dont l’une d’elle devient souvent la killer feature de votre application au point, paradoxalement de devenir idispensable. Exemple : les réactions client sur Amazon.
• Les fonctionnalités avancées, généralement complexes – voire impossibles – à utiliser, réservées à moins d’1% de vos utilisateurs. Exemple : le formulaire de recherche avancée de Google.

La mise en avant de chacune de ces fonctionnalités dépendra évidemment des besoins de vos utilisateurs. Cependant, pesez leur poids réel dans l’utilisation de votre outil par rapport à la place que vous leur donnez. Mettre des statistiques particulièrement avancées directement sur le tableau de bord de vos utilisateurs en ravira certainement quelques-uns, mais risque de faire fuir la grande majorité d’entre eux qui se diront tout simplement “cette application n’est pas pour moi”.

Je ne suis pas contre la mise en place de systèmes d’aide, que ce soit sous forme de messages d’accompagnement, de bulles d’aide ou de liens vers un glossaire. Cependant, une trop grande prolifération est toujours suspecte à mes yeux, et cache souvent un vrai problème structurel, preuve que l’utilisabilité doit être prise en compte dès la conception.

Article original écrit par Frédéric de Villamil et publié sur Ergonomie, Rails et Architecture de l'information web | Lien direct vers l'article | Si vous lisez cet article dans son intégralité sur un autre site que Ergonomie, Rails et Architecture de l'information web c'est qu'il a été reproduit illégalement et sans autorisation. Merci de le signaler à son auteur original en cliquant ici | © t37.net 2008.