Transcription écrite du podcast :
Bienvenue sur le podcast Parlons UX Design. Je suis Thomas Gaudy, UX designer, spécialisé en accessibilité des jeux vidéo aux personnes ayant un handicap.
On vous propose de démarrer une série de podcasts audio dont le propos est d'expliquer les différentes méthodologies et théories que pour ma part, je connais - parce qu’évidemment je ne connais pas tout - dans le domaine de l’UX Design.
Je travaille chez Ludociels pour tous, une organisation à but non lucratif dont le propos est de concevoir des jeux vidéo à visée sociale. On s’intéresse principalement à l'accessibilité. Notre modèle d'affaire actuellement est de nous tourner vers différents types de clients, dont des écoles pour faire des mandats d'enseignement. Nous devons être très prudents sur la façon d'utiliser notre temps. Il y a quelque chose qui prend pas mal de temps et qui peut être aussi frustrant du côté des étudiants et étudiantes dans les deux écoles qui sont l’ITESCIA à Cergy-Pontoise et l’ISART à Montréal. Il s’agit de devoir d’une année sur l’autre répéter toujours les mêmes notions théoriques. J'aime voir comment les étudiants s’emparent de cette théorie pour l’adapter à leur propre projet et leurs propres préoccupations.
Il y a une sorte de tiraillement et je pense que le podcast peut être une bonne idée pour faire gagner du temps à tout le monde. Cela permettrait aux étudiants d’avoir une base théorique qui semble, je l’espère, un peu plus organisée, disponible en tout temps, gratuitement. Ça pourrait servir également à d'autres personnes qui ne sont pas forcément dans ces écoles. Ça me libérerait du temps pour accompagner les étudiants dans leurs projets et d’être peut-être plus précis sur des points vraiment très particuliers.
Je ne sais pas quel va être le rythme de parution de ces podcasts. Les thématiques générales vont être de la théorie et des méthodologies en UX Design.
Pour ce premier podcast, je vous propose de parler d’analyse heuristique. On parlera aussi de playtests mais je voudrais voir aussi ce qui est particulièrement important pour moi - encore une fois il faudrait être très prudent sur ce qui me semble être important - pour réussir à mener avec succès une évaluation heuristique.Donc je propose aux étudiants en général, un document de gabarit qui reprend plusieurs informations et ce que je vous propose, c'est de reprendre plusieurs informations une à une pour expliquer et justifier leurs propos. Et que cela soit un peu plus facile de s'approprier ce gabarit.
En remarque générale sur le processus, quelque soit le type d'analyse, la finalité n’est pas de faire un rapport de plus mais de faire un projet de jeux dans lequel vous êtes en train de vous embarquer.
Donc à priori, vous allez faire des tests et des analyses. Ça va retarder votre effort de développement mais ce que cela va donner est que ça peut vous permettre, ça doit vous permettre d’identifier plus rapidement les bugs ou pire des problèmes de frustration du côté des joueurs et des joueuses. Si vous attendez que votre jeu soit quasi finalisé, certes ce sera plus facile de les observer auprès de vos joueurs, mais ce sera trop tard pour vous pour les implémenter dans votre projet, pour les prendre en compte.
Donc c'est super important d'avoir différentes méthodologies. En classe, j’explique qu’avant d'arriver à un produit final, il y a différentes méthodologies qui sont super pratiques. Par ordre de force, il y a la version Alpha ou encore mieux Bêta, qui est la mise à disposition en Beta Access, par exemple, auprès d'une communauté de joueurs présélectionnés qui vont pouvoir vous faire des retours à distance sur la qualité et les défauts de votre jeu. Ça c'est très bien, c'est encore plus puissant si vous accompagnez cette démarche d'analyse automatique de données pour comprendre quels sont les temps de jeu, quels sont les endroits où vos personnages, vos joueurs échouent ou mettent trop longtemps à comprendre ce qui se passe. Ce genre de choses c’est vraiment très très bien. Encore faut-il que votre jeu soit assez fort et assez satisfaisant pour que les joueurs ne s’en détournent pas au moment où vous faites cette « release » anticipée.
Pour ça vous avez intérêt à soigner quand même la qualité de ce projet que vous allez sortir à un stade par forcément fini. Donc il y a les playtests avant. Vous pouvez les faire directement chez vous dans votre studio ou aller à la rencontre des joueurs à l'occasion de salons ou de différents événements. En général, c’est la méthode la plus performante de mon point de vue pour obtenir directement des retours qualitatifs, attention je parle bien de qualitatif et pas de quantitatif. Pour voir ce qui se passe au niveau des expressions, du comportement, des verbalisations, c'est très riche. Mais ça prend pas mal de temps et il y a pas mal de choses à garder en tête aussi.
Encore avant ça, il y a une autre démarche qui est plus économique en temps mais pas plus efficace, elle est un peu moins précise, beaucoup moins précise, mais en général elle est pratique pour lancer la conception du projet sur de bons rails avant que vous ne passiez à l'étape des playtests. Même si les playtests, vous devriez être en mesure de les faire dès les premières étapes de conception de votre jeu avant même qu'il soit rendu interactif. Cette première démarche méthodologique c'est l’évaluation heuristique. L’évaluation heuristique, c’est ce dont on va parler pour ce premier podcast. L’évaluation heuristique, qu’est-ce que c’est ? Il s’agit d’utiliser des recommandations d'experts qui ont été approuvées et éprouvées aussi par des démarches scientifiques. Une démarche scientifique, c'est quoi ? C'est une méthodologie qui permettra à d'autres de répéter une hypothèse, un protocole d’expérimentation, le recueil de données objectives et l’interprétation de résultats. La méthodologie, c’est cette recette qui articule ces différentes notions pour arriver sur l'interprétation qui est, du coup, incontestable. Parce que d’autres personnes pourront ré-appliquer cette même recette et peut-être trouver des choses différentes. Il faut comprendre que la méthodologie scientifique ne prouve rien, car dans son propos, il s’agit d’une méthode de discussion toujours valable, qui laisse toujours la porte ouverte pour que des experts puissent se répondre et affiner les interprétations qu’on puisse faire.
Les heuristiques, je reprends donc, ce sont des recommandations très générales, appuyées par la méthodologie scientifique. Ca veut donc dire que ce sont des recommandations qui sont toujours un petit peu biaisées, qui seront toujours à améliorer parce que la recherche scientifique va continuer à avancer et va devenir de plus en plus fine et adaptée à différents contextes. Mais ce ne sont pas des recommandations qui sont tirées d'un chapeau par n‘importe quel expert et qui vont dire « bah voilà c’est comme ça qu’on va faire ».
Cela va devenir très problématique sous peu car vous allez prochainement retrouver deux experts qui vont vous affirmer des choses complètement contradictoires pour votre projet. Il faut une méthodologie qui puisse déterminer laquelle semble la plus fiable, à condition de la comprendre, de lire un petit peu le contexte et le protocole expérimental. Cela prend du temps, et il faut s’en méfier parce que quand cela est trop chronophage, ça devient contre-productif pour une démarche de production industrielle. Cependant, cela peut aider à partir sur de bonnes bases. Alors pour faciliter cette démarche et gagner du temps, je vais retravailler le document de gabarit que j’utilise pour enseigner. Ainsi, il pourrait peut-être servir aussi à d'autres personnes qui souhaitent mettre en place des analyses heuristiques.
La finalité de ce genre de démarche est le jeu vidéo. Il faut comprendre que le processus de production de ce jeu vidéo est un grand entonnoir. C’est à dire qu’à la fin, vous avez un seul jeu vidéo. Pour le faire, vous n'allez a priori pas être seul. La plupart du temps le jeu vidéo est un travail en équipe et même les personnes indépendantes en général vont devoir recourir à quelques collaborateurs ici et là. Donc c'est très rare d'avoir des jeux vidéo réalisés par une seule personne. Evidemment ça existe. Sauf que dès l’instant où vous avez plusieurs personnes, le conflit est inévitable. Toutes les idées des différentes personnes impliquées dans la réalisation de ce jeu vidéo ne vont pas se retrouver dans le projet final. Donc avant d'arriver en bout d'entonnoir, qui est la réalisation du jeu vidéo, la chose qu'il va y avoir au préalable est l'outil de gestion de plannings. Ça peut être Taïga ça peut être Gira, il y en a énormément. L’outil que vous allez utiliser pour déterminer ce qui va faire X ou Y tâche.
La finalité d'une démarche ergonomique d’UX Design est le jeu vidéo. Avant cela évidemment, il s'agit de pouvoir avoir un impact sur l’outil de répartition des tâches, l’outil de planning pour savoir quelle personne va s'occuper de telle modification, ou telle tâche pour bonifier le jeu. Cela est très bien mais ne suffit pas encore parce que vous allez probablement observer énormément de problèmes en faisant vos démarches. Et toutes ne pourront pas évidemment être transcrites sous forme de tâches dans l’outil de planning. Il y a des priorités à gérer évidemment donc il y a uniquement certaines priorités qui vont se retrouver mises dans cet outil de planning. Et que fait-on du reste vous me direz ? Il y a le risque qu'il soit perdu quelque part. Il est important d’avoir à l’esprit que lorsque l’on parle d'outils de gestion de plannings, on parle directement de tâches à faire.
Le problème avec le concept de tâches à faire est qu'on perd la visibilité sur la nature du problème. Cela signifie que si vous faisiez un test ou une méthodologie d’évaluation, vous auriez observé des problèmes, en auriez fait des interprétations. De ces interprétations, vous en auriez tiré des tâches à réaliser pour différentes personnes. Là, il y a tout un flot de raisonnement qui passera à la trappe si vous arrivez directement dans l'outil de gestion de plannings. Avant cela, on remonte un peu plus haut dans notre entonnoir. Il est important d'avoir un document de rapport de test qui permet d'expliquer cet enchaînement de processus qui permet d'arriver à des recommandations : untel va faire telle tâche, untel va faire telle autre tâche.
C’est donc ce document que je vous propose de voir afin de vous aider à faire un rapport de test et d’analyse qui puisse vous servir plus efficacement.Pour commencer, il est important d'avoir une bonne nomenclature. Vous allez avoir plusieurs versions de tests, plusieurs rapports de test et la chose qui serait dramatique est de mal le nommer et que celui-ci commence à se balader partout dans vos archives de documents et qu'on sache plus quel document correspond à quoi. Chaque équipe à sa nomenclature de classement. Il y en a une que j'apprécie particulièrement. Ce n’est pas forcément la meilleure mais elle consiste à nommer systématiquement les documents avec l'année par exemple 2020 tiret le mois (donc 04) tiret - le jour (donc le 17) ans et puis dans quelques jours quelques mois quelques années je dirais « Ah! Le podcast est vieux. Il faudra le refaire ».
De cette façon, cela vous permettra assez rapidement d’identifier les vieux rapports de test et les plus récents. Ce n'est pas suffisant donc vous mettez l’année tiret le mois tiret le jour et ensuite vous mettez le projet à tester. Vous pouvez être dans équipes dans lesquelles il y a plusieurs projets. La version du projet que vous testez prend toute son importance. En effet, vous pouvez envisager que le même jour, vous testez deux versions différentes du même jeu. Il faut savoir les distinguer efficacement. Cela est juste au niveau de la nomenclature pour nommer votre document. Il est important, dès l'instant où vous allez avoir plusieurs documents, de respecter la nomenclature. Ainsi, votre capacité à produire de nouvelles idées ou de nouvelles tâches ne sera pas entravée.
Une fois que vous aurez un document bien nommé, il est évidemment important d'avoir un contenu clair. Un contenu clair signifie faire des phrases courtes. Il y a beaucoup de personnes, moi y compris, au début de mon activité professionnelle qui cherchent à faire des phrases très alambiquées. La règle est simple : si vous avez une phrase qui fait plus d’une ligne, cela signifie qu’il y a un problème pour les personnes qui vont vous lire. Cela ne leur plaira pas. Ce n’est pas un exercice littéraire, c'est un exercice de concision et de précision en même temps. Si vous avez besoin de rentrer dans les détails, décortiquez vos idées en plusieurs phrases. Cela est très important car si votre rapport contient plein de bonnes idées mais quelles sont peu lisibles, vous n’aurez pas l’impact attendu.
L’exercice de lecture que vont faire vos collaborateurs va a priori être fastidieux pour eux, peu plaisant donc si vous faites des phrases courtes, cela rendra l’exercice beaucoup plus agréable et efficace. Faire des phrases courtes est bien. Toutefois, il convient d’être précis. Par précis, je veux dire que beaucoup de travaux étudiants que j’ai vus contiennent des « etc ». Par exemple, « les graphistes sont moches, les personnages, les ennemis etc ». Ça c’est trop vague. Typiquement, il faut réussir à définir, qu’est ce qui est moche plus précisément. Est-ce que ça te touche un ennemi en particulier ? Est-ce que c’est un ennemi ? Dans quel contexte ? Est-ce que c'est dans une animation particulière ? Est-ce que ça renvoie à une scène ? On verra un peu plus tard comment on peut détailler plus précisément ce genre de choses. Il faut à tout prix éviter à tout prix les généralités parce que quand c'est trop vague, ça ne veut plus rien dire.
Si un problème est trop général, je vous recommande de le décomposer en plusieurs sous problèmes. Autre chose, ne mélangez pas les informations de plusieurs problèmes à la fois. Chaque problème doit être bien séparé des autres pour permettre de suivre le déroulement logique de votre réflexion. N’abordez pas par exemple plusieurs problèmes de manipulation ensemble. Essayez de les détailler les uns après les autres. Si vous avez un jeu qui se joue clavier souris et que votre raisonnement d'une part le clavier sur-utilisé avec trop de touches sur le clavier d'autre part sur le clavier il y a des combinaisons de triple touche à faire et enfin troisième partie, on devrait envisager une jouabilité du clavier seul ou de la souris seule, il y a là dedans plusieurs problèmes que vous détaillerez. Cela permettra l’identification de ces problèmes et la simplification de l'attribution des tâches qui pourraient en découler.
Dans ce document, j'ai passé les remarques générales. Vous indiquerez évidemment votre nom et votre prénom. Cela est important dans une démarche professionnelle car il peut y avoir facilement plusieurs UX designers ou plusieurs ergonomes. Cela permet de savoir la provenance du document ou des documents. Cela semble évident mais quand ce n’est pas nommé, cela devient compliqué. Cela est aussi important pour des raisons de confiance. Vous pouvez avoir des collègues à peu près certains de la bonne qualité du contenu et puis d’autres pour lesquels cela ne se passe pas toujours comme prévu. N’oubliez pas ce petit détail évident. N’oubliez pas de mettre la date même dans le document, même si cela fait une redite avec la nomenclature de nommage de votre fichier. Vous rappelez le nom du projet testé et vous rappelez la version du projet testé et expliquez aussi la classification des importances de problèmes que vous comptez utiliser.
Ça peut être un peu surprenant au début pour les étudiants mais l'idée est que tous les problèmes vont pas être forcément aussi graves les uns que les autres : pour 100 problèmes que vous parvenez à identifier, on peut imaginer qu’il y a 70 problèmes vraiment très importants si vous avez le temps et le budget de tous les corriger. Qu’est-ce que ça peut être ? Ça peut être quelque chose de pas très important, la petite animation sympathique manquante mais qui n’est pas forcement essentielle, un petit effet graphique si votre souris passe sur un bouton et puis que vous voudriez qu’il y ait un effet particulier lorsqu'on appuie sur le bouton ou lorsqu'on le relâche. Des petites choses qu’on peut trouver comme des normes dans certaines interfaces mais qui ne vont pas forcement grandement gêner l’utilisabilité de votre interface.
Il peut y avoir des problèmes plus graves. Par exemple, le jeu n'a pas de bug, il fonctionne bien mais il manque un petit quelque chose qui empêche au joueur de s’amuser. Cela peut être un contrôle qui n’est pas confortable à utiliser, une interaction un peu « lourdingue ». Ça peut être quelque chose qui est affiché sur l'écran mais qui est dure à lire car trop petite ou bizarrement formulée, ou des fautes. Toutes ces choses ne sont pas des bugs qui vont planter le jeu. Toutefois, il est important de les corriger. Il y a différentes gravités possibles mais on comprend qu’elles sont plus importantes, plus prioritaires que les autres problèmes que j'ai mentionnés auparavant.
L’autre problème, d'une plus haute importance, est évidemment les gros bugs, les gros crashs. Ils ne sont pas forcément les seuls points bloquants dans un jeu vidéo. Ça peut être le joueur qui bugge, qui arrive dans une situation du jeu et qui ne comprend absolument plus rien. Alors vous pouvez dire fonctionnellement le jeu fonctionne il n’y a pas de bug. Cela est très bien mais si tous les joueurs buggent à ne pas comprendre pourquoi « je ne peux pas sortir de telle ou telle pièce ? » ou « qu'est-ce que je dois faire pour continuer ma quête c'est qu'il y a une information critique ou un élément de compréhension qui manque. Vous pouvez décider de le laisser pour voir si les joueurs se débrouillent par eux-mêmes mais peut-être pas et ça peut être gênant. Donc une classification là encore : chaque entreprise a la sienne. Il y a des standards qui existent mais il y en a plusieurs. J'aime bien utiliser la classification A, B, C, D.
Typiquement comprenez :
A : Gros point bloquant ou crash. C’est à résoudre de façon ultra prioritaire
B : Ce n’est pas un gros crash ou un gros point bloquant mais c'est quelque chose qui entâche grandement la satisfaction du joueur. Typiquement plein de mauvaises manipulations qui exaspèrent le joueur, des problèmes de lisibilité qui font qu’il peut s'en sortir mais que c'est vraiment fastidieux ; des mauvais retours sur certaines informations, qui font qu’il peut y arriver mais voilà…c’est quelque chose qui provoque beaucoup de frustration. Il faut plutôt le résoudre pour la qualité globale de votre jeu. C'est assez essentiel de considérer ces problèmes.
C : Je considère que ce sont des problèmes importants mais pas critiques donc là on peut en avoir vraiment plein. Typiquement en C, c'est tout ce qu'on pourrait mettre en polish du jeu pour le rendre de meilleure qualité mais sans que ce soit forcément essentiel. Attention aux éléments de polish pour rendre votre jeu de meilleure qualité. Il peut y en avoir énormément. On peut considérer que dans beaucoup de projets ça puisse facilement prendre 50 % du temps de développement. C'est quelque chose qui va vous demander beaucoup d’efforts, faire beaucoup de mécanismes de toutes sortes et cette masse de mécanismes de peaufinage est invisible au début quand on se lance dans un game design.Il est très important de se prévoir du temps dans votre planning pour réussir à aborder un maximum de ce type de problèmes. Ces problèmes, on ne les considère pas mais au fur et à mesure des tests et des analyses que vous allez faire, il y en a plein et plein et plein qui vont remonter et vous allez avoir l'impression de vous faire déborder et de prendre du retard ce qui permet d'arriver à la dernière catégorie de problèmes.
D : Vous pouvez garder en tête comme les problèmes qui sont certes intéressants mais pour lesquels vous n'aurez certainement pas le temps de les traiter. Typiquement, vous les laissez de côté en vue d'une reprise pour une prochaine suite. Quand vous reprendrez un jeu, si vous le reprenez, si vous faites une suite, vous reprendrez ces problèmes-là en tête dès la reprise en conception de votre projet pour qu'il ait tout de suite une meilleure qualité.
J’aime bien utiliser la classification A, B, C, D (des problèmes les plus critiques au plus facultatifs).
Ceci conclut notre première partie sur le podcast dédié à l’évaluation heuristique. Dans une seconde partie, nous allons voir plus spécifiquement les informations que vous devrez renseigner dans votre rapport concernant chacun des problèmes que vous serez en mesure d’identifier. A très bientôt.
Merci d’avoir écouté ce podcast, je vous invite à vous abonner pour ne pas rater les prochains épisodes. Si vous voulez en savoir plus sur moi, je vous invite à consulter mon profil Linkedin. Si vous souhaitez de l’accompagnement pour implémenter ces notions et ces outils dans vos équipes et vos projets, vous pouvez faire appel à mes services de consultant en UX Design. Au plaisir !
Transcription du podcast : Guillaume Le Négaret
Relecture et correction : Ngala Elenga
Édition : Stéphanie Akré
Commenti