Les ergogames : un projet interne qui prend son envol

Comment rendre accessible à toutes les équipes de développement un concept testé et approuvé en interne ?

Depuis quelques mois, nous travaillons sur un projet interne avec mes collègues de Sogilis Lyon : développer une version web ouverte à toutes et à tous des Ergogames, un ensemble de petits jeux permettant de découvrir et de comprendre les bases de l’ergonomie (on en parlait ici). La vision de Sogilis étant de “rendre le développement informatique de meilleure qualité”, c’est pour nous important d’exploiter le travail de construction des jeux pour apporter notre contribution en partageant ces jeux afin qu’un maximum de personnes puissent les utiliser.

Initialement, les jeux ont été créés par Marion et moi, sous forme de maquettes interactives dans UX-Pin. Il y a un an, nous cherchions le meilleur moyen de les partager largement, considérant les contraintes de licence (utilisation d’images sous licence) et de maintenabilité dans le temps (maquettes UXpin) que nous n’avions pas pour un usage interne ponctuel. Après quelques mois de pause (faut dire que je suis partie pendant plus de 4 mois en congé maternité ^^) et au passage mon retour à Lyon me permettant de côtoyer l’équipe lyonnaise au quotidien, nous avons décidé que la meilleure solution serait de repartir de zéro pour développer un site web responsive et en profiter pour améliorer certains jeux.

Comme c’est un projet interne au sein d’une entreprise de services du numérique, la principale problématique était de dégager du temps pour mener à bien ce projet. Il a été décidé par le groupe de personnes motivées par le projet de le mener de manière itérative, en développant tout d’abord un MVP (sur les temps libres, pause déjeuner et autre) afin de tester rapidement le concept auprès de la communauté.

Nous avons ajouté la story “Mettre en ligne les Ergogames” dans notre Kanban d’entreprise (plus de détail ici) et listé les actions à mener :

• définir le MVP
• faire des maquettes
• estimer le temps de dev
• développer les IHM
• pré-tester les jeux
• prendre en compte les retours
• faire le buzz 😝

Ma collègue Marion et moi-même avons naturellement partagé le rôle de Product Owner et nous sommes penchés sur les 2 premières tâches, tandis que 3 développeurs ont participé aux développements : Kévin, Romain et Éric.

1. Définir le MVP

Pour définir le MVP, nous avons tout d’abord brainstormé sur notre cible et avons défini 4 pseudo-personas :

• Marlène : ergonome en entreprise, elle a entendu parler des jeux lors de sa veille sur Twitter et les a testés. Si elle est convaincue, elle pourra décider de les partager en interne, voire d’organiser un atelier en interne afin de sensibiliser ses collègues devs.
• Tahys : graphiste (mais qui pourrait être développeuse) qui souhaite monter en compétence sur le domaine de l’ergonomie. Elle a trouvé les jeux en cherchant comment se former via une requête Google et les utilise seule pour apprendre les bases d’ergo.
• Raphaël : ergonome freelance, il a entendu parler des ergogames et les utilise ponctuellement pour expliquer un concept à un client.
• Edith : décideuse dans une société de développement logiciel qui souhaite faire monter en compétence ses salariés. Elle a entendu parler des ergogames via un partage LinkedIn. Elle n’a pas d’ergonome en interne et nous contacte pour mettre en place le jeu dans l’entreprise.

En s’appuyant sur ces archétypes d’individus, nous avons défini le contenu minimum permettant d’avoir un concept testable et apportant de la valeur aux utilisateurs et aux utilisatrices. Nous avons ensuite dessiné un storyboard du parcours utilisateur afin de définir l’architecture du site et les écrans à maquetter.

Nous avons décidé de nous concentrer sur 2 jeux dans cette première version. Pour les choisir, nous avons mis en place un sondage sur le Slack de Flupa en demandant aux gens de voter pour les principes à adresser en priorité selon eux. Les principes d’homogénéité et de gestion des erreurs sortant clairement du lot, le choix n’a pas été compliqué.

2. Faire des maquettes et estimer le temps de dev

Avec Marion, nous avons fait ensemble les wireframes des écrans les plus simples (accueil, principes) dans Balsamiq, puis nous nous sommes réparti le travail pour le maquettage des deux jeux. Le principe général était déjà défini dans la version interne des ergogames : une consigne, un jeu “test” qui enfreint le principe, un jeu “contrôle” qui les respecte puis l’explication du principe, le tout entrecoupé par les écrans informant le joueur de sa réussite ou de son échec. Néanmoins, il a fallu repenser les jeux car :

• pour le principe Homogénéité : le jeu qu’on avait fonctionnait bien mais n’était pas très ludique, nous avons souhaité le retravailler pour le rendre plus amusant.
• pour le principe Gestion des erreurs : le jeu n’avait pas très bien fonctionné lors des sessions internes car la consigne était (volontairement) très vague ce qui avait généré de l’incompréhension, et il utilisait des images “Minions” sous licence.

Nous avons donc chacune réfléchi à la mise en pratique d’un principe, puis avons échangé pour améliorer les jeux.

En parallèle, Kevin a commencé à estimer le temps de développement sur la base du storyboard.  

3. Développer les IHM

Kevin a tout d’abord mis en place l’architecture du site. C’est à peu près à cette période que Sogilis a recruté un graphiste (Nicolas), que nous avons voulu intégrer au projet. Il a rapidement réalisé des maquettes graphiques pour les écrans principaux, et a proposé de fournir également le CSS, super !

