Cas pratique : Comment intégrer une conception orientée utilisateur·rice dans un projet long terme en méthode agile ?
Bonjour et bienvenue cher·ère lecteur·rice :)
Je vais vous présenter comment nous avons intégré une conception orientée utilisateur·rice lors d’un projet de deux ans.
Nous avons participé (Jean-philippe Heurtier, Vladimir Roybet, Rachid El Abouti et moi) au premier hackathon du SIDO (le plus grand salon sur l’IoT, l’intelligence artificielle et la robotique d’europe) en avril 2016. Le hackathon était organisé en partenariat avec Michelin, Sigfox et Renault Trucks. Nous devions réfléchir sur la thématique de la Truck Tribe Generation et la digitalisation du métier de chauffeur·e poids lourd.
On ne se rend pas vraiment compte quand on n’est pas dans le milieu du poids lourd, mais ce métier a beaucoup d’avantages pour les personnes qui aiment conduire, voyager, passer du temps seul, se sentir libre, etc. En revanche, ce métier-passion a aussi quelques contraintes :
- légales : le temps de conduite est limité à 8 heures par jour avec des pauses de 45 minutes toutes les 4h (NDLR et d’autres règles assez complexes sur ce sujet)
- métiers : respecter les horaires de livraison malgré un trafic dense, ou passer par un itinéraire inadapté au chargement du camion à cause de matière dangereuse (ADR), d’une hauteur d’un tunnel insuffisante, etc.
- personnelles : certain·e·s chauffeur·e·s peuvent passer jusqu’à 3 semaines isolé·ée·s dans leur camion en traversant l’Europe. Il faut alors penser à organiser l’intégralité de sa vie autour de son travail : où passer la nuit en sécurité (le la chauffeur·e, le camion et son chargement), où manger, où faire une toilette décente, où voir un·e médecin, comment garder le contact avec sa famille, ses ami·e·s, ses collègues, etc.
En deux jours de brainstorming et de prototypage, nous avons essayé de trouver des solutions à toutes ces problématiques. Notre équipe a proposé une application mobile mêlant un réseau social pour favoriser les interactions et le partage de connaissance ainsi qu’un agrégateur de services indispensables pour les chauffeur·e·s.
À la suite de l’événement, Michelin nous a demandé de prolonger l’expérience du hackathon et de produire un proof of concept du projet présenté lors de l’événement. Nous avions quatre mois devant nous pour créer une application fonctionnelle avec un périmètre limité.
Nous avons dû nous mettre en ordre de bataille rapidement, équipe, planning, bureau, etc.
Composition d’une équipe pluridisciplinaire
Nous voulions commencer par de la conception pour dégrossir, éclaircir un peu le terrain, définir un minimum l’architecture de l’information et l’architecture technique… Les deux premiers sprints* du projet ont été consacrés à la conception des premiers scénarios d’usage, des premières interfaces et pour finir à la définition de l’architecture technique à mettre en place.
Pour la bonne réalisation de cette étape, l’équipe était composée uniquement :
- d’un designer d’expérience utilisateur·rice (UX)
- d’un directeur artistique (UI)
- d’un ingénieur en recherche et développement
- d’un scrum master
- du product owner Michelin (PO)
Ensuite, au début du troisième sprint nous avons intégré deux développeurs, un front-end et un back-end pour commencer les développements.
Mise en place de la méthode de travail
Comme tout projet de recherche, nous avions un terrain de jeu, mais pas forcément de cadre précis et de besoins fonctionnels détaillés, nous avions pour unique mission d’expérimenter. Pour réussir cet objectif, nous avons choisi de mettre en place une méthode de travail agile avec le framework SCRUM en sprints de deux semaines. Cette méthode permet de gérer un projet de manière itérative, de donner de la visibilité régulièrement sur l’avancement des actions et d’avoir un produit testables rapidement.
Voici un descriptif des cérémonies nécessaires au bon fonctionnement d’une équipe avec cette organisation :
- Daily meeting : tous les jours, l’équipe se réunit 10 à 15 minutes maximum pour faire un point individuel sur les actions menées la veille, les problèmes rencontrés, les actions à mener aujourd’hui et les potentiels freins.
- Point backlog : listing priorisée de toutes les tâches à faire. Le backlog est revu au quotidien afin de l’enrichir, de le détailler, de l’élaguer ou de le réorganiser.
- Démo : réunion collective dans laquelle l’équipe présente toutes les actions menées pendant le sprint.
- Rétrospective : suite à la démo, tous les membres de l’équipe s’expriment sur leurs motivations, blocages, freins et objectifs.
- Poker planning : réunion collective permettant un échange sur les tâches à faire dans le sprint suivant ainsi que la définition du temps à passer sur chacune.
Une fois l’équipe et la méthode choisies, comment bien faire travailler les gens ensemble ?
Dans un projet agile, tout le monde est dépendant des uns et des autres. En quelques mots, le product owner énonce son besoin à l’équipe, ensuite les UX/UI conçoivent les parcours utilisateur·rice et pour finir les développeur développent les interfaces et fonctionnalités nécessaires.
Notre principale crainte était de ne pas réussir à concevoir les scénarios suffisamment en amont pour que les développeurs aient assez d’éléments pour avancer sur leur partie. Certains scénari utilisateur·rice peuvent être très compliqués à concevoir et à designer (NDLR et prendre beaucoup de temps à l’équipe) alors que les développeurs vont les développer en très peu de temps.
Pour éviter ce problème, nous avons essayé de toujours conserver deux sprints d’avance de conception sur les développements. Entre les deux sprints, nous pouvions avancer, main dans la main avec le PO, pour garantir la cohérence avec le besoin exprimé. En tant que garant de la qualité du produit, le PO doit valider si le besoin fonctionnel est bien couvert par les scénari conçu par l’équipe UX/UI avant de lancer les développements. Une fois validé nous pouvions passer le relais aux développeurs.
Bien entendu c’est une utopie, l’équipe technique a pu faire remarquer en cours de sprint que l’équipe UX/UI avait oublié un cas d’usage (les cas d’erreurs notamment), ou encore qu’il leur fallait des éléments graphiques supplémentaires (des animations, comportement au clic, etc.). Ces petits oublis pouvant agacer, l’équipe UX/UI devait corriger le tir rapidement pour permettre à tous les membres de l’équipe d’avancer dans leurs tâches respectives, tout en ne négligeant pas les sujets en cours.
L’équipe était très soudée et bienveillante, mais comme disait Lénine :
“La confiance n’exclut pas le contrôle”.
Avant chaque démo, l’équipe UX/UI faisait une phase de recette fonctionnelle et graphique sur l’application, remontant la plupart des problèmes et oublis sur les interfaces. Tous les défauts étaient corrigés dans la foulée par les développeurs. Cette étape est très importante pour garantir la qualité du produit, mais aussi pour montrer au PO que l’équipe est rigoureuse et garantir une bonne relation.
Pour améliorer encore et toujours la qualité et le périmètre fonctionnel de l’application, le mieux est encore d’être à l’écoute des principaux intéressés !
Tester et itérer pour améliorer en continu
Ce projet est marqué par la proximité que nous avons pu avoir avec nos utilisateur·rice·s cibles. Dès le début, nous avons eu la chance d’avoir un contact privilégié avec des chauffeur·e·s poids lourd via une page Facebook privée. Nous avons mis en place des sondages et des tests A/B sur des maquettes, co-construit la roadmap en fonction de leurs besoins et priorités, échangé sur les bugs et difficultés rencontrées, etc. Nous avons aussi fait des tests utilisateur·rice·s sur des aires d’autoroute, des relais routiers et participé au 24h du Mans poids lourd pour présenter le produit — en grande pompe — et récolter des retours des utilisateur·rice·s cibles.
Pour sensibiliser toute l’équipe à la cause des chauffeur·e·s, tous ont participé aux événements et tests utilisateur·rice·s. A chaque fois, nous avons été accueillis chaleureusement, avons pu échanger facilement et librement. Après chaque prise de contact, nous comprenions un peu mieux le métier et ses contraintes, nous revenions avec plein de nouvelles idées pour améliorer les interfaces ou apporter de nouvelles fonctionnalités.
Les outils utilisés pour faciliter les interactions au sein de l’équipe
Dans une équipe pluridisciplinaire comme la nôtre, les cultures peuvent être différentes, il est néanmoins primordial de partager la même vision. Nous avons mis en place plusieurs outils pour nous faciliter la tâche.
- IceScrum : outil de gestion de projet scrum, il permet de gérer / suivre / analyser le backlog, les releases, les sprints, les stories, les tâches et les bugs.
- Axure RP : permet de réaliser des wireframes interactifs et de les publier en ligne pour faciliter l’échange et le partage d’information de conception.
- Sketch : permet de réaliser le design des interfaces.
- Invision : permet le partage de toutes les maquettes graphiques d’un site ou d’une application. Lié à Sketch via le plugin Craft, il permet aux développeurs d’extraire tous les composants (images, pictogrammes, etc.) et même d’avoir tous les spécifications graphiques (tailles, couleurs, typographies, marges, etc.) utilisés par le designer.
Après 2 ans et demi de projet, des centaines de wireframes et maquettes, des milliers de lignes de code, des partenariats, des tests utilisateur·rice·s sur des aires d’autoroute, dans des relais routiers ou à des courses de poids lourd, nous avons découvert un métier pratiqué par des gens passionné·ée·s, dévoué·ée·s et sympathiques. Cette ambiance et l’envie de faciliter le quotidien de cette communauté, a d’ailleurs été un facteur important de la motivation de l’équipe tout au long du projet.
Pour conclure, je pense qu’avoir une équipe pluridisciplinaire sur toute la durée du projet est un vrai plus. Être capable de solliciter n’importe quel corps de métier à n’importe quel moment nous a apporté de la flexibilité et de la réactivité. J’ajouterais aussi, comme dans tout projet, la bonne volonté des gens pour se rendre disponible et travailler en équipe et essentiel au bon déroulement d’un projet d’une aussi grande envergure.
Merci pour votre lecture, j’espère que la mise en pratique de cette méthode vous aura plue et que vous aurez l’occasion d’essayer ;) Si vous avez besoin d’un coup de pouce, n’hésitez pas, nous serions ravis de vous aider.
A bientôt.
