Place de l'ergonomie dans un projet web

Publié le 5 août 2011

Tags : Ergonomie Gestion de projet Technique

Monique Brunel en partageant l’article “Ergonomie, pourquoi est-ce si difficile ?” a lancé une discussion sur l’ergonomie. Mon commentaire s’étoffant, je le publie ici pour lui donner plus de visibilité.

Ergonomie et aspect visuel

L’ergonomie est souvent confondue avec l’aspect graphique, car nos émotions affectent notre raisonnement. Nous préférons utiliser un bel objet/outil/site car l’expérience vécue sera plus appréciée. Voir à ce sujet Ergonomie et beauté des choses sur Ergolab. En pratique, un beau site est vu comme ergonomique, même si ce n’est pas le cas. Un site ergonomique mais dont la charte graphique déplait paraîtra en revanche moins pratique.

Il faut donc (ce ne devrait pas être une surprise) soigner à la fois l’ergonomie et l’aspect visuel. D’expérience, donner aux créas des indications liées à l’ergonomie du site les aide dans leur travail. Correctement informés de l’importance conceptuelle des différents informations et fonctionnalités, ils n’ont plus qu’à retranscrire cette importance à l’aide de leur vocabulaire : couleurs, contrastes, typographie

Le rôle des développeurs

On tape souvent sur les développeurs en termes d’ergonomie, mais ce n’est jamais méchanceté ou malveillance de leur part je pense. De plus, ils sont loin d’être les seuls responsables. L’influence négative qu’ils peuvent avoir vient de leur culture, de leur place dans le projet, et du manque d’information.

La culture machine

Les développeurs ont souvent atterri dans cette profession à cause de leur intérêt pour les nouvelles technologies et les jeux vidéos. Ils aiment connaître le fonctionnement des choses, ont souvent démonté des objets étant jeunes (posez-leur la question, vous verrez…), et savent optimiser un traitement en fonction du matériel. C’est leur métier !

Oui, mais… Quand on ne leur indique pas le modèle conceptuel souhaité, ils utilisent le seul qu’ils connaissent : le modèle objet, que ce soit celui des classes ou celui de la base de données. Voilà pourquoi certaines applications de gestion demandent un identifiant numérique à 15 chiffres pour pouvoir ouvrir un dossier, pourquoi la colonne de tri d’une liste de données sera l’identifiant en base, etc.

Place dans le projet et manque d’information

Les développeurs ne sont souvent sollicités qu’au moment de construire le site ou l’application finale, parfois un peu avant pour valider la faisabilité du projet. Il est parfois trop tard pour qu’ils puissent soulever une impossibilité technique, ou proposer une amélioration du processus, et c’est bien dommage.

Il leur manque donc l’historique et le recul pour mieux connaître les fonctionnalités indispensables, et les modalités de mise en place. Ils ont le “quoi”, mais pas le “pourquoi”. Or développer nécessite de prendre un grand nombre de décisions intermédiaires, souvent non détaillées ou trop vaguement décrites dans le cahier des charges. Quelques exemples : le nombre de résultats par page de recherche, la colonne de tri principale dans un tableau, doit-on répéter la pagination en bas de page, etc.

Il est donc obligatoire de les informer des enjeux du projet et des raisons de chaque choix ergonomique, et leur fournir les moyens de faire les bons choix.

Conclusion

Pour que les choix graphiques et techniques soient respectueux des choix ergonomiques, le mieux reste donc d’informer les acteurs de ce qui a motivé chacun de ces choix.

Néanmoins je pense que l’ergonomie souffre d’un manque de visibilité. Compter le nombre de clics ou le temps pour réaliser une action reste encore trop peu utilisé, sans parler des tests utilisateurs. Et pourtant, le succès de l’iPod et de sites comme Amazon ne sont plus à démontrer, et un site comme ABTests.com atteste qu’il suffit parfois de changer un mot ou la position d’un bouton pour doubler les bénéfices.

4 commentaires

Marco le 15 août 2011

Bonjour,

Post intéressant. Je dois avouer que je suis assez néophyte en terme d'ergonomie, mais de prime abord j'ai plus l'impression que ce doit être des choix réalisés en amont du design, et donc qu'a priori au niveau du développement tout est déjà pris en compte (dans le monde idéal bien sur). Disons que dans mon esprit, avant qu'un site soit développé, il faudrait qu'un ergonome, un DA et un référenceur soit passé dessus, et le développeur réalise le résultat de toutes ces contraintes. Après tout, chacun son métier, non ?

Je dois avouer que dans mon esprit l'ergonomie touche surtout au graphisme, tu as des exemples concrets de choix technique qui impactent les choix ergonomiques ? (à moins que tu ne places le temps de réponse d'un site comme élément de son ergonomie ?)

Florian d'Appili le 15 août 2011

Idéalement les développeurs doivent être le plus possible en communication avec le client pour améliorer leurs compréhensions business d'un projet, c'est d'ailleurs un des points principaux du succès de la méthode Agile. Sinon il est aussi conseillé que les développeurs (et l'équipe dans son ensemble) observent les scéances de tests utilisateurs.

@ Marco: tu peux aller sur cet article parlant de design et d'ergonomie : http://www.appili.com/blog/2011/08/...

Goulven le 31 août 2011

@Marco En effet, l'ergonomie reste le travail de l'ergonome. Mais il est important que les intervenants aient, en plus des indications "normatives", une justification de chaque indication. Par exemple, si l'ergonome dit que l'ajout au panier doit se faire sans quitter la page, il faut expliquer que c'est pour éviter que les visiteurs perdent le fil de leurs achats et mettent plus de choses dans leur panier.

Anecdote : quand les développeurs du site Amazon ont conçu l'achat en 1 clic... Il en fallait 2 pour acheter un objet ! Il y avait sûrement une raison technique à leur "interprétation" du cahier des charges, mais si on leur avait expliqué que le retour sur investissement dépassait largement le temps de développement, ils auraient sûrement mieux respecté la demande.

@Florian Tout-à-fait ! Et l'article en lien est intéressant, merci de l'avoir partagé.

Marco le 5 septembre 2011

@Goulven : Effectivement, après tout la vrai question est je pense, est-ce possible pour chaque projet de respecter l'ensemble du cahier des charges (si déjà cahier des charges il y a !) Et sinon, tout est effectivement question de communication et compromis. Mais bon l'anecdote Amazon est flagrante, c'est sur que dans ce cas je veux bien croire que de petits détails font toutes la différence !

@Florian : Merci pour le site, intéressant en effet !

Page précédente Page précédente Page suivante Page suivante