Participation à la refonte complète du double SaaS du service Pajemploi

Contexte client : Une équipe de trois personnes (Une Product Owner et deux UX designers) étaient sur la refonte du site Pajemploi, mais l’un des designers devait être remplacé.

Mon rôle : Je suis arrivé sur le sujet en tant que Senior Product designer, dans une équipe formée d’une product owner dédiée et d’une UX designer plus senior. Mon rôle était de pouvoir montrer mes appétences et compétences en termes de qualité et de rapidité dans le delivery, tout en montant d’autant plus en compétences sur la partie discovery.

Organisation : Nous étions organisés sur des sprints de 6 semaines, allant de la discovery au suivi du développement en passant par le delivery, des ateliers et des tests utilisateurs:

• • Daily avec la PO et l’autre UX de manière systématique tous les jours
• • Ateliers métiers 2 à 3 fois par semaine en fonction des besoins, avant, quand ils étaient disponibles, l’équipe projet côté Direction des Opérations
• • Point Design System de manière hebdomadaire avec toute l’équipe design (une dizaine de designers)
• • Des points réguliers avec l’équipe de développement en fonction des besoins (un point hebdomadaire en général), notamment pour être en phase côté recette et accessibilité numérique.
Pour chaque sprint, chaque designer travaillait sur un parcours différent, ce qui permettait d’avancer sur deux parcours en parallèle chaque 6 semaines, une organisation mise en place en vue de la taille du projet.

Démarche UX research

Pajemploi étant divisé en deux SaaS distincts, celui pour le Parent employer et celui pour les Assistantes Maternelles (AssMat) ou les Gardes d’Enfants à Domicile (GED), il fallait, avant de commencer à étudier les parcours, analyser les besoins réels des utilisateurs.

Pour ma part, la partie Discovery de la partie Parent employeur avait déjà été réalisée quand je suis arrivée sur le projet. J’ai néanmoins pu travailler sur celle visant les AssMat.

Le processus se déroulait en plusieurs parties:

• • Etude terrain afin de comprendre les différents besoins des utilisateurs, notamment par leurs commentaires sur les réseaux sociaux
• • Analyse des outils utilisées par ces mêmes utilisateurs (benchmark), comme, par exemple, AssMat-facile
• • Rédaction d’un question utilisateur afin de faire des entretiens, suite aux premiers insights soulevés
• • Animation d’interviews d’AssMat et de GED afin de comprendre leurs besoins (et d’entendre leurs revendications)

Ensuite, avec ma collègue UX, nous avons mis en place un certains nombres de supports:

• • Une liste de 5 personas, afin de voir les différentes typologies d’utilisateurs
• • Une cartographie d’expérience, notamment pour analyser, à travers tous leurs parcours complexes, toutes les frictions qui pouvaient apparaître.
• • Ensuite, en atelier de co-conception avec les métiers, nous avons mis en place du map de priorisation impact/effort, permettant de voir ce qu’il était possible de faire ou non, et dans quels délais.
• • Réalisation d’un story-mapping, afin d’analyser les fonctionnalités à mettre en place et leurs priorisations.
• • En est ressorti ensuite, d’abord, l’arborescence de la plateforme, permettant de visualiser la navigation, puis un diagramme permettant de visualiser les différents scénarios d’usage que pouvait avoir l’utilisateur sur tel ou tel parcours.

Livrables

Un lien Klaxoon concentrant tous les supports cités préalablement :

• • 5 personnes
• • Une Experience map
• • Une map Impact / Effort
• • Un story mapping
• • Une arborescence
• • Un diagramme de scénario

Quelques exemples de livrables :

Démarche UX product

Pour chaque sprint, qui, rappelons le, faisait 6 semaines, avec, pour chaque designer, un parcours dédié :

• • Réalisation pendant une semaine de l’analyse de la démarche Discovery afin de mettre en place les premiers écrans grâce au design system (tout en travaillant, en parallèle, à la recette des developpeurs pour le sprint précédent)
• • Ensuite, étude des premiers écrans réalisés avec les métiers en ateliers de co-conception, afin que chacun explique ses choix et que l’on puisse voir ensemble ce qu’il fallait garder ou non, faire évoluer, tout en itération. Pour chaque atelier, utilisations de différents posts-it afin de tous être d’accord sur la finalité des réunions : Vert (OK), Orange (à traiter), Rouge (hypothèse), Orange (à tester), Bleu (Règle de gestion)
• • Réalisation en parallèle du prototypage des parcours, pour, si besoin, mieux visualiser les interactions (généralement, 2 semaines)
• • Validation des parcours de la part de l’équipe projet côté Direction des Opérations.
• • Réalisation du protocole de tests utilisateurs afin de pouvoir valider ou non les décisions prises lors des ateliers.
• • Pour chaque parcours, animation d’une dizaine de tests utilisateurs (en moyenne) afin d’avoir un nombre assez représentatif de retours.
• • Réalisation d’un document PPT de restitution des tests utilisateurs, avec une version résumé des tests et une version plus détaillée en fonction des besoins des parties prenantes
• • Présentation du document à toutes les parties prenantes et validation ou non des modifications à mettre en place, en étant force de proposition face aux diverses frictions et en défendant la voix de l’utilisateur au maximum.
• • Corrections du prototype et livraison aux développeurs
• • Suivi du développement tout en attaquant le sprint suivant.

Livrables

Pour chaque sprint, qui, rappelons le, faisait 6 semaines, avec, pour chaque designer, un parcours dédié :

• • Un fichier figma avec les différentes itérations de parcours afin d’avoir bien tout l’historique d’évolution
• • Un lien klaxoon avec les historiques de ce qui a été écrit et décidé par atelier
• • Un protocole de test (fichier excel)
• • Un document de restitution de tests (fichier PPT)
• • Un document (PPT ou Figma selon les besoins) de retour de recettes pour les développeurs

Quelques exemples :

Résultats et impacts

• • La majorité des participants aux tests utilisateurs ont apprécié les améliorations apportées aux parcours proposés.
• • Une refonte complète de la plateforme dans des délais plus réduits que prévus
• • Une satisfaction des équipes avec qui j’ai pu travailler (dont une recommandation LinkedIn de la part de la PO)

Je n’ai pas eu accès aux retours utilisateurs après le déploiement. Les observations présentées ici portent sur les tests réalisés pendant ma mission.

Apprentissage

• • Travail en réelle complicité avec une autre designer et une Product Owner, ainsi qu’avec tout un ecosystème plus complexe que ce que je connaissais avant (équipe produit, équipe projet, équipe UX de taille moyenne, métiers)
• • Découverte des vrais enjeux de l’accessibilité, et de comment créer des interfaces qui y répondent de manière concrète
• • Rédaction de protocoles de tests, animations des tests, et restitutions de ces derniers.
• • Mise à niveau sur la phase de discovery (mes anciennes expériences étant plus basées sur des demandes clients directes ou de la data)