A serious escape game

Ou comment impliquer les développeurs dans la qualité de l'expérience utilisateur
Fuzzy RTOS - Logiciel de gestion de robots industriels
Genèse du projet
Le cœur technique du produit, considéré jusqu'ici comme un utilitaire devient un produit à part entière. Ce produit est destiné à des développeurs aguerris. La réflexion de l'équipe produit se porte alors sur comment accompagner au mieux les utilisateurs dans la découverte de l'étendue des fonctionnalités du produit.

Ecrire une documentation n'est pas une tâche facile et agréable pour les développeurs.Un premier jet de documentation est fourni mais celle-ci reste très succincte et difficilement accessible à des développeurs externes. Une repasse est faite pour intégrer des codes d'exemple mais le résultat reste encore insatisfaisant.
Jouer pour améliorer l'expérience utilisateur
Nous décidons alors de mettre en place un test utilisateur de la documentation sous forme de serious game.

Les buts sont multiples :
- rendre tangible aux développeurs interne la difficulté d'accès au produit
- créer une cohésion autour de l'amélioration de la documentation
- lister les améliorations nécessaires pour rendre cette documentation publique
- passer un moment agréable afin de dénouer un problème complexe et inconfortable.

L'atelier est prêt, c'est parti !

Déroulé du test
Le contexte du jeu est donné en introduction. Puis 3 équipes sont formées, chaque équipe a différentes épreuves à réaliser pour pouvoir finaliser le jeu.
Contexte :
" Vous êtes arrivés sur la planète des robots, la seule façon de survivre sur cette planète est de savoir dompter des robots. Malheureusement, au cours du voyage vous avez tout oublié (ou presque), seuls les experts ont gardé leur connaissances mais ils sont très fatigués, ils ne peuvent pas manipuler eux même les robots.La documentation a aussi été partiellement perdue, il va donc falloir vous appuyer sur ce qu’il en reste et la compléter.Il vous reste 1h30 avant l’ouverture du sas. Ensemble vous devez apprendre à installer des Fuzzy RTOS, manipuler l’ensemble des robots que vous avez et compléter la documentation pour garder les connaissances acquises..En 3 équipes, vous allez avoir 2 à 3 épreuves à passer. Chaque épreuve validée augmente vos compétences et votre niveau de défense. "
Les points :
" Le pourtour du sas est divisé en 15, chaque épreuve complétée remplit une partie, une fois le sas activé, il peut s’ouvrir sans danger. "
Les épreuves :
" Pour chaque épreuve vous devez regarder la documentation existante, faire l’action requise et compléter la documentation. Attention ! Pour bien différencier la doc existante de ce que vous allez apporter, veillez à surligner vos modifications de la couleur de votre équipe. Si quelque chose pose question ou demande validation, mettez un commentaire. L’épreuve ultime sera le grand conseil pour valider l’ensemble des modifications. Vous pouvez vous répartir les tâches si vous le souhaitez. "

Symbole de chaque équipe et leurs épreuves

SAS d'entrée en début d'atelier

Epreuve de test en cours

Fin d'atelier, le SAS n'a pas pu être activé... KABOUM...

Retour d'expérience
Malheureusement toutes les épreuves non pas pu être menées à leur terme lors de l'atelier.
Des sessions de rattrapage ont été organisées en plus petit groupe par la suite.
Une amélioration significative de la qualité et de l'accessibilité de la documentation :
Les testeurs se sont laissés prendre au jeu et ont pris vraiment du plaisir à réaliser les différentes épreuves, à annoter la documentation, à apporter des idées d'exemple de code.
Tous ces retours ont été pris en compte, ils ont permis d'augmenter de façon très importante la facilité de prise en main de ce nouveau produit.
Au cours d'entretien, les primo utilisateurs nous ont confirmé que la documentation leur avait permis de passer les différentes étapes de prise en main et d'utilisation.
Les points à prendre en compte pour de prochains ateliers :
1- Les équipes avaient été divisées entre des profils plus ou moins expert mais au cours de l'atelier, un profil "super expert" s'est détaché. Le développeur portant cette casquette a été sur sollicité, il aurait surement été plus judicieux de l'extraire d'une équipe pour lui confier le rôle de coordinateur.
2- Malgré une préparation technique en amont, certaines problématiques techniques n'avaient pas été levées, cela à entraîner des latences et de grosses attentes sur le développeur "super expert".
AccueilHaut de page

Vous avez une question, une suggestion ?
Laissez moi un message :

Une suggestion, un commentaire, un petit mot.... n'hésitez pas !

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.