En matière d’expérience utilisateur, dans la création de jeux vidéo (comme dans d’autres projets), ambition et moyens ne s’opposent pas si on sait réduire l’expérience finale de jeu souhaitée à sa quintessence, et la développer en mode agile en intégrant l’utilisateur tôt et souvent. Ambition et moyens s’opposent quand l’accessoire est développé avant le principal, le temps – et l’utilisateur – devenant des ennemis et des contraintes.
J’ai participé récemment en tant que jury à une présentation intermédiaire de projets de jeux vidéo réalisés par des étudiants.
C’était très intéressant, en particulier parce que toutes les équipes, quelque soit leur composition, leur approche du thème proposé et le résultat présenté, ont buté sur une difficulté qui semble donc être assez notable pour être notée : la qualité de l’expérience utilisateur. Et j’entends par là une acception large du terme, au sens où on l’entend en français, et pas au sens strict de « UX » / ergonomie, même si les deux sont intimement liés.
Les joueurs font-ils les bons concepteurs ?
Ce qui m’a surtout frappée, c’est que finalement, quelque soit le secteur d’activité et le sujet – jeu vidéo, application mobile, site web, réseaux sociaux… – il semble difficile de se mettre dans les chaussures de l’utilisateur, de voir les choses de son point de vue, de concevoir les choses pour lui … alors même qu’il est au centre et au coeur de tous les objectifs !
J’ai trouvé d’autant plus intéressant de le noter chez des – jeunes – concepteurs de jeux vidéo, car on peut supposer que dans ce secteur, ce sont des joueurs qui veulent devenir concepteurs, designers et programmeurs de jeu. Donc, qu’ils sont déjà utilisateurs avant de passer de l’autre côté de la barrière, et qu’ils ont une large connaissance des mécanismes de jeu, des différents types de leviers, stratégies et autres éléments d’un jeu.
Alors que chez les annonceurs et dans les agences, pour comparer à d’autres secteurs, le client ou le designer n’est pas toujours l’utilisateur, et se réfugie derrière ce prétexte pour justifier d’une mauvaise expérience de l’usager final.
Et bien, il faut croire qu’être utilisateur ne suffit pas ! Pourtant, ça devrait : ce sont les feedbacks des utilisateurs qui font évoluer un jeu ou un projet.
En l’occurrence, dans le cas de notre jury de jeux, ce sont les feedbacks des membres du jury en tant qu’utilisateurs – car les jeux ont été testés en temps réel – qui ont révélé l’essentiel des manques et insuffisances. Jargon technique mis à part, un jury moins expert dans le secteur aurait appuyé sur les mêmes points douloureux.
Quels sont les travers qui mènent à cela ?
Les justifications de chaque équipe, face aux critiques – bienveillantes -, ont été à chaque fois les mêmes ; ce sont exactement les mêmes qu’on retrouve dans d’autres secteurs, et ce n’est pas étonnant :
– Trop d’ambition au départ
– Temps imparti insuffisant pour servir cette ambition
– Parallélisation des tâches entre les différents membres de l’équipe, avec peu de points de rencontre et d’échange
– Très peu de tests (pour de bonnes ou de mauvaises raisons)
Résultat : énormément d’efforts dans ce que j’appellerai la réalisation des apparences (graphisme, décors, variété et multiplicité des contenus / assets graphiques), et une expérience utilisateur qui s’avère être ni à la hauteur de l’ambition ni à la hauteur du reste des éléments réalisés (manque de fil rouge, décalage entre la promesse de jeu et la réalité des tâches à accomplir ou des actions possibles, scénarios alambiqués, pas de vision globale de jeu …).
Ca vous rappelle une expérience vécue ? Dans d’autres secteurs ? Tiens tiens …
Pour résumer ce problème transversal à tant de secteurs et de projets, la volonté de départ est de construire une cathédrale* et le temps imparti ne permet que la construction d’une église de village.
Le problème étant : le temps imparti n’est pas fini, il n’est qu’une étape intermédiaire.
Faut-il poser les fondations d’une cathédrale, au risque de montrer une bâtisse mal finie et aux fondations branlantes à l’étape intermédiaire ? Ou faut-il partir sur les fondations d’une église de village, au risque de ne plus pouvoir la transformer en cathédrale, même si le temps disponible ensuite le permet ?
En gros : faut-il réduire l’ambition aux moyens disponibles (temps, argent, compétences…), ou faut-il viser grand au risque d’échouer et de ne plus pouvoir évoluer sur les bases de départ ?
Vision finale et démarche itérative : de l’art de concevoir une structure élastique
La bonne démarche n’est certainement pas de réduire l’ambition ; elle est d’arriver à concilier ambition importante et réalisations intermédiaires assez solides pour être auto-suffisantes et offrir une bonne expérience à l’utilisateur même si tous les éléments ne sont pas encore en place.
Ce qui nécessite de revoir la façon de mener ces projets, et d’une manière profonde :
– Etre capable de « disséquer » l’ambition et la vision finale souhaitées, pour en dissocier la quintessence du décor. C’est le squelette qui compte, et il faut être capable de percevoir sa forme et sa structure, car là sont les véritables bases du projet. Les apparences pourront évoluer selon les moyens, elles ne changeront pas fondamentalement l’expérience utilisateur.
Pour arriver à cela, il faut d’emblée et en permanence confronter sa vision de l’objectif à l’expérience vécue par l’utilisateur, en dépouillant tous les éléments qui ne participent pas fondamentalement à l’expérience. On est toujours étonné, en faisant cet exercice, de voir le nombre de choses qu’on peut retirer à un jeu ou projet sans que ça ne change vraiment sa raison d’être !
– Avoir une démarche itérative agile et non projective : dit autrement, on part du début, pas de la fin ! Une fois le squelette bien identifié, le jeu ou projet réduit à son essence, à son comportement de base (sans lequel le jeu n’existerait pas !), construire d’abord ce comportement, et rajouter au fur et à mesure du temps disponible les éléments accessoires complémentaires. Et pas l’inverse ! Ne pas partir en ayant en tête de tout faire, car généralement cette démarche crée surtout les éléments accessoires, et on se retrouve dépourvu sur le nécessaire …
– Tester, tester, tester … et encore tester ! Si vous travaillez pour qu’un utilisateur final utilise votre jeu ou votre projet, impliquez-le dès le début, et le plus fréquemment possible ! Les tests ne sont pas l’ennemi du temps : concevez plutôt votre planning comme un rétro-planning en incluant dès le départ des moments de test non négociables pour l’ensemble des membres de l’équipe. Le rôle de l’utilisateur n’est pas de challenger votre vision, ne vous trompez pas là-dessus ; il est de challenger l’exécution de votre vision, pour vous aider justement à ce que les deux se rejoignent.
Finalement, sous les jargons techniques et spécialisations sophistiquées des différents secteurs du numérique, on retrouve souvent les mêmes problèmes, les mêmes biais, et les mêmes types de solutions : car c’est le comportement humain qui est bien souvent à la fois le problème et la solution ! Arriver à identifier cela, derrière ou au-delà du jargon de chaque fonction et de chaque secteur, c’est être en bonne voie de trouver la solution à son problème. Faut-il encore vouloir le faire …
*NB1 : références non religieuses :), mais informatiques – cf « The Cathedral and the Bazaar », d’Eric Raymond.