L’expérience utilisateur ou ux (pour User eXperience) est prise en compte depuis plus de 10 ans aux USA. Des experts en ux sont employés par de grandes entreprises comme Google, mais aussi des startups du web et des agences de design ou communication. Pourtant, cette discipline peine à percer en France, où l’on considère encore un designer comme un simple décorateur.
UX, quésaco ?
Il est assez difficile de définir l’ux, qui est fortement trans-disciplinaire. Concrètement, l’expérience utilisateur tient compte aussi bien des aspects techniques (accessibilité, rapidité), ergonomiques (compréhension), statistiques (quels utilisateurs dans quels contextes) et émotionnels (l’image véhiculée) d’une application ou d’un site. Un professionnel de l’ux aura donc idéalement à la fois des compétences en design, en marketing et en programmation !
Pour créer une bonne expérience utilisateur, l’ux designer va procéder par itérations : collecter des idées, réaliser des prototypes, les tester auprès d’utilisateurs. Il s’agit non seulement de s’intéresser aux besoins de l’utilisateur, mais aussi de ne pas oublier ceux du business. Son rôle est également de donner à l’ensemble des parties prenantes (décideurs, équipe technique) le point de vue des utilisateurs, en ce sens l’ux est aussi un état d’esprit de centrage sur l’utilisateur.
OK, mais en quoi ça nous concerne, nous autres développeurs ?
Nous avons tous reconnu le fonctionnement de certains projets dans ce dessin.
Ce dessin fait rire, mais reflète une situation douloureuse, dans laquelle les développeurs font des heures supplémentaires à gogo et le client est mécontent. De nombreux projets n’aboutissent pas, c’est une perte d’argent mais aussi une source de frustration. Contrairement à une croyance répandue, les développeurs ne s’intéressent pas au code pour le code, ils aiment le produit qu’ils construisent et souhaitent le savoir utilisé. Personne n’apprécie de voir un projet qui plante ou qui ne sert à rien !
La pensée agile est un début de réponse à ce problème : privilégier les interactions, la collaboration et favoriser le changement permet de réaliser très rapidement que l’on part dans une mauvaise direction par rapport au besoin. Cependant, même si un projet agile est bien plus à même qu’un projet reposant sur un cycle en V de satisfaire le client en répondant à son besoin, il ne faut pas perdre de vue deux points :
- Le client n’est pas toujours l’utilisateur final, et il n’a pas toujours la culture qui le pousserait à chercher l’avis des utilisateurs ;
- Même le client utilisateur ne sait pas forcément très bien ce dont il a besoin, surtout s’il n’est pas à l’aise avec l’outil informatique, et dans ce cas, ce sont souvent les développeurs auprès de qui il va chercher conseil.
Pour reprendre la métaphore de la balançoire, un projet agile permettra la plupart du temps d’obtenir une balançoire simple, avec un budget inférieur à celui de la balançoire à trois niveaux demandée initialement, mais ne permettra pas d’atteindre le pneu qui est le besoin réel. Et si les utilisateurs finaux sont écartés du projet, ce qui peut arriver dans une structure hiérarchisée, on aura alors plutôt quelque chose qui se rapproche de la demande initiale, avec le risque non négligeable que les utilisateurs se plaignent et rechignent à utiliser le produit, quand bien même il est d’une qualité acceptable et conforme à la demande du client (souvent un supérieur hiérarchique des utilisateurs). Dans ce cas, on attribue l’échec relatif du projet à la résistance au changement des utilisateurs, alors qu’il faudrait également interroger le produit : est-il facile à utiliser ? Est-il agréable à utiliser ? Est-il rapide à prendre en main ? Améliore-t-il la productivité ?
Dans le pire des cas, il m’est arrivé d’entendre : «Cette fonctionnalité, on ne l’a jamais utilisée, on n’a pas réussi à comprendre comment elle marchait».
Le dessin ci-dessous n’est-il pas fidèle à la réalité des applications que nous développons pour le métier ? Et même parfois pour le web ?
Que pouvons-nous faire ?
Dans la plupart des projets, les développeurs ne sont pas de simples exécutants : il leur est souvent possible de faire des suggestions au client (même en dehors d’un cadre agile) et ils sont même parfois les rédacteurs des spécifications fonctionnelles, sans oublier que les rôles de Product Owner et d’amoa sont des évolutions possibles du métier de développeur ! Nous autres développeurs ne sommes donc pas toujours de simples spectateurs impuissants de ces conceptions de logiciels rebutants pour l’utilisateur. Et là où nous pouvons agir, comme nous voulons avant tout ne pas travailler pour rien, nous avons intérêt à prendre en compte l’ergonomie de ce que nous produisons.
Si nous voulons que notre produit plaise, que le client l’utilise, qu’il ne nous regarde pas avec des yeux remplis d’incompréhension à la fin de notre présentation, nous devrions nous intéresser à l’expérience utilisateur. C’est cet avis que je vous exposerai, ainsi que quelques bonnes pratiques, lors de ma conférence au DevFestL’expérience utilisateur est importante pour vous, à Nantes le 7 novembre prochain. C’est également un sujet du module de formation Introduction au webdesign proposé par Ippon Technologies.
Crédit photo:
https://www.flickr.com/photos/mordefroid/6049289722/
https://www.openhub.net/p/stuffthathappens
