L’ergonomie, vous y pensez souvent… avant?
… et pendant le développement? Ou seulement après?
Il est un point que je désirais aborder depuis longtemps sur ce blog: la place que l’on veut bien donner à l’ergonomie au sein des projets informatiques actuels et surtout le bien fondé de l’intégration de la notion d’ergonomie dans des équipes de développements agiles. Par ergonomie, je veux parler de l’expérience que l’utilisateur aura lors de ses interactions avec le logiciel. Il s’agit là d’un facteur de qualité trop souvent sous-estimé et qui, pourtant, influencera grandement le ressenti de l’utilisateur.
Combien de fois des projets se sont vu commencer à développer la première version utilisable du logiciel sans avoir simulé son utilisation avec des utilisateurs. Pourtant, beaucoup gagneraient à “faire un brouillon” de ces interactions en amont avec des utilisateurs, peu importe la méthode de réalisation: maquettes logicielles ou bricolages faits de papier, de trombones, de coups de crayons et d’attaches parisiennes. C’est d’ailleurs cette dernière méthode qui, de mon point de vue, a le meilleur ratio coût/efficacité et se trouve pourtant la plus évitée parce que “pas assez hype” ou, je cite, “ridicule”.
Durant mon expérience, j’ai pu constater que l’ergonomie, quant elle avait été citée, avait souvent été vue comme un “mieux” à la priorité très faible… puis les mois passant, certains projets, s’ils arrivaient à atteindre leurs objectifs fonctionnels, se trouvaient affublés d’une mauvaise réputation auprès des utilisateurs. Ceux-ci trouvant l’usage du logiciel trop difficile, tortueux, illogique: bref, ce qu’on appelle une mauvaise expérience.
Après avoir lu, entre autres, des publications de Bill Buxton, Dan Saffer, Bill Moogridge ou Jon Maeda ces dernières années, après avoir soulevé la question à l’Agile Open France 08 et en discutant de tout ceci avec des chercheurs de l’Université de Genève spécialistes en ergonomie, je prêche désormais pour l’intérêt d’intégrer dans des équipes de développement agiles la notion d’ergonomie, tant les deux mondes accordent l’importance qu’il se doit à l’avis de l’utilisateur. Sous la forme de l’intégration d’un profil d’ergonome ou d’une équipe sensibilisée à l’ergonomie, selon le contexte. Une chose est sûre: si l’on y gagne à itérer de manière incrémentale sur les fonctionnalités avec un utilisateur disponible, on y gagne tout autant à itérer sur l’ergonomie avec lui durant ces phases.
Devant la complexité des applications d’aujourd’hui, le besoin de donner à l’utilisateur l’occasion d’aller à l’essentiel est encore plus nécessaire et je me rassure en voyant ces réflexions de plus en plus présentes sur les blogs s’intéressant à l’agilité ou/et au designing d’intéractions…
Ajout de dernière minute: chose amusante, une illustration toute récente de ceci, certes concernant le grand public mais tout aussi valable pour l’informatique d’entreprise, m’a été indiquée, alors que je rédigeais ce texte, par un collègue me parlant d’ un post sur l’application Things, une application iPhone au succès dépassant les espérances de ses créateurs, l’ergonomie y étant pour quelque chose. Sur le post cité, les images de sketchs réalisés au crayon correspondent à ce qui a été cité plus haut. Alors, à vos crayons!…

http://stuffthathappens.com/blog/2008/03/05/simplicity/
Pour la petite histoire et les fans d’Alien le film de 1979, les studios Century Fox ont doublé le budget du film en voyant les storyboards de Ridley Scott. D’où l’importance des supports visuels en avance du projet !
@Andrew: uhu, le lien que j’ai posté suite à l’annonce de Scrinch.
Fail early, fail often. Intégrez le design, ergonomie, interaction, … l’utilisateur … dès que possible. et refactorez. Un point simple est d’en faire moins, moins et encore moins. La perfection est atteinte quand on ne peut plus rien enlever et non plus rien ajouter.
Les deux processes peuvent vivre en parallèle, l’implémentation et le design et se challenger mutuellement, plutôt que se brider mutuellement (chose que j’ai trop souvent vu). impossible n’est pas français, dit-on. À savoir s’il faut mettre un f minuscule ou majuscule à français
Cordialement,
Héhé
Ceci dit, une question reste: faut-il systématiquement écouter les utilisateurs et leur adapter le soft ou faire des choix drastiques qui semblent de prime abord excessifs voir limitatifs, mais qui sont les bons au final (exemple avec Apple)?
Par expérience, certains utilisateurs vont faire des choix, disons, carrément bizarres. Ce d’autant plus qu’ils n’accèpteraient pas ce genre de modifications où façon de travailler dans des logiciels connus tels que Word, Excel ou encore Outlook. Je parle d’une expérience récemment vécue (Jérôme tu n’as pas le droit de rire). Autre difficulté majeure, arriver à “synthétiser” le feedback de plusieurs utilisateurs pour produire une solution unique qui doit satisfaire tout le monde. Bonjour le défi et ce d’autant plus s’il n’y pas une personne qui tranche au final pour ne pas dire fait fermer la g… des autres. Bon OK Steve Jobs peu paraître excessif à ce niveau, mais lui à un certain don de clairvoyance que peu de gens possèdent.
@Jean-Marc
“To discover which designs work best, watch users as they attempt to perform tasks with the user interface. This method is so simple that many people overlook it, assuming that there must be something more to usability testing. Of course, there are many ways to watch and many tricks to running an optimal user test or field study. But ultimately, the way to get user data boils down to the basic rules of usability:
* Watch what people actually do.
* Do not believe what people say they do.
* Definitely don’t believe what people predict they may do in the future.”
– First Rule of Usability? Don’t Listen to Users, http://www.useit.com/alertbox/20010805.html
Encore un lien sur les mockups:
http://alistapart.com/articles/paperprototyping