#03 - Rapport de playtest

Problème d'affichage du lecteur ? Écoutez l'épisode 03 sur SoundCloud.

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.

Bonjour tout le monde, pour ce nouveau podcast, je vais vous expliquer comment remplir efficacement un rapport de playtests.

Tout d’abord, il faut savoir que le playtest est assez essentiel pour réaliser l’existence de toutes sortes de problèmes, que vous-même, en tant que concepteur d’un jeu, ou de toute autre forme de projet, vous pouvez ne pas avoir conscience.

En fait, c’est assez simple, dès l’instant que vous êtes en train de concevoir quelque chose, vous avez forcément en tête une idée de la façon d’utiliser ce « quelque chose ». Si vous concevez un jeu, vous vous attendez à ce que les joueurs prennent en main ce jeu de la façon que vous aurez envisagé. Évidemment, dans la réalité, vous allez avoir des surprises. Vous aurez toutes sortes de testeurs qui vont prendre en main toutes sortes de projets d’une façon complètement imprévue. Là intervient l’utilité des playtests.

Les playtests permettront de rendre votre projet plus flexible pour une plus grande variété d’utilisateurs. Ils seront surtout utiles afin d’identifier toutes sortes de problèmes que vous, en tant qu’auteur du projet, ne serez plus en mesure d’identifier par vous-même.

Tout d’abord, il faut savoir qu’il doit y avoir plusieurs sortes de testeurs pour votre jeu. En fait, il doit y avoir plusieurs catégories d’usagers pour votre jeu, vous devez donc être en mesure d’identifier différents profils, différents persona. Par exemple, il y aura peut-être des gens plus portés sur l’exploration, d’autres qui sont à la recherche d’un challenge particulier, et d’autres qui vont chercher à finir un jeu et ensuite passer à autre chose, sans forcément profiter d’extensions ou de contenus bonus additionnels. Il y a donc toutes sortes de profils à considérer.

Idéalement, si vous pouvez identifier des catégories de joueurs qui soient appuyés par des statistiques existantes, c’est encore mieux. Mais même en l’absence de ces statistiques, essayez quand même d’envisager différents profils de joueurs complémentaires.

Une fois que vous aurez identifié ces différents profils de joueurs, essayez de recruter des testeurs qui correspondent à ces profils. Pour cela, dans votre rapport de playtests, vous aurez donc une phase de présélection de vos testeurs.

Pour présenter vos différents testeurs, il déjà bien de prendre l’âge en compte – même si l’âge n’est pas forcément un facteur déterminant quant au type de jeu joué par l’utilisateur ( c’est un peu plus flou que ça) - c’est quand même un indicateur pertinent pour donner une tendance générale d’appréciation.

Il est aussi important de considérer le sexe du playtesteur ou de la playtesteuse parce que - là encore sans que ça soit quelque chose de trop déterministe - il y a toujours des tendances qui peuvent émerger.

N’oubliez pas de mentionner la date du test, la version du projet testé, et, pour mieux identifier le persona du ou de la playtesteuse, il est par exemple pratique de poser une question simple, à savoir énumérer trois jeux connus par votre testeur qui se rapproche le plus du projet testé. Alors, il peut y avoir une approche beaucoup plus complète que celle-ci, mais ce qui est pratique avec la question des trois jeux, c’est qu’elle vous permet quand même assez facilement de comprendre le rapport de l’utilisateur au jeu testé. Par exemple, si vous faites un jeu de simulation, mais que la personne en face de vous ne connaît absolument aucun autre jeu de simulation, les retours qu’on pourra vous faire seront peut-être un peu en décalage avec votre public cible. Ça ne va pas être inintéressant - ça va probablement vous permettre de développer la prise en main et l’apprentissage de votre jeu -, mais le volume et l’importance des problèmes reportés va peut-être vous demander plus d’efforts, là où une catégorie de joueur mieux ciblé vous aidera à identifier des problèmes plus justes.

Ensuite, il faut que vous expliquiez pour chacun des testeurs le protocole de test. C’est une étape importante, car sans protocole de test, le testeur ne saura pas forcément dans quelle condition doit se dérouler le test, et il y a quelque chose d’important qu’il peut rater. Il pourra se lasser du projet à tester et avoir envie d’abandonner. S’il n’y a pas de consignes qui expliquent, par exemple, à quel moment on doit abandonner le jeu (on peut abandonner le jeu à n’importe quel moment), le joueur va finir par se forcer à jouer et vous ne serez pas facilement en mesure d’identifier ce moment de décrochage.

Donc l’explication du protocole de test et des consignes associées, peuvent influencer positivement le comportement du joueur, le rendre plus transparent, et l’aider à mieux gérer son temps et son énergie parce qu’il saura qu’après le test lui-même il peut y avoir peut-être ¼ d’heure, ½ heure, plus rarement une heure de discussion pour comprendre un petit peu son ressenti.

Alors, pas vis-à-vis du testeur, mais vis-à-vis de vos lecteurs du rapport, c’est bien d’expliquer brièvement les rôles de chacun dans l’équipe de test, c’est-à-dire « qui fait quoi ». Dans votre équipe de test, il y aura probablement une personne qui va prendre des notes, peut-être une personne qui va accompagner le testeur pour expliquer le protocole, peut-être une personne qui va tenir une caméra (parfois un support caméra c’est très bien, mais parfois un smartphone ça peut suffire).

Dans votre rapport, il est donc très important d’identifier les rôles des membres de votre équipe, surtout d’un point de vue éthique et pratique de travail pour créditer les participations de chacun.

Après, dans une démarche plus professionnelle, quand vous êtes dans une entreprise qui est spécialisée dans le retour de rapport de test en général, il n’y a qu’une signature qui vaille, c’est le logo de l’entreprise. Mais dans une démarche interne ou dans une école, c’est toujours bien de rappeler les rôles occupés par les membres de l’équipe.

Une fois que vous avez précisé ces différentes informations, on revient un peu comme sur le rapport d’une analyse heuristique, à savoir : vous énumérez votre problème, vous donnez un titre concis, mais suffisamment évocateur pour qu’on puisse parler du problème, vous expliquez, au moment de l’observation du problème, quel est, à ce moment précis, le comportement du testeur.

Donc, vous aurez toujours la préoccupation de distinguer, d’une part, les comportements observables - les données objectives-, et d’autre part, les interprétations que vous pourrez faire de ces données, c’est-à-dire de votre vision sur la nature du problème.

Vous n’expliquerez pas toujours directement le problème, vous allez d’abord commencer par expliquer une attitude, un comportement du testeur, qui appuiera peut-être une investigation - pour dire qu’à ce moment, il y a potentiellement un problème. Il s’agit donc de fournir des détails et d’être précis.

Il s’agit aussi d’insister auprès du testeur, que ça soit au moment du test si c’est pertinent et si ça ne casse pas votre protocole, ou alors après lors de l’entretien post-test. Et, à ce moment-là en insistant auprès du testeur vous finirez par obtenir plus d’éléments sur les raisons des comportements qui ont été observés. Donc c’est vous de voir si vous le demandez avant ou après le test sachant que ces deux phases sont très importantes.

Ensuite, quelle est votre interprétation sur ce que pourrait être le problème dans le projet? C’est ici que vous distinguez, avec votre point de vue et votre expérience, à quel niveau se situe le problème. Il peut y avoir beaucoup d’interprétations possibles et donc de nombreux problèmes potentiels pour un comportement observé. Soyez toujours vigilants avec ça.

Alors tout ça, c’est bien, mais à ce niveau-là on est toujours dans la description littéraire, ça a quelque chose d’assez lourd à lire, et ce n’est pas non plus toujours très parlant. Par contre, ça permet en général de rentrer dans les détails.

Donc pour avoir une bonne démarche de test, vous faites en général votre test avec un support vidéo. Vous enregistrez ce qu’il se passe, idéalement vous enregistrez la capture vidéo du déroulement du jeu, les expressions faciales de votre joueur, et si vous en avez la possibilité, vous enregistrez également les membres qui servent à votre testeur pour interagir avec le jeu. Alors évidemment on parle souvent des mains, des doigts, mais parfois ça peut être des choses un peu plus compliqués comme le cas de l’ancienne Kinect ou des jeux qui s’utilisent avec la webcam ou d’autres périphériques - donc c’est pas toujours au niveau des mains que ça se passe.

Donc il faut une vidéo. Mais attention avec la vidéo, car parfois on peut avoir des choses à la fois très longues et très confuses. Donc il ne s’agit pas d’envoyer une vidéo de la durée du test : « voilà débrouillez-vous ». Si vous proposez une vidéo, idéalement, pour chacun des problèmes que vous identifiez, vous devez être en mesure de présenter une lecture de vidéo au moment précis où le comportement en particulier est observable. Pour être un peu plus précis, imaginez une situation où l’avatar doit chercher un objet magique dans son inventaire pour franchir un portail magique (tout est souvent très magique dans les jeux vidéo); il se trouve que l’inventaire est très mal fait avec des informations diffuses et trop nombreuses. Le joueur commence à fouiller là-dedans, vous le voyez soupirer et perdre patience. Vous allez donc devoir pointer la vidéo vers ce moment précis. YouTube permet par exemple de faire ça, mais ce n’est probablement pas le seul lecteur.

Pour résumer, quand vous partagez votre vidéo, ne faites pas juste un lien vers la vidéo qui commence à zéro, faites un lien qui commence au moment précis du problème. Et en faisant ça d’ailleurs, vous pouvez réussir à compiler toutes vos différentes vidéos - si vous en aviez plusieurs - et puis présenter, pour chacun des problèmes, un moment de démarrage différent. Ça va être très pratique et vous permettre de gagner beaucoup de temps.

Mais ce n’est pas tout, il faut encore définir l’importance du problème. Vous avez une classification des différents problèmes, que j’aborde dans le podcast #1 sur les évaluations heuristiques. Il y a plusieurs systèmes de classification, je ne vais pas les rappeler en détail, mais on a souvent quatre gradients : A, B, C, D. : « A» étant archi critique et « D » étant à garder de côté pour un autre projet. Donc pour chacun des problèmes que vous aurez identifiés vous apportez une échelle de notation pour déterminer son importance.

Si vous êtes arrivé jusqu’ici, c’est très bien, mais vous n’êtes qu’à la moitié de la démarche de travail.

Il ne s’agit pas seulement d’identifier un problème, il s’agit surtout de proposer une solution. C’est votre proposition de solution qui devra se retrouver dans le jeu via votre outil de planification, donc, plus que la description littéraire d’un problème c’est ce qu’on fait pour améliorer la qualité du jeu.

De même, cette solution, vous commencez avec une description littéraire, textuelle, courte et précise, mais vous devez présenter aussi un mockup pour expliquer plus précisément la solution de façon graphique. Dans le jeu vidéo parfois ça se passe de façon un peu plus dynamique, donc si c’est pertinent passez par un prototype interactif. Évidemment, ça peut être beaucoup plus long, beaucoup plus lourd, mais voilà globalement c’est cette démarche-là.

Alors moi dans une pratique professionnelle, ce type de gabarit je ne le remplis pas toujours de façon rigoureuse. J’ai souvent à faire à des studios qui sont pressés, déjà parce qu’ils n’ont pas forcément de gros budget ni beaucoup de temps, ils ont donc tendance à mettre en avant une démarche d’évaluation heuristique plutôt qu’une démarche d’évaluation par playtest. Donc juste de pouvoir faire des playtests c’est rarissime alors, faire des playtests dans des bonnes conditions c’est encore plus rare.

Ça dépend beaucoup des attentes du client. Certains clients auront des attentes sur le fondement scientifique et le côté objectivable de votre démarche, donc avoir un support vidéo c’est toujours très bien. Ce que je vous encourage à faire de toute façon c’est de commencer votre rapport d’une façon beaucoup plus décontracté. Donc vous commencez quand même à reporter directement les problèmes sur le papier. Je vous mets quand même en garde, cette histoire de gabarit c’est quand même une aide pour distinguer d'une part ce qui relève de l'observation de comportement et d'autre part, ce qui relève de l'interprétation des problèmes. Donc, reprendre ça ensuite un peu plus au propre si vous avez le temps - si vous en avez la possibilité, c’est quand même une façon supplémentaire de vous prémunir contre un problème de biais, d’interprétation et de peut-être considérer d’autres problèmes possibles et d’autres solutions possibles qui pourraient être plus efficace et moins coûteuse pour votre entreprise.

Voilà, c’était un récapitulatif rapide sur la façon de remplir un gabarit de playtests. Je reparlerai probablement de playtests parce qu’il y a beaucoup d’autres choses à dire. Je parlerais plus en détail de protocole de test donc des histoires de procédure, d’autoconfrontation, d’autoconfrontation croisée, d’exploration conjointe, et autres. Ces trois-là sont vraiment mes trois favoris. Ce genre de « jargon » on le verra plus en détail dans un prochain podcast. Et en attendant si vous avez un commentaire n’hésitez surtout pas à réagir ça peut aussi aide à bonifier cette démarche.

Merci et à 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 : Inès Sanchez

Édition : Stéphanie Akré

Nous souhaitons remercier chaleureusement Gordon W. Hempton The Sound Tracker® qui nous a fait don de la totalité de sa merveilleuse bibliothèque de sons récoltés dans la nature.