Introduction

Fleet est une start-up française créée en 2019 qui a pour mission de simplifier la location, la gestion et le renouvellement de la flotte informatique des PME via un service clé en main. Côté produit, Fleet propose à ses clients un accès à leur plateforme SaaS, le Cockpit, afin d’expérimenter leur proposition de valeur.

Le marché de la location d’ordinateurs chez les professionnels s’est considérablement développé ces dernières années eu Europe. La crise sanitaire et économique a acceleré ce processus : la location permet aux entreprises de s’équiper sans s’endetter, de proposer à ses employés un appareil à la pointe des dernières technologies pour une meilleure productivité (jusqu’à 109h perdues / an à cause des lenteurs informatiques *) en plus d’améliorer la marque employeur.

* Étude Easy Panel - 2013

0. Brief / Rôle

En 2021, Fleet a vu le nombre moyen de devices enregistrés dans le Cockpit se multiplier par 4 et continue d’attirer de nouvelles entreprises, toujours plus grandes. Il est donc primordial que la plateforme SaaS puisse répondre aussi bien aux problématiques d’une start-up de 5 employés que d’une scale-up de 500 collaborateurs aux besoins plus spécifiques tout en conservant sa simplicité d’utilisation.

C’est dans cette optique qu’une refonte UX/UI de la plateforme avec la mise en place d’un nouveau design system a été décidé. Mon rôle consistait à concevoir en collaboration avec un design studio externe et l’équipe Produit les parcours utilisateurs, wireframes, prototypes interactifs, mockups et composants de cette nouvelle plateforme tout en assurant une user research en continu.

1. Découverte

La phase de Découverte est primordiale pour comprendre qui sont nos utilisateurs, leurs usages de la plateforme et leurs besoins avant d’envisager toute solution. J’ai pu m’appuyer sur le travail déjà réalisé par mes précédesseurs avant ma prise de poste à travers des études quantitatives (sondages) pour reccueillir un maximum de retours des utilisateurs, l’analyse des données et des usages des utilisateurs sur la plateforme, la création des personas ou encore des entretiens utilisateurs afin de m’immerger rapidement dans le produit, comprendre les cas d’usages et les besoins de nos utilisateurs.

J’ai néanmoins itéré sur cette étape de Découverte par un audit UX de l’existant ainsi que par l’interview des équipes commerciales / support afin de remonter d’éventuelles points de friction des clients en plus d’apprendre à mieux connaitre mes nouveaux collègues 😉.

2. Définition

Les insights tirés de la phase de Découverte nous ont permis d’identifier les points bloquants et les besoins de nos utilisateurs. Nous pouvons alors enrichir au fur et à mesure nos personas, dresser une customer journey map et ainsi définir des problématiques pour chaque brique de la plateforme en tenant compte de la problématique globale :

Comment peut-on mettre à l’échelle la plateforme tout en conservant sa simplicité d’utilisation ?

Quelques enseignements / besoins utilisateurs issus de la phase de Découverte :

• Les IT managers veulent gérer l’intégralité de leur parc informatique, accessoires inclus et pas uniquement les appareils en location chez Fleet pour éviter l’utilisation de documents additionnels (ils utilisaient jusqu’à alors la partie commentaire d’un équipement pour y “associer” des accessoires)
• Les IT managers veulent attribuer un ou plusieurs équipements à un employé pour faciliter le suivi des équipements et l’offboarding de l’employé en cas de départ
• Les RH souhaitent pouvoir anticiper au mieux l’arrivée d’un nouveau collaborateur
• Les RAF souhaitent faciliter le suivi financier des équipements (par ex attacher une facture à un équipement)
• Les DG / manager souhaitent que les employés puissent créer eux-même les tickets au SAV lors d’un problème

3. Idéation

C’est à l’étape d’idéation que la solution commence à se dessiner progressivement. En nous appuyant sur les problématiques définies à la seconde étape, il nous est alors plus facile de brainstormer avec les équipes et d’émettre des hypothèses de solution à envisager, aussi innovantes et folles soient-elles.
Je suis à cette étape en charge de donner chair aux idées retenues par la construction de flux utilisateurs et de wireframes afin de rendre visuelles les solutions envisagées, pouvoir en débattre plus facilement et les challenger lors de design reviews avec l’équipe Produit chaque semaine.

