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.
Bienvenue dans cette seconde partie de ce podcast dédié à l'évaluation heuristique.
Dans la première partie nous avions vu des informations plutôt générales qui servent à rendre votre rapport plus clair et plus intelligible. Dans cette 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'observer.
Vous allez rentrer les informations suivantes :
- En premier lieu le titre et la numérotation du problème. La numérotation est importante parce que c’est la façon de référer le plus rapidement le problème. Par exemple vous allez dans un restaurant chinois, vous dites juste un numéro et c'est très clair pour tout le monde. Vous gagnez du temps. Dans une équipe c'est pareil ! Vous rentrez un numéro et cela peut être plus rapide d'autant plus si ce numéro est associé à un lien hypertexte ; ce qui permet d'arriver tout de suite sur le bon élément.
Sauf qu'un numéro ce n'est pas parlant. C’est donc bien de l’accompagner par un titre explicite. Un titre explicite cela veut dire qu’il ne doit être trop long et assez clair. « Problème de gameplay » typiquement cela ne veut rien dire. Vous pouvez dire par exemple « éviter les combinaisons de triple touche ». C’est déjà un petit peu long mais ça donne une meilleure idée.
- En deuxième information vous allez donner une description du problème. C’est là que vous pouvez rentrer dans un exercice littéraire qui va essayer d'être plus précis. C’est aussi là que vous garderez en tête cet impératif d'avoir des phrases courtes et lisibles. C'est très important d'être précis. Récapituler le contexte, si cela est pertinent l'endroit dans le niveau, l'endroit du menu… ce genre de choses. Cela dépend vraiment des problèmes mais c'est ici qu'on peut rentrer dans les détails.
Ne faites pas non plus un roman. Plus c'est long et moins votre rapport sera efficace. Le mieux c'est toujours d'être court et précis.
- Troisième catégorie d'informations : nous sommes dans une évaluation heuristique. Ce problème que vous êtes en train de remonter il revient soit d'une observation de playtest, soit de la prise en compte d'une heuristique. Nous sommes là dans un gabarit de rapport heuristique donc je vous demande de citer l’heuristique relié au problème.
L'utilisation des heuristiques, vous pouvez la faire dans deux sens. C'est-à-dire que l’heuristique est une grille avec des recommandations générales. Pour les plus célèbres, vous pouvez utiliser celle de Jakob Nielsen. Il en a fait qui sont appliquées aux jeux vidéo. Ce sont les mêmes que ses dix heuristiques appliquées au web, mais avec des exemples tirés de jeux vidéo. Vous pouvez en trouver aussi beaucoup d'autres. Voir par exemple, les recommandations de Bastien et Scapin. Ils ne s’intéressent pas directement au jeu vidéo mais leurs recommandations sont toujours très pertinentes dans ce domaine là.
Vous pouvez, par vous-même face à un projet, identifier des problèmes et utiliser les heuristiques pour donner du poids à votre avis.
« - Je pense que ton jeu a un problème au niveau des contrôles ». Par exemple sur un projet de téléphone sur lequel un contrôle d’avatar se fait en inclinant le téléphone. Je pense que ce n’est pas bon [Cela me fait penser évidemment à un projet que j’encadre]. Pour donner plus de poids à ce genre de choses, je mets en pièce jointe une heuristique. De tête j'ai oublié le rapport mais lorsque j'avais fait le retour, il y avait le document, la page, l’heuristique et l’auteur. Cela permet de comprendre. Ce n’est pas forcément suffisant mais c'était plus précis.
Voilà la première façon d'utiliser l’heuristique. Vous voyez tout de suite instinctivement un problème et pour donner du poids à votre avis vous utilisez l’heuristique derrière.
Mais une autre façon plus professionnelle d’utiliser les heuristiques, c'est de partir de la grille d’heuristique et pour chacune d'entre elle, vous regardez le projet et vous essayer de voir si vous n’identifier pas des problème en considérant les heuristiques comme grille d'analyse de départ. C'est une autre démarche. C’est en général plus précis et ça permet d'être un petit peu mieux organisé. À vous de voir, vous pouvez faire les deux. Idéalement faites les deux ! Partez d’abord avec votre propre ressenti ce sera plus rapide. Prenez en note les choses qui vont sauter aux yeux. Dans un second temps utiliser les grilles heuristique comme grille de lecture pour critiquer davantage le projet.
C'est bien de citer l’heuristique. Vous pouvez en citer plusieurs, mais il faut aussi que cette heuristique puisse être consultée. Je vous demande pour ça de citer éventuellement le lien Internet, ou si cette heuristique n’est pas trouvable sur le lien Internet, la référence du document. Dans ce cas là vous citez : l’auteur, l’année, le journal de publication, le numéro, le volume… toutes les informations qui permettront de faire une recherche par quelqu'un d'autre et de retrouver cette information
La grande majorité des cas les informations utilisées sont trouvables sur Internet pour faire gagner du temps à tout le monde. Mais garder en tête que ce n'est pas la seule source d’information. Il y a beaucoup de choses qui sont sur les format papier uniquement. De moins en moins certes mais quand même.
L’autre point qui semble évident concerne l'auteur de l’heuristique. C’est important parce que toutes les heuristiques sont pas toutes aussi pertinente. Je disais que ça dépend de la qualité de la méthodologie scientifique qui est associé. Et ce souci de qualité de méthodologie scientifique dépend aussi de la qualité de l’auteur.
Et certains seront donc plus pertinent que d’autres.
Quand vous citez une heuristique avec son auteur ca permet très rapidement, pour ceux qui s’y connaissent un petit peu, de dire d'accord « c'est vrai ! Effectivement lui la plupart du temps c’est assez juste ». J'ai plutôt intérêt à prendre en compte ses conseils.
Et à l’inverse si c'est un autre auteur, on peut toujours se renseigner un peu sur lui. Il peut y avoir des auteurs qui ont mauvaises réputation, qui ont eu des problèmes d'escroquerie ou de falsification de résultats. Cela arrive ! Dans ces cas on aura plutôt tendance à invalider ce support, cet argument supplémentaire.
A ce niveau là, on est toujours sur de l’écrit, sur l’apport de littérature. Il faut considérer que c'est important, ça permet de rentrer dans les détails. Mais ce n’est pas ce qu’il y a de plus efficace. Ce qui est le plus efficace c'est d’apporter des images. Donc en général je demande d'apporter une capture d'écran ou une courte vidéo. Pour des menus, la capture d'écran c'est vraiment très bien. Dans beaucoup de situations de jeux vidéo, c'est insuffisant. Une capture vidéo permet de voir le problème en mouvement. Ça peut être des glitchs qui apparaissent dans certaines situations. À vous de voir ce qui est le plus pertinent. On commence à toucher à quelque chose d’un peu plus délicat : tout de suite prendre une capture d’écran, c’est encore mieux si on l’annote ou une capture vidéo cela prend beaucoup plus de temps. Certes ça VOUS prend plus de temps.
Par compte ce que cela vous prend comme temps en plus, va libérer du temps à vos collaborateurs. C’est-à-dire que quand ils vont se saisir de votre rapport pour comprendre et décortiquer vos problèmes, ces captures d'écran et ces vidéos, vont leur permettre de saisir beaucoup plus rapidement ce que vous voulez dire. Ça vaut le coup de prendre ce temps pour rendre la compréhension de ce problème là plus claire, plus évidente et plus rapide pour vos collaborateurs.
Le problème que vous avez identifié vous l’associez à l'importance du problème. Cette classification que vous avez expliciter en début de rapport (système A-B-C-D ou autre que vous aurez choisi), lorsque vous aurez fait ça, vous n’aurez fait pour l'instant que la moitié du problème. Parce que ce n'est pas tout d'identifier un problème, il faut aussi expliquer quelle pourrait être la solution. C’est important de pouvoir faire la part des choses entre les deux.
Pour un problème identifié il peut y avoir une multitude de solutions possibles. Il faut bien distinguer systématiquement problèmes et solutions. Vous proposez une solution que vous expliquer en détail. Vous pouvez expliquer d'ailleurs plusieurs pistes de solution. En disant par exemple « celle-ci est rapide mais elle ne corrige pas complètement le problème ». Dans un contexte où l’on peut être un petit peu pressé par le temps dans ce cas choisissez celle-ci. Par contre si nous avions un peu plus de temps un peu plus de budget c'est plutôt les choses comme ça parce que ça corrigerai tel ou tel aspect. C’est toujours bien pour un problème d'apporter plusieurs solutions possibles. Ce n’est pas toujours nécessaire mais apportez au moins une solution qui soit adaptée au contexte de développement de votre projet. C'est un problème que j'avais pendant un moment lors de mes premières expériences professionnelles. J’avais tendance à proposer des solutions qui me semble être parfaite pour corriger les problèmes mais qui était en décalage avec la réalité du planning de l’entreprise. Cette dernière était souvent pris à la gorge et devait choisir des solutions extrêmement rapide à mettre en place.
La plupart du temps on recherche plutôt des sparadraps efficaces que des prothèses bioniques qui vont faire encore mieux que ce que l’on pouvait espérer.
C'est pas mal. Mais cette proposition de la solution là encore nous sommes sur quelques choses de littéraire. Et là encore cela va être beaucoup plus efficace si vous parvenez à expliquer votre solution sous une forme graphique. Pourquoi la forme graphique ? Il y a plusieurs approches possibles : vous pouvez faire un wireframe. Un wireframe va consister à proposer un positionnement de différents éléments sur un écran ou sur l'interface graphique. Souvent on parle de manipulation de carrés, de bloc de rectangles, de placeholders… qui vont donner du sens, qui vont donner une idée de proportion et de dispositions. Mais beaucoup de choses vont passer à la trappe. L'avantage du wireframe c'est en général assez rapide à faire.
Pour aller plus loin ou si le contexte le permet faite un mockup.
Le mockup est un wireframe amélioré. Vous allez avoir le souci du détail. Vous allez essayer de rentrer le code couleur et d'avoir un niveau de finition qui puisse presque faire penser que ce sera le produit final. Un mockup très bien réalisé est comme une capture d'écran du jeu en vrai. Et parfois il y a même l'interactivité en plus.
Mais cela reste un mockup parce que il n’y a pas le jeu complet dedans. Il y a plein de choses qu'on ne peut pas réaliser proprement avec les outils de mockup.
De temps en temps cela ne suffit pas. De temps en temps il faut passer par quelque chose de plus interactif et donc vous pourriez avoir besoin de passer par des moteurs de jeux plus light pour expérimenter des idées. Par exemple avec Zelda Breath of the Wild, l’éditeur d'énigmes a fait beaucoup parler de lui. Zelda Breath of the Wild est un jeu en 3D et l’éditeur qu’ils ont utilisé, était un jeu en 2D qui faisait penser au tout premier Zelda sur NES.
Avec ce genre d’outils, on est vraiment sur la conception, ou presque de mini jeux. Cela peut être pratique. Plus vous prenez un moteur de jeu qui soit light et plus cela peut vous permettre de tenter d'expérimenter des choses. Et même pour un jeu en 3D vous pouvez expérimenter des choses sur un moteur de jeu en 2D. Encore une fois cela dépend du contexte.
Vous avez toutes les informations. Je vais les récapituler, cela sera plus clair.
Pour chacun des problèmes identifiés, le titre et la numérotation puis la description du problème puis la citation de l’heuristique reliée aux problèmes puis le lien Internet permettant de consulter l’heuristique, l'auteur de l’heuristique. Nous sommes là sur le descriptif littéraire.
Vous revenez ensuite sur le problème expliqué sous une forme graphique, la capture d’écran. Ensuite vous rappelez l'importance du problème.
Vous faites ensuite une proposition de solution d'abord sous un format littéraire. Ensuite vous faites une proposition de solution sous une forme graphique.
Et enfin il faut que cet apport de solutions vous puissiez expliciter le temps que ça pourrait prendre pour l'entreprise. Cela permettra de placer le curseur sur la répartition des tâches entre les problèmes urgents et les problèmes faciles à corriger. Ces deux paramètres permettent de savoir ce que l’on fait, comment nous nous débrouillons dans le planning.
Avec ces informations, vous avez à peu près tout : vous allez identifier tout un lot de problème, en masse. Ce qui peut être le bienvenue à la fin c'est de faire une petite synthèse. Dans un document vous expliquez les problèmes qui vous semble être les plus importants à corriger. Le but n’est, évidemment pas que les idées restent à ce stade. Mais bien de vous fournir des billes des arguments et une trace à archiver pour qu’un maximum du contenu de ce document puisse être reporté sur l’outil de planning puis dans le jeu. Si nous nous rendons compte plus tard dans le processus de développement de ce jeu, qu’il y a des choses que nous avons mal compris ou mal pensé, nous pourrions revenir dans les archives, consulter le document et se dire qu’il y avait là une information que nous avions peut être mal interprétée.
C'est pour ça que c'est important d'avoir des traces de ses rapports de test.
Je termine là ce premier podcast sur le contenu d'une démarche pour faire une évaluation heuristique. Le prochain podcast que je ferai cela à peu près la même démarche mais appliqué aux playtests. Surtout n’hésitez pas à envoyer des commentaires pour nous aider à bonifier cette démarche.
A très bientôt !
Si vous voulez en savoir plus sur moi je vous invite à consulter mon profil LinkedIn Thomas Gaudy.
Si vous souhaitez de l'accompagnement pour implémenter ses notions et ses outils dans vos équipes et vos projets vous pouvez faire appel à mes services de consultant en design il vous suffit de me contacter via mon profil Linkedin.
Au plaisir.
Transcription du podcast : Guillaume Le Négaret
Édition : Stéphanie Akré
Comments