Parlons UX Design - #1

Évaluation heuristique - Partie 1

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 podcast 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 du 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, c'est qu'on se tourne vers différents types de clients, dont des écoles pour faire des mandats d'enseignement et il faut qu’on soit très prudent sur la façon d'utiliser notre temps. Il y a quelque chose qui bouffe 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, c’est 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 un espère de tiraillement et je pense que le podcast peut être une bonne idée pour faire gagner du temps à tout le monde. Ça permettrai aux étudiants d’avoir une base théorique qui semble, j’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é ce n’est pas de faire un rapport de plus, la finalité c'est le 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 c’est que ça peut vous permettre, ça doit vous permettre d’identifier plus rapidement les bugs ou pire des problème de frustration du coté des joueurs et des joueuses. Et ça, si vous attendez que votre jeu soit quasi finalisé, certes se 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 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 évaluation heuristique. L’évaluation heuristique c’est ce dont on va parler pour ce premier podcast. L’évaluation heuristique, c’est quoi ? C’est utiliser des recommandations d'experts qui ont été approuvé et éprouvé 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 donc ça veut 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 a 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 ».


Ça va devenir très problématique très rapidement parce que assez rapidement vous allez retrouver deux experts qui vont vous affirmer des choses complètement contradictoires pour votre projet et à ce moment laquelle choisir. Il faut une méthodologie qui puisse déterminer laquelle semble la plus fiable et la méthodologie scientifique à condition de la comprendre à condition de lire un petit peu le contexte et le protocole expérimental -et ça prend du temps, et il faut s’en méfier parce que quand c'est trop chronophage c'est contre-productif pour une démarche de production industrielle mais voilà ça peut aider à partir sur de bonnes bases. Alors pour faciliter cette démarche et gagner du temps ce document de gabarit que je propose dans l'école je vais le reprendre et pourrait peut-être servir aussi à d'autres personnes qui souhaitent mettre en place des analyses heuristique.


Donc la remarque générale : la finalité de ce genre de démarche je disais c'est le jeu vidéo. Mais le jeu vidéo il faut comprendre que le processus de production de ce jeu vidéo c'est un grand entonnoir. C’est à dire qu’à la fin vous avez un seul jeu vidéo mais pour se faire pour le faire apriori vous n'allez pas être seul. La plupart du temps le jeu vidéo c'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 très rare d'avoir des jeux vidéo réalisés par une seule personne. Evidemment ça existe. Sauf que des l’instant que vous avez plusieurs personnes le rapport évidemment va y avoir des conflits et toutes les idées les 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, ce qu'il va y avoir avant, ça va être c'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 qui va faire telle tache.


Donc la finalité d'une démarche ergonomique du UX Design c'est le jeu vidéo mais avant ça évidemment il s'agit de pouvoir avoir un impact sur l’outil de répartition des taches, l’outil de planning pour savoir quelle personne va s'occuper de telle modification, ou telle tache pour bonifier le jeu. Alors ça c’est très bien mais ça ne suffit pas encore parce que cet effet d’entonnoir vous allez observer probablement beaucoup beaucoup beaucoup de problèmes en faisant vos démarches. Et toutes ne pourront pas évidemment être transcrit 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 le reste qu'est-ce qu'on en fait, il y a le risque qu'il soit perdu quelque part et puis il y a un autre problème qui est important aussi c'est que quand on parle d'outils de gestion de plannings on parle directement de tâches à faire.


Et le problème avec le concept de tâches à faire c'est qu'on perd la visibilité sur quel était le problème à la base. C’est-à-dire que vous ferriez un test ou une méthodologie d’évaluation, vous observeriez des problèmes, vous en feriez des interprétations et de ses interprétations vous en tireriez des tâches à réaliser pour différentes personnes.

Mais là il y a tout un flot de raisonnement qui passerai à la trappe si vous arrivez directement dans l'outil de gestion de plannings. Donc encore avant ça, on remonte un peu plus haut dans notre entonnoir, c’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.


Et donc c'est ce document que je propose de voir comment vous pouvez faire un rapport de test, d’analyse qui puisse vous servir plus efficacement.

Pour commencer c'est important d'avoir une bonne nomenclature. Vous allez avoir plusieurs versions de tests, plusieurs rapports de test et ce qui serait dramatique c'est qu'il soit mal nommé et qui commence à se balader partout dans vos archives de documents et qu'on sache plus quel document correspond à quoi.

Chaque équipe à sa nomenclature de classement. Moi il y en a une que j'aime bien c'est pas forcément la meilleure mais ça 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! Ça date. Il faudra le refaire ce podcast ».


De cette façon ça 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 ou il y a plusieurs projets et aussi important la version du projet que vous testé. Parce que vous pouvez envisager que le même jour vous testez deux versions différentes du même jeu. Il faut savoir les distinguer efficacement. Ça c’est juste au niveau de la nomenclature pour nommer votre document c'est important des l'instant que vous allez avoir plusieurs documents ça peut vite devenir la jungle et dans ce cas là-les documents ça va juste être du bruit qui vont gêner votre capacité de produire de nouvelles idées ou de nouvelles tâches.


