Comprendre vos utilisateurs, c'est comprendre comment ils utilisent votre application
Il y a quelques mois, j’entendais un administrateur système me dire : de toutes manières, je vais brider telle possibilité, car je ne veux pas que les utilisateurs se servent de l’application comme de …
. Outre le fait que c’est le genre de phrase typique de quelqu’un qui est déconnecté de la réalité métier, et donc de ses pratiques, elle implique quelque chose d’assez fondamental : vous avez beau concevoir votre application avec une certaine idée de la manière dont elle sera utilisée, l’important est finalement la manière dont vos utilisateurs finaux s’en servent.
Je suis évidemment pour mener des tests d’utilisabilité en amont de la mise en production d’un site, ou d’une application web. Rassembler des utilisateurs types pour autant que ce termes veuille dire quelque chose permet de s’assurer que l’on n’a pas commit de grosses boulettes. Cela permet également, et c’est plus important que le nombre de clics, de valider la facilité avec laquelle l’utilisateur pourra accomplir l’acte d’achat sur un site de e-commerce.
Pour une application web destinées à un seul client, les choses se compliquent un peu, principalement pour des raisons de mise en oeuvre. Les tests utilisateurs effectués à la fin des développements souffrent généralement de deux problèmes :
<li>Les budgets, quand ils existent, ne permettent pas de tester sur un panel suffisamment étendu d'utilisateurs, particulièrement pour une application touchant de multiples services, voir de multiples pays.</li>
<li>Afin de ne pas <q>déranger les collaborateurs dans leur travail</q> ou <q>ne pas risquer de retarder les travaux en cours</q>, les testeurs sont généralement des membres de l'équipe projet, qui en ont assuré la conception, éventuellement la recette, et dont la relation à l'application est, par conséquent, biaisée.</li>
Il devient dès lors franchement impossibles de tester proprement en amont une application web destinée à de multiples clients, tant les modes d’utilisation dépendront du contexte d’entreprise et des spécificités métier des utilisateurs. Il devient en revanche intéressant d’effectuer les tests et de récupérer des retours d’expérience après une période relativement longue d’utilisation, de quelques mois à un an, afin de rassembler des informations sur :
L’utilisation faite de votre application, et le delta avec ce que vous aviez initialement prévu en conception. L’analyse de cette première collecte se fera évidemment en fonction du milieu professionnel des utilisateurs, et notamment de leurs spécifitiés métier. Comparer l’usage fait de votre produit dans deux banques différentes à un sens ; comparer ce que font un banquier et un directeur marketing en agence de communication virale en aura beaucoup moins. Et même à poste égal, la culture interne à l’entreprise peut jouer de manière beaucoup plus forte que l’on peut s’y attendre. La limitation des fonctionnalités par les administrateurs également, mais j’y reviendrai dans un très prochain article.
Les grandes tendances d’utilisation communes à l’ensemble des clients, et particulièrement celles que vous n’aviez pas prévues initialement. Cette étude est particulièrement intéressante avant une refonte de votre application, car elle permet d’identifier des besoins dont la satisfaction a nécessité un détournement des objectifs originaux de l’application.
Les tests en aval du déploiement, auprès d’un panel d’utilisateurs varié, nombreux, et particulièrement après une longue période d’utilisation, relève bien trop souvent du rêve théorique. Cela coûte du temps, de l’argent, des ressources que les clients ne sont généralement pas prêts à mettre en oeuvre, et surtout, cela leur fait livrer des informations sur leurs méthodes de travail. Il est pourtant très intéressant de voir le delta entre ce que vous aviez prévu que vos clients feraient de votre application et la manière dont ils l’utilisent vraiment, ne serait-ce que pour éviter de vous planter la prochaine fois. C’est cependant loin d’être toujours possible.
<typo:flickr img=”3155934386” size=”medium” alt=”Rockfeller Center New York City” />
Publié le 12 janvier 2009 à 21h52 Publié sous Ergonomie web et logicielle
Mots clés usages, utilisabilité, expérience, tests, application
Si cet article vous a plu, n'hésitez pas à me suivre sur Twitter.
2 commentaires sur Comprendre vos utilisateurs, c'est comprendre comment ils utilisent votre application »
-
Par Florian Le Goff le 13 janvier 2009 à 10h33 :
-
Par Frédéric de Villamil le 13 janvier 2009 à 23h29 :
Florian : oui et non.
Les stagiaires sont très bien sur le papier, car ils représentent une main d’oeuvre peu chère et éphémère donc non indispensable à la survie de l’entreprise.
Leur jeune âge, leur fraîcheur et leurs habitudes les placent cependant à des années lumières des utilisateurs types de l’application. Sans compter qu’il leur manque la culture de l’entreprise, laquelle est souvent pour beaucoup dans les méthodes de travail.
Trackbacks sur Comprendre vos utilisateurs, c'est comprendre comment ils utilisent votre application
Les trackbacks sont fermés pour cause de spam.
L'ergonomie web, l'utilisabilité et la qualité des logiciels sont trois grandes passions mises au services de ma profession.
Lors de mon arrivée en stage chez France Télécom R&D, à Lannion, les premiers papiers que l’on a eu sous les yeux nous avertissaient que nous pourrions être sollicités comme testeurs. Pour évaluer des algorithmes de compression video, audio, mais aussi l’ergonomie de certains services web.
Et j’ai trouvé que c’était une fort bonne idée. Plutôt que de faire appel à toujours le même panel de gens, pourquoi ne pas utiliser des regards frais, pas formatés par les outils existants, une force de travail silencieuse mais souvent plus créative que celle en place (et qui en plus se renouvelle organiquement tous les 6 mois ?).
Les stagiaires du client, dans ce cas là, sont une ressource assez intéressante. Ils sont facilement mobilisables, leur coût est minimal, et on peut en avoir de toutes les spécialités de l’entreprise. Si l’outil devra être utilisé par les comptables, alors c’est facile de trouver un stagiaire de compta. Si il sera utilisé par le marketing, c’est pareil. Et on peut en général trouver un stagiaire bac+3 à côté d’un stagiaire bac+5 donc toutes les couches de l’entreprise peuvent être facilement représentées.
Bon, après ça ne règle pas le problème qu’il faut toujours un prestataire pour encadrer les tests, la collecte des retours et leur analyse. Mais au moins, les retours coûtent moins cher.