L’ergonomie en pré-prod : comment travailler sans prototype ?

J’ai échangé récemment avec un étudiant qui se trouvait face à un dilemne. Il avait bien compris la valeur ajoutée des tests utilisateurs, mais se trouvait coincé par l’absence de prototype du jeu pour apporter les réponses attendues par son équipe.

Cette problématique est classique en phase de conception. L’ergonome dispose heureusement de nombreux outils en dehors des tests utilisateurs qu’il peut mettre en oeuvre, du focus group à l’analyse concurrentielle, en passant par la construction de persona.

Mais pour l’ergonome qui a des questions bien précises auxquelles la meilleure réponse vient malgré tout de tests utilisateurs. Et j’ai une bonne nouvelle :
tant que rien n’est développé tout peut être fait!

Cet article vous présentera quelques outils pour réaliser des tests, même à partir d’un simple pitch.

7 solutions pour faire des tests utilisateurs très tôt dans la conception

On ne le répète jamais assez, plus l’ergonomie est prise en compte tôt dans un projet, meilleurs sont les résultats. Puisqu’il est humainement impossible au meilleur des concepteurs d’anticiper tous les cas d’utilisation tordus que les joueurs vont inventer pour s’amuser, détourner et dépasser les limites du jeu, confronter le jeu aux joueurs est encore la meilleure façon d’atteindre l’objectif et l’expérience que le designer veut lui faire vivre.

Tester tôt permet d’optimiser le temps et coût de développement sur des features, soit en évitant une phase de correction, soit en développant la meilleure solution du premier coup. Plus les résultats sont disponibles tôt, plus ils ont de chance d’être intégrés : rien de plus frustrant qu’un gros défaut d’utilisabilité, connu, mais qui n’a pas pu être corrigé faute de temps.

Ne pas avoir de prototype n’est pas une raison pour ne pas faire de tests utilisateurs dès le début du développement. De nombreuses solutions sont envisageables pour avoir de la matière à exploiter. Voici 7 approches pour réaliser des tests utilisateurs pertinents sans nécessairement avoir de prototype abouti.

Wireframing

Le “wireframing” ou storyboarding interactif est une méthode de conception bien maitrîsée des ergonomes IHM. La méthode consiste à réaliser des maquettes en fil de fer plus ou moins détaillées des écrans clés d’un site, d’une application ou d’interfaces. Ces maquettes peuvent être rendues dynamiques de façon plus ou moins avancée selon l’outil utilisé, allant de maquettes statiques jusqu’à des maquettes dynamiques très proches du résultat final en termes de fonctionnalités, mais sans habillage graphique.

Exemple : Maquettes des interfaces réalisée pour le jeu Symbiose

Situations de références (reference situations)

Selon le jeu en cours de conception, l’ergonome peut étudier des situations de référence, c’est à dire analyser soit des produits similaires, soit des produits totalement différents, mais qui présentent des points communs avec le système cible. Les situations de référence peuvent d’ailleurs ne pas du tout venir de produits, mais de situations de la vie réelle spontanées.

Exemple : Afin d’évaluer la fiabilité du gyroscope du casque EPOC, nous avons réalisé un test utilisateur sur le site dontclick.it Ce test nous a permi de vérifier si les interactions sans clic étaient viables avec ce dispoitif de contrôle
Exemple : observer des enfants jouant qu’ils sont des oiseaux dans un parc

Analyse de traces (traces analysis)

L’analyse de traces est une méthode d’étude basée sur le recueil et l’analyse de “traces de l’activité”. On s’attache dans ce contexte à recueillir des traces d’activités, comme des notes prises lors de sessions de jeu, des extraits videos, playthrough, trucs et astuces échangés sur des forums… Ces traces constituent des indices permettant aux ergonomes de reconstituer l’activité des utilisateurs et donc d’avoir une meileure compréhension de leurs comportements, difficultés et stratégies de réalisation.

Exemple : Afin d’assurer un gameplay dynamique, nous avons analysé des extraits vidéos de jeux dans lesquels les joueurs contrôlaient des bateaux en situation de combat, quel qu’en soit le genre. Nous avons ainsi confirmé que placer les canons sur les côtés du navire contribuerait à rendre le jeu plus nerveux.

Paper prototyping

Le prototypage papier est une approche souvent bien connue des game designers. Ils s’en servent pour tester leur concept, soit seuls, soit en jouant avec d’autres personnes.

Cette méthode est tout aussi efficace pour les ergonomes qui peuvent en tirer des observations, hypothèses et conclusions complémentaires à celles du game designer. Par ailleurs, cette approche est également adaptée pour tester et itérer très rapidement des pistes d’interfaces et des étapes de tutoriaux.

Exemple : Pour le projet iMA, nous avons storyboardé les tutoriaux, vérifié leur compréhension et ajusté l’enchainement des informations avant de les développer au format vidéo et de les intégrer dans le jeu.
exemple 2 : ergo du travail, conception d’aménagement d’usines

Simulation & jeu de rôle