Une fois que vous aurez un document bien nommé c'est important évidemment d'avoir un contenu clair. Alors un contenu claire ça veut dire déjà de faire des phrases courtes. Il y a beaucoup de personnes, moi compris, au début de mon activité professionnelle qui cherchait à faire des phrases super alambiquées. La règle est simple : si vous avez une phrase qui fait plus d’une ligne déjà c’est qu’il y a un problème pour les personnes qui vont vous lire. Elles ne vont pas appréciées. 
C'est pas un exercice littéraire c'est un exercice de concision et de précision en même temps donc si vous besoin de rentrer dans les détails décortiquer vos idées en plusieurs phrases. C’est super important parce que si votre rapport contient plein de bonnes idées mais quelles sont peu lisibles, quelque-part vous aurez raté le coup.


L’exercice de lecture que vont faire vos collaborateurs va déjà être à priori fastidieux pour eux, peu plaisant donc si vous faites des phrases courtes ça va rentre l’exercice beaucoup plus agréable et efficace.

La deuxième, c’est bien de faire des phrases courtes, mais il faut aussi être précis. Alors par précis, ce que je veux dire, c’est que je trouve beaucoup de travaux étudiants qui contient 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 beaucoup 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 renvoi à une scène donc on verra un peu plus tard comment est-ce qu'on peut détailler plus précisément ce genre de choses. Mais é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 ce que je vous recommande de faire c'est de le décomposer en plusieurs sous problème. Autre chose ne mélangez pas les informations de plusieurs problèmes à la fois donc 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 seul, il y a la dedans plusieurs problèmes que vous détaillerez de facilité et cela permettra l’identification de ses problèmes et aussi de faciliter l'attribution des tâches qui pourraient en découler.


Dans ce document donc j'ai passé les remarques générales vous indiquerez évidemment votre nom votre prénom. Dans une démarche professionnelle cela est important parce qu’il peut y avoir facilement plusieurs UX designer ou plusieurs ergonomes pour savoir quel document vient d’ou, cela semble évident mais quand ce n’est pas nommé, cela devient compliqué.

Et puis c'est important pour l'histoire de confiance. Vous pouvez avoir des collègues à peut près certain de la bonne qualité du contenu et puis d’autres ou cela ne se passe pas toujours très très bien. 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 rappeler le nom du projet testé et vous rappeler la version du projet testé et vous expliquez aussi la classification des importances de problème que vous comptez utiliser.


Ça peut être un peu surprenant au début pour les étudiants mais l'idée c'est que tous les problèmes vont pas être forcément aussi grave 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 important mais 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 super 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 est 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. Çà va un petit peu la grignoter mais ça ne va pas être critiques donc c'est pas des choses essentielles. C’est quand même des choses pratiques.


Il peut y avoir des problèmes plus graves typiquement là le jeu n'a pas de bug, il fonctionne bien mais il manque un petit quelque chose qui fait que le joueur ne s’amuse pas. Çà 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 c’est dur de le lire parce que c’est trop petit ou bizarrement formulée, ou des fautes. Tout ça ce ne sont pas des bugs qui vont planter le jeu mais c’est important de le corriger. Il y a différentes gravités possibles mais on comprend que c’est plus importante, plus prioritaire que les autres problèmes que j'ai mentionnés auparavant.

Autre problème d'une plus haute importance évidemment c'est les gros bugs, les gros crashs ou les bugs et les crashs ce n’est pas forcément les seuls points bloquant dans un jeu vidéo. Ça peut être le joueur qui bug 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, c’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. Moi 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 c'est pas un gros crash ou un gros point bloquant mais c'est quelque chose qui entache 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 c'est vraiment fastidieux ; des mauvais retours sur certaines informations, qui fait qu’il peut y arriver mais voilà…c’est quelque chose qui provoque beaucoup de frustration et ça c'est pareil 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 c'est les 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 au début quand on se lance dans un game design elle est invisible.

C'est super important de se prévoir du temps dans votre planning pour réussir à aborder un maximum de ce type de problèmes et 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 prendre du retard surtout. Ce qui permet d'arriver à la dernière catégorie de problèmes. En D. Vous pouvez garder en tête comme ce qui sont certes intéressant mais vous n'aurez certainement pas le temps de les faire donc 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, ces problèmes là vous les reprendrez en tête dès la reprise en conception de votre projet pour qu'il est tout de suite une meilleure qualité.


Expliquer la classification de l'importance des problèmes que vous comptez utiliser, vous expliquer la nomenclature de problèmes que vous allez utiliser, moi j’aimes bien A, B, C, D. Des plus critiques ou 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 !

Recevez notre infolettre à propos des jeux vidéo accessibles, de nos activités et de nos vidéos Parlons UX Design.

Soyez notifié de la sortie d'un nouvel épisode de notre podcast Parlons UX Design.

Contactez-nous

Vous voulez nous soutenir?

Grâce à vos dons, nous pouvons continuer à promouvoir l'accessibilité en offrant à tous des loisirs adaptés et ludiques. Parce que tout le monde a le droit de jouer.

Merci pour votre générosité!

© 2019 Ludociels pour Tous