💡 Pour assurer un bon déroulement des design reviews, j’ai pris pour habitutde de prévenir en amont les équipes des sujets de la design review à venir ainsi que tenir un “backlog” dans Figma afin de mettre par écrit les éventuelles modifications décidées et ne rien oublier en route.

Prenons l’exemple de Total Fleet, l’une des nouvelles fonctionnalités phares de la plateforme SaaS permettant aux utilisateurs d’ajouter des équipements et des accessoires non Fleet, sur lesquelles j’ai itéré :

La page existante ne permet pas d’ajouter un seul équipement facilement; ne prend pas en charge les accessoires; il faut télécharger un modèle .xls à remplir, plus proprice à du batch import, puis l’importer dans la plateforme.

La première proposition consiste donc à permettre à l’utilisateur de choisir le type d’équipement qu’il souhaite ajouter (device ou accessoire) puis d’y rentrer les différentes informations à son sujet. Pour un ajout rapide, il sera décidé que seuls le type d’équipement et son nom seront obligatoires, le reste des informations est optionnel. Pour répondre au besoin de nos utilisateurs d’associer une facture à un équipement, nous ajoutons une section document avec un uploader.
Conformément au design system en place, la feature est designée dans une modale plutot qu’in-page.

Afin de donner une meilleure lisibilité globale et éviter de devoir scroller excessivement à l’intérieur d’une modale, notre seconde proposition consiste à intégrer in-page notre formulaire d’ajout. Le design des boutons radio est affiné pour une meilleure harmonie avec le reste des composants et une redirection vers le batch import est proposée en haut de page.

Après de nombreux retours avec l’équipe produit, cette 3ème proposition consiste à intégrer la feature à l’intérieur d’un flow pleine page en plusieurs étapes pour réduire la charge mentale de l’utilisateur et assurer une cohérence avec la fonctionnalité de batch import.

Quelques itérations de plus nous ont permis d’arriver à notre solution finale : le stepper et le formulaire sont centrés au milieu de l’écran, la tab de sélection de la catégorie d’équipement est remplacée par les mêmes boutons radios que le type d’équipement, un texte informatif quant aux champs obligatoires est ajouté.

4. Prototypage & test

Brique après brique, notre solution prend vie. C’est alors le moment idéal de tester (et faire tester) notre solution auprès de nos utilisateurs à l’aide de prototypes intéractifs pour s’assurer que la solution correspond bien aux attentes de nos clients.
Si ce n’est pas le cas, nous pouvons itérer et améliorer la solution pour atteindre l’objectif souhaité.
Si l’équipe hésite entre deux solutions ou deux variations d’un écran, c’est également l’occasion d’écouter la voix de nos utilisateurs en mettant en place des A/B tests.

Nos prototypes sont réalisés à base de wireframes basse fidélité en noir et blanc afin de focaliser nos tests sur l'utilisabilité et la réponse aux besoins plutot que l'esthéthique.

À cette étape, toutes les parties prenantes sont réunies autour de la table pour valider (défintivement 🤞) quelle solution sera intégrée car la plus facilement réalisable, la plus viable, la plus centrée utilisateur, ...

💡 Les prototypes interactifs permettent également aux développeurs de s’imprégner de la solution et mieux se projeter sur les fonctionnalités et composants à implémenter lors des futurs sprints.

5. Lancement et itération

La solution est désormais sélectionnée et validée ! 🎉
Mon rôle consistait alors à produire et documenter, pour faciliter l’implémentation future par les développeurs, les maquettes haute-définition mais également les composants du design system établi.

Chaque composant du design system est documenté sous Zeroheight et comporte :

• une description du composant
• son anatomie
• ses variantes
• ses différent(e)s états / propriétés
• ses comportements (taille minimale, comportement au scroll, ...)
• quand utiliser ce composant
• comment utiliser ce composant (do’s and don’ts)

Enfin, des entretiens en continu avec nos utilisateurs permettent de nous founir des retours indispensables pour comprendre si les solutions mises en place répondent bel et bien à leurs besoins et nous permettre de toujours améliorer et perfectionner le produit mais également l’expérience.

La solution finale :