Michelin – M2I

Je suis intervenu sur un projet de nouvelle application pour l’entité Infrastructure appelé M2I. Cette application a comme objectif de cartographier les différents flux de données chez Michelin.

Aujourd’hui, une multitude de petites applications existantes faisant office d’outil de visualisation sans que cela soit. Cette application répond à une problématique forte : Identifier à quel moment le flux s’arrête et pour quelle raison ? Cela permettra de :

Le dernier objectif a été retiré du MVP, car l’application aurait des droits administrateurs bien supérieurs aux autres apps, ce qui amènerait une couche de sécurité. Les ends-users ont placé ce besoin bien plus bas par rapport à d’autres.
Mon intervention UX/UI a débuté par un Design Sprint de 3 jours afin de cadrer l’objectif et d’obtenir un alignement des end-users entre le business et les fonctionnalités attendues.
Le challenge a été de faire entendre les points de vue de multiples acteurs (Analyste Fonctionnel, Architecte, Support, Ingénieur de Fiabilité des Sites, Devops, Développeur, PO) afin de trouver les points communs/différences qui vont définir l’importance des fonctionnalités.
Durant ce Design Sprint, j’ai coanimé avec deux coachs lean et agile auprès de 26 participants et en étant le seul UX/UI Designer dans ce projet.
Ces trois jours se sont articulés de la manière suivante :

• 1er jour, nous avons axé notre première journée sur le besoin. Nous avons travaillé en groupe, autour de l’outil cadre Lean UX Canvas pour préciser les enjeux et les bénéfices attendus pour les utilisateurs au sens large. Pour cette raison, nous avons fait le choix de ne traiter qu’une partie de ce template (jusqu’à l’étape 4 user outcomes and benefits). Afin d’aligner l’ensemble des participants, nous avons également fait un travail d’ux writing pour définir ce qu’est un ‘flux‘ dans la future application. Par la suite, nous avons défini de manière plus précise à travers les proto-personas les besoins et le contexte en lien avec nos objectifs.
  J’ai reformulé les différents besoins présents dans les proto-personas en ‘comment pourrions-nous…’. Cet exercice sert à préparer la phase de divergence du lendemain.
• À partir des questions, ‘comment pourrions-nous…’ nous avons pu commencer à parler de fonctionnalités en itérant avec un crazy 8’ en se focalisant lors de chaque session sur 1 ou 2 problématiques ‘comment pourrions-nous… ?’.
  Puis nous avons fait une double phase de convergence représentée par du wireframe (par groupe puis collective). Pour aider à diverger, j’ai planifié une phase de benchmark en amont de l’idéation. J’ai mis en place un dot voting lors de la convergence collective pour forcer les participants à prioriser par eux-mêmes qu’est-ce qu’ils jugent le plus nécessaire
• Le dernier jour a servi à construire le story mapping à partir des fonctionnalités ressorties du dot voting de la veille.

Le choix de ne pas effectuer la phase de validation est justifié par la présence de l’ensemble des persona au cours de ce Design Sprint.
Ce Design Sprint a été un défi pour forcer les utilisateurs à ne pas se focaliser tout de suite sur la solution sans se poser la question du pourquoi. J’ai également cherché constamment à garantir la vision du produit tel qu’elle a été définie au premier jour.

J’ai synthétisé les maquettes sur Balsamiq en améliorant l’architecture de l’information et en commençant à intégrer les grandes règles du Design System Michelin (disposition du menu et choix des composants en particulier).

Suite au MVP, j’ai animé un exercice de design studio sur le modèle de la phase de divergence (crazy 8’) et convergence (wireframe) avec l’équipe projet pour faire les écrans de la phase 2 du projet. J’ai fait un focus lors de cette phase pour appliquer différentes règles selon la forme employée dans le schéma (rectangle bordure pointillée = système, cercle = composant,…).

ObjectifAnimation d'un design sprint et design d'un nouvel outilMissionDesign sprint, Design studio, WireframeRéalisation2024