C’est ensuite Romain et Éric qui ont repris le travail de développement. Dès que quelques écrans ont été disponibles, ils nous ont fait une première démo. À partir de là, nous avons fonctionné avec un process en flux dans Gitlab (plateforme de gestion de projet informatique) :

• les fonctionnalités à développer sont décrites par tous sous la forme de tâches
• Marion et moi les priorisons
• les développeurs développent chaque fonctionnalité sur une nouvelle branche, pour ne pas impacter les autres développements en cours
• Marion et moi validons les tâches lorsque le dev est terminé, si besoin nous faisons des commentaires pour modifier des choses
• quand la tâche est validée, la branche est fusionnée avec le code commun

Lorsque les tâches concernent des petites modifications de html / CSS, il nous arrive d’essayer de les traiter par nous-mêmes Marion et moi, avec nos maigres connaissances dans ce domaine. C’est à la fois stimulant de contribuer directement au développement du projet, et enrichissant de monter en compétence sur ce domaine.

Régulièrement, Romain nous débloque pendant les pauses déjeuner en nous montrant comment modifier le code pour arriver à nos fins.

Enfin, nous avons fait évoluer les règles de chacun des jeux au moins une fois chacun afin de mieux démontrer le principe, suite à des retours des développeurs. Le résultat final est donc vraiment collaboratif, que ce soit sur la conception ou sur le développement.

4. Apprentissages

Sur deux points j’estime qu’on aurait pu faire mieux. Mais comme disait Nelson Mandela :

Je ne perds jamais, soit je gagne, soit j’apprends.

Sur ce projet, j’ai donc appris 2 choses :

1. L’importance de la présentation des maquettes aux autres intervenants, dans toutes les circonstances. Je le sais, je prends généralement du temps pour détailler les interactions dans un document accompagnant les maquettes, et les présenter à l’oral, que ce soit à mes clients ou aux développeurs et développeuses avec qui je travaille. Mais pour un projet interne comme celui-ci, prises par le temps, nous n’avons pas fait cet effort. Les maquettes ont été livrées brutes, sans explication, partant du principe que les développeurs travaillaient à côté de nous et nous poseraient des questions s’ils avaient un doute. Ça aurait pu marcher, mais c’était sans compter l’appel à un ami pour la partie graphisme. Nicolas, qui travaille à Grenoble alors que le reste de l’équipe projet est à Lyon, a transformé nos wireframes en maquettes graphiques en y apportant quelques modifications. Quand nous les avons regardées, ces modifications ne nous ont pas sauté aux yeux, et les développeurs les ont utilisées comme nouvelle spec. Or certaines des choses qu’il avait modifié ne nous convenaient pas d’un point de vue ergo. Ces choses ont été remarquées seulement lors de nos tests de validation, et ont généré une perte de temps de développement pour modifier le code en conséquence. La même chose s’est produite sur le jeu que j’avais maquetté juste avant de partir en vacances. Prise par le temps, je l’ai livré sans détailler précisément ce que je voulais, et la première version du jeu développé ne démontrait pas du tout le principe. Si nous avions pris le temps de présenter les maquettes systématiquement, d’expliquer nos choix et de spécifier le comportement attendu, du temps aurait été gagné lors du développement.
2. L’importance d’être au clair sur ce qu’on veut faire avant de commencer le développement. Concrètement, j’ai lu très (trop) tardivement l’article de Bastien et Scapin (disponible en PDF ici) que nous citons en référence. J’avais lu beaucoup d’articles sur le web qui en parlaient, mais je n’avais jamais lu l’article original. Or, en le lisant, j’ai découvert que ce que j’avais toujours considéré comme appartenant au critère Protection contre les erreurs, à savoir l’affichage du format attendu pour une date par exemple, appartenait en réalité au critère Incitation (sous-partie du Guidage). De même, en lisant l’article je me suis demandée si le jeu que j’ai conçu pour illustrer le principe d’Homogénéité ne correspond pas davantage au principe de Distinction par le format (sous-partie de Groupement). Les pré-tests auprès de nos pairs vont permettre de prendre une décision sur ces sujets là, mais si j’avais lu l’article avant nous aurions peut-être conçu ces deux jeux différemment.

5. La suite

Le MVP est presque terminé ! Il nous reste quelques petites choses à modifier, puis nous pourrons commencer à tester les jeux sur un panel de personnes triées sur le volet :

• quelques ergonomes / UX designer pour vérifier que les jeux démontrent correctement les principes choisis
• quelques personnes d’autres professions du numérique (devs, graphistes, PO…) pour voir si elles trouvent les jeux attrayants et si elles comprennent le lien entre les jeux et les principes qu’ils illustrent

Pour en savoir plus sur la manière dont les tests utilisateurs vont être mis en place et analysés, il faudra attendre le prochain article !

À la suite de ces tests nous prendrons en compte les feedbacks, puis nous communiquerons largement sur les jeux pour les faire connaître. Nous avons déjà prévu un formulaire de contact qui servira à ce que chacun puisse nous faire des retours très simplement. Nous prioriserons alors les retours des joueurs avec le développement de nouveaux jeux, pour que le projet prenne de l’ampleur dans les mois et années à venir.

Edit : les Ergogames sont en ligne, c’est ici !