Étant la première UX/UI designer interne, ma première question fut : à qui s'adresse ce produit ? Quels sont leurs besoins, leurs points bloquants ? Comment les utilisateurs utilisent-ils Manaos ? Des personas avaient déjà été réalisés à la création de Manaos, mais jamais mis à jour. Une fois les personas définis, dès lors qu'un sujet s'ajoute à la roadmap produit, une étude est menée en collaboration avec le PO afin de comprendre le besoin et/ou le problème rencontré.
UX Research & Persona
Le contexte ?
Mon rôle ?
- Pour la mise à jour des personas de Manaos : j'ai animé deux ateliers avec l'équipe produit et l'équipe commerciale/marketing, pour créer de réels personas utilisateurs et non des personas clients.
- Lors de la création ou mise à jour d'une feature :
- Lorsque la feature existait déjà, je commençais ma recherche par l'analyse des chiffres Matomo pour comprendre l'utilisation actuelle, et j'approfondissais avec des entretiens exploratoires. Je complétais en échangeant sur le sujet avec les équipes en interne sur l'historique du sujet.
- Dans le cas d'une nouvelle feature, une étude de marché et un benchmark étaient réalisés avec le PO. Des échanges avec les équipes sales étaient aussi menés pour comprendre la demande utilisateurs/clients.

Atelier n°1 — création des macro-personas.

Atelier n°2 — création des personas finaux.

Atelier de définition du besoin — pour la mise à jour d'une fonctionnalité.

Customer journey mapping de la fonctionnalité existante avant revue.
UX design & maquettage Zoom parcours de reporting
Le contexte ?
Une fois la solution dans les grandes lignes définie, des user flows étaient réalisés pour comprendre l'intégralité du parcours (front & back) — ici un zoom sur le parcours de reporting — puis les maquettes étaient créées dans Figma avec le design system mis en place.
Mon rôle ?
J'ai réalisé le user flow pour ce parcours et maquetté les écrans avec le design system Manaos, en visant un maximum de réalisme pour préparer les tests utilisateurs.
User flow complet du parcours de reporting.



Maquettes des écrans développés pour cette fonctionnalité.
Tests utilisateurs
Le contexte ?
Pour apporter plus de réalisme, des prototypes sont créés et testés lors de 3 phases, avec itération sur les maquettes à chaque test.
Mon rôle ?
Je fais tester le prototype à trois publics successifs :
- Test avec le PO en charge du sujet et les développeurs de la squad
- Test avec l'équipe commerciale/expérience client
- Test avec de réels utilisateurs
Le résultat ?
Les résultats dans le cas du parcours de reporting : deux clients dont 4 utilisateurs ont effectué les tests utilisateurs, et les points suivants sont ressortis :
- Validation du funnel de création de rapport dans sa structure.
- Les rapports proposés sont les principaux, mais certains souhaitaient en voir de nouveaux apparaître dans la liste en fonction des nouvelles demandes réglementaires.
- Le plus gros point bloquant : l'écran récapitulatif des données lors de la création des rapports. Selon les profils, certains voulaient grouper par portefeuille, d'autres par NAV. L'amélioration UX implémentée fut la mise en place de la feature "Grouper par" dans le composant grid, avec un groupe par défaut mais modifiable par les utilisateurs.
Gouvernance design
Le contexte ?
Manaos n'ayant jamais collaboré avec un UX/UI designer en interne, l'une de mes premières missions fut de mettre en place une stratégie UX s'incorporant dans l'organisation produit — découpée en plusieurs squads par fonctionnalité.
Mon rôle ?
J'ai mis en place une stratégie transverse incluant toutes les parties prenantes : l'équipe commerciale (connaissance clients/utilisateurs), l'équipe produit (PO et proxy-PO), et les équipes IT (connaissance technique). Le tout basé sur les notions du Design Thinking et sur la méthode Scrum mise en place dans les squads, avec une fréquence de 3 semaines de sprint.
Process en 4 sprints — UX Research, Maquettes/Tests, Refinement, Delivery.
Suivi par squad — Team Kirby, Team Rocket, Team Yoshi.
Design System
Le contexte ?
Lors de mon arrivée, aucun design system n'avait été créé. Le but : homogénéiser le design et le comportement des composants dans toute la plateforme. Une fois ce système Figma assez mature, une mise à jour du storybook a débuté — le reflet des composants une fois intégrés et développés.
Mon rôle ?
J'ai créé le design system dans Figma en me basant sur le produit live (librairies MUI v6, AG Grid, Quicksight), en collaboration avec les développeurs front. Une fois ce système mature, j'ai piloté sa bascule dans Storybook : revue des composants existants, création de nouveaux, suppression de ceux non utilisés. J'ai pris la casquette de product owner sur ce sujet — chaque composant à modifier ou refaire fait l'objet d'un ticket Jira rédigé par mes soins.

Librairie de composants du design system Manaos.

Portfolio Coverage Estimation.

Paramètres — notifications email.

GREAT — comparaison du scoring ESG entre deux portefeuilles.

Marketplace — bibliothèque d'applications lors d'un guided tour.
Club utilisateur
Le contexte ?
En collaboration avec l'équipe commerciale, un club utilisateur a été mis en place en 2024, à destination d'utilisateurs de niche correspondant aux personas Manaos et souhaitant contribuer à l'amélioration de la plateforme.
Mon rôle ?
J'ai mis en place un événement annuel pour rassembler les utilisateurs sur des sujets communs. D'un point de vue UX, cela me permettait aussi de créer une base de données de personnes mobilisables pour des ateliers ou des sondages.
Inauguration du Club Manaos.