En tant que Product Owner et UX Designer, on s’est rendu compte que notre organisation ne fonctionnait pas. On ne trouvait pas l’équilibre entre les besoins et envies des utilisateurs (qui arrivaient tout juste dans l’équation du projet), les enjeux business ou encore ceux de la technique. Si on avait tout le monde autour de la table, la question ne se poserait pas. Pour y parvenir, la meilleure façon de faire était pour nous le _Design Sprint_©. On a décidé de l’étudier et de se l'approprier pour trouver notre équilibre.
Nos incréments produit ne nous donnaient pas satisfaction. On jonglait entre les directives des business owners, les fortes contraintes de l'existant et les processus métier, sans trouver de véritables solutions viables pour cadrer efficacement nos sujets fonctionnels.
Nous avions besoin de parer au manque d’information lié à notre contexte : une organisation silotée et agnostique des méthodes de design. Ajoutés à ça, une grosse partie d’existant dans le système informatique, de nombreuses parties prenantes et de forts enjeux stratégiques. Tout cela a affecté notre fonctionnement au fur et à mesure.
Désormais, notre objectif était clair, il fallait réunir tout le monde autour de la table pour que chacun soit au même niveau d’information et puisse avoir son mot à dire dans la construction.
“Octobre 2021, toutes les équipes de la DSI se retrouvent en “Team Breakout” (Rituel clef de la méthodologie SAFe qui permet de discuter des dépendances entre les équipes). Chacun remplit son board de post-its bien disposés sur les 5 prochains sprints. On a tiré les ficelles de dépendances sur le board commun, estimé la complexité et priorisé les sujets. Les designers ont déjà préparé leurs maquettes. On avait tous les éléments pour partir sereinement.
La PO demande alors l’indice de confiance : “On est comment là par rapport à nos objectifs ?”
Indice de l’équipe : “2 sur 5… on ne sait pas si le legacy nous envoie les infos, on va peut-être devoir refaire une API, ça vaut le coup d’investir pour cette fonctionnalité par rapport à la valeur utilisateur?”
À la suite de cette journée intense de PI Planning, nous nous sommes retrouvés autour d’un verre. Nous étions tous d’accord sur le fait que depuis le début du projet, 5 mois auparavant, nous n'avions jamais rencontré cette situation. Surement dû au projet qui a commencé par le développement d’un produit qui était semblable à un produit existant. Pour plaisanter, nous nous sommes dit qu’un Design Sprint nous aurais permis d'y voir plus clair.
On a commencé par étudier précisément le Design Sprint mais aussi ses dérivés, comme le design Sprint Quarter. Tous avaient un point commun, 5 jours d’ateliers où tout le monde était ensemble pour résoudre un problème. Leur objectif était de réunir tout le monde pour que chacun soit au même niveau d'information et puisse avoir son mot à dire. Ce qui était impossible à organiser dans notre contexte. Mais nous avons décidé de tenter le coup, malgré les contraintes organisationnelles que nous avions.
Le processus était clair dans nos têtes, il nous fallait maintenant impliquer les parties prenantes que nous souhaitions réunir pour échanger.
Après lui avoir exposé notre idée, notre premier allié a été le directeur produit qui nous a alors laissé carte blanche pour remédier à la situation. Avec une confiance aveugle, il a donc porté notre voix auprès des business owners et des représentants des opérationnels :
dans un premier temps : on avait besoin des business owners pour connaître les enjeux business et définir notre challenge ;
ensuite il nous fallait préparer les ateliers, trouver des créneaux pour avoir des représentants opérationnels tout le long ;
enfin, une personne pour trancher efficacement lorsque le débat s'éternisait : le temps est précieux, on ne pouvait pas se permettre de digresser trop longtemps !
Tout le monde était embarqué, on pouvait désormais dérouler la méthode.
On a joué notre version des ateliers du Design Sprint sur 2 semaines :
définir un challenge : on identifie la problématique ou le besoin utilisateur auquel on souhaite répondre pendant cette série d’ateliers et comment mesurer leur réussite. #KPI
diagramme de l’expérience : on construit un schéma d'expérience et on identifie les acteurs clefs.
how might we ? : séquence d’interviews des sachants sur notre sujet fonctionnel et on identifie les questions auxquelles on souhaite répondre au format “Comment pourrions nous…”.
suite à ça on définit l’acteur cible (profil utilisateur) et l’événement cible (où on souhaite intervenir au sein du parcours).
on met à jour le diagramme tout au long pour avoir une vue globale sur les décisions prises au fur et à mesure.
ASTUCE 💡
Il est crucial que tous les membres de l’équipe cœur (en l'occurrence : Product Owner, UX/UI Designers, Product Manager et différents spécialistes sur le sujet à cadrer) gardent le cap et suivent toutes les discussions efficacement lors des ateliers tout en assurant leurs tâches du quotidien. C’est pourquoi nous avons mis en place un questionnaire de suivi pour identifier au plus vite si l’implication demandée était trop lourde à porter au quotidien, et adapter si besoin nos demandes de participation. Également, à chaque fin d’atelier, on établit un ROTI (Return On Time Invested) pour évaluer la pertinence du temps passé sur l’atelier par rapport à ce qu’il a apporté au niveau de la prise de décision, des échanges et des informations.
ASTUCE 💡
Lors du sketching, on a tendance à oublier que tout le monde n’est pas l’aise avec l'exercice, pour cela nous vous recommandons de prévoir des composants graphiques sur papier (si c’est en présentiel) ou digital (si c’est à distance) pour leur permettre de schématiser rapidement leurs idées sans avoir peur de mal faire ou d’avoir le syndrôme de la page blanche. Et bien prévoir des inspirations et tout le matériel nécessaire en amont.
Enfin on partage au reste de l’équipe, on commente et on vote (n’hésitez pas à aller plus loin et à itérer si vous avez l’occasion, des participants à l'aise et le temps disponible)
Les designers peuvent désormais partir sur le prototypage à partir des sketchings !
On prépare le protocole de test et on lance les tests utilisateurs. (Avec un panel anticipé à l’avance c’est mieux pour être dans les temps 😇).
ASTUCE 💡
Dans notre cas, nous avons fait appel à Testapic, qui est un service qui propose de fournir un panel de testeurs sur profil. Mais si vous avez déjà une communauté de testeurs, c’est aussi l’occasion de faire appel à eux.
On n’aurait pas oublié quelqu’un ? 🤔 🚨
En effet, pris dans notre élan de création et d’harmonisation des décisions on en avait presque oublié l’essentiel : intégrer l’équipe technique dans nos choix. 🫣
La sentence tombe : sur les deux sujets sur lesquels on a travaillé, on se retrouve avec un go pour le sujet mineur et un no-go sur le majeur.
La raison, vous la devinez : impossible à réaliser techniquement en l’état. Après cette belle leçon, on décide d’avancer sur notre sujet mineur et on se relance dans une nouvelle itération de la démarche.
Tout se joue sur l’optimisation du temps en atelier et des plannings
Simplifier l'accès au sketching pour mettre tout le monde à l'aise
S’assurer du suivi de la motivation et l’implication de tout le monde
Prendre le temps de construire une communauté ou faire appel à un prestataire pour vous fournir un panel d’utilisateurs, pour le solliciter et s'assurer de sa disponibilité en fin de sprint.
Dans ce deuxième article.. Nous verrons comment nous avons poursuivi notre quête du graal avec les chevaliers de la technique.