A serious escape game - jouer pour améliorer la qualité

A serious escape game

Ou comment impliquer les développeurs dans la qualité de l'expérience utilisateur — en transformant un test de documentation technique en escape game.

ContexteFuzzy Logic Robotics
Année2024
01 — Genèse du projet

Un utilitaire devient un produit

Le cœur technique de Fuzzy RTOS, considéré jusque-là comme un simple utilitaire interne, devient un produit à part entière, destiné à des développeurs aguerris. La question se pose alors pour l'équipe produit : comment accompagner au mieux ces utilisateurs dans la découverte de l'étendue des fonctionnalités du produit ?

Écrire une documentation n'est pas une tâche facile, ni agréable pour des développeurs. Un premier jet est fourni, mais il reste très succinct et difficilement accessible à des développeurs externes. Une repasse intègre des exemples de code, mais le résultat reste encore insatisfaisant.

02 — Le dispositif

Jouer pour améliorer l'expérience utilisateur

Plutôt que de retravailler ce document de la même manière encore une fois, je décide de le mettre à l'épreuve directement auprès des équipes internes, à travers un test utilisateur pensé comme un serious game.

Les buts sont multiples :
— Rendre tangible aux développeurs internes 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

Documentation existante testée lors de l'atelier
L'atelier est prêt, c'est parti !
03 — Déroulé du test

Trois équipes, un sas à ouvrir

Le contexte du jeu est donné en introduction, puis trois équipes sont formées. Chaque équipe doit relever différentes épreuves pour pouvoir finaliser le jeu.

  1. 01

    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é leurs connaissances mais ils sont très fatigués, ils ne peuvent pas manipuler eux-mêmes 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 rests 1h30 avant l'ouverture du sas pour compléter la documentation. »
  2. 02

    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.

  3. 03

    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.»
04 — Retour d'expérience

Ce qui en est resté

Malheureusement, toutes les épreuves n'ont 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.

Le résultat est 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'exemples 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'entretiens, 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.

  1. 01

    Un profil « super expert » sur-sollicité

    Les équipes avaient été divisées entre des profils plus ou moins experts, 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 sûrement été plus judicieux de l'extraire d'une équipe pour lui confier le rôle de coordinateur.

  2. 02

    Des problématiques techniques non levées

    Malgré une préparation technique en amont, certaines problématiques techniques n'avaient pas été levées, ce qui a entraîné des latences et de grosses attentes sur le développeur « super expert ».