La simulation est une mise en situation réelle durant laquelle le jeu repose sur l’imaginaire des participants. Des éléments factices remplacent de ce qui serait réellement utilisé par le joueur. Sur le modèle du jeu de rôle papier et grandeur nature, un “maitre de jeu” simule le jeu et explique au joueur son déroulement. Ce dernier est encouragé à agir comme s’il jouait, à dire ce qu’il ferait, ou par exemple, à le faire avec une manette non branchée.

ex : coeur avec ou sans wiimote, jeu de rôle grandeur nature

Processing

Processing permet de programmer des prototypes très simplement, même si l’on n’est pas programmeur et a l’avantage de s’interfacer très bien avec arduino, notamment, ce qui le rend intéressant pour prototyper des interactions même complexes sans perdre de temps sur des questions d’interfaçage. C’est un outil particulièrement adapté pour réaliser de petites briques de gameplay ou des modalités d’interactions sans interaction avec d’autres éléments. Processing permet également de traquer les interactions et performances du joueur et de les récupérer au format texte pour un traitement dans excel.

Le code produit n’est pas réutilisable dans le jeu, mais il est moins couteux et rapide de réaliser certains prototypes de cette façon que de développer le jeu entier (ou même avec game maker, ou des outils similaires)

exemple : test fatigue liée au vol dans iMA / comparaison modes d’input

Prototypage

Enfin, le prototype du jeu lui-même peut être un support de test. L’objet de l’article ici est de tester sans prototype, cela peut donc paraitre étrange de mentionner ici comme support de test ce dont on ne dispose pas. De mon expérience, quand on ne dispose pas de prototype, c’est souvent qu’on ne dispose pas de prototype montrable. Prendre en compte les besoins liés aux tests que l’on a besoin de faire au cours du projet dès la planification des tâches est très efficace pour disposer de prototypes testables avec une charge de travail raisonnable. Cela ne signifie pas réaliser un prototype “polished” a chaque fin de sprint, simplement d’identifier les éventuels points bloquants pour les tests, pour que l’équipe et l’ergonome n’attendent pas l’un après l’autre (ce qui de toute façon ne devrait pas arriver)

ex : modèle d’interaction avec LD bloc

Quelle répartition des tâches dans la production des supports de tests ?

Pour nombre de ces solutions, la charge peut être répartie entre l’ergonome et l’équipe de développement. Nous observons plus particulièrement trois cas :
L’ergonome prend en charge la conception du support de test. L’équipe est sollicitée ponctuellement pour vérifier sa compréhension des besoins de l’équipe, présenter ses propositions et valider les actions à mettre en oeuvre (itérer sur le support, tester le support, prendre les décisions à l’issue des tests)

Le tableau suivant indique le degré d’implication / répartition des tâches que peut avoir chacun, selon la méthode.
+++ : pilote et réalise les travaux
++ : réalise les travaux,
+ : pilote les travaux, a besoin d’intervenir

Who can do it ?
UX guys Game dev
Wireframe +++
Reference situation +++
Traces analysis +++
Paper prototyping ++ +
Simulation ++ +
Processing ++ ++
Prototyping + +++

Ces répartitions ne sont bien entendu pas limitatives : une case vide signifie que l’équipe de développement itenrvient ponctuellement lors de workshops d’alignement par exemple. Par ailleurs, rien n’empêche un ergonome avec des compétences en programmation de réaliser de façon autonome un prototypage, de même que rien n’empêche l’équipe de développement de réaliser des wireframe ou faire une analyse de traces s’ils ont des compétences en recherche scientifique et en psychologie.

Si on découpe chacune des méthodes en phases, le challenge lié à la méthode pour obtenir des données pertinentes, les analyser et en tirer des conclusions opérationnelles varie pour chaque méthode. Dans le tableau suivant, le nombre de + indique l’investissement relatif sur chaque phase de l’étude, pour un résultat pertinent.

Répartition de la charge pour tester selon les types de support
Préparation Réalisation Analyse Restitution
Wireframe ++ ++ ++ +
Reference situation ++ +++ ++ +
Traces analysis +++ + ++ +
Paper prototyping + ++ ++ ++
Simulation + +++ ++ +
Processing ++ ++ +++ +
Prototyping ++ +++ ++ +
  • L’analyse de trace demande plus d’efforts pour réunir le support à analyser, mais elle permet de passer très rapidement à la phase d’analyse.
  • L’observation de situations de références demande de la préparation pour que la situation choisie soit pertinente, mais surtout, l’observation en elle même peut être complexe à mettre en oeuvre.
  • La simulation demandera de nombreuses répétitions lors de sa mise en oeuvre pour affiner le déroulement de chaque session. Les sessions sont d’ailleurs exponentiellement plus longues qu’avec un prototype : comptez 1h de jeu de rôle grandeur nature pour jouer 10 minutes d’installation interactive.
  • Processing permet de recueillir facilement des observables par tracking, il faut encore analyser une quantité importante et souvent indigeste de données.
  • Enfin, le développement, c’est couteux en temps, même s’il faut le faire dans tous les cas.

Il existe certainement d’autres solutions créatives pour pouvoir tester un concept, une brique de gameplay, un choix de conception sans nécessairement avoir de jeu avancé entre les mains. Et vous, avez vous déjà utilisé ces solutions ? Cela vous a-t-il aidé ? En avez vous essayé d’autres ?

Leave a Reply

Your email address will not be published. Required fields are marked *