Expérience professionnelle · MONI
Expérience professionnelle · MONI
Expérience professionnelle · MONI
Product Design @MONI
Product Design @MONI
Product Design & Optimisation E-commerce (Prepaid & Airtime)
Product Design & Optimisation E-commerce (Prepaid & Airtime)
Product Design & Optimisation E-commerce (Prepaid & Airtime)
Métadonnées du projet
Métadonnées du projet
Métadonnées du projet
Rôle : Product Designer (Alternance)
Période : Septembre 2024 – Septembre 2025
Squad : Prepaid & Airtime (Vente de cartes prépayées & recharge mobile)
Stack & Outils : Figma, Amplitude, Metabase, Jira
Impacts clés : +15 % de conversion sur une étape clé d'onboarding • 30 % → 60 % d'opt-in notifications
Contexte & Périmètre
Contexte & Périmètre
Contexte & Périmètre
Chez MONI, j'étais intégré à la squad Prepaid & Airtime. Contrairement aux parcours financiers et réglementés (KYC, transfert de fonds), mon périmètre était focalisé sur une expérience proche du e-commerce : la vente en ligne de cartes prépayées et de recharges téléphoniques.
Mon rôle s'est articulé autour de trois piliers :
L'optimisation des parcours d'achat et de conversion.
L'exploration et la mesure des opportunités via la donnée produit (Amplitude).
L'alignement quotidien avec les développeurs et la contribution au Design System.
L'évolution stratégique vers le 100 % B2B : L'entreprise a pivoté d'un modèle mixte B2C/B2B vers un positionnement full B2B en marque blanche. Le système devait pouvoir adapter instantanément l'ensemble de l'expérience aux identités visuelles de multiples partenaires tiers (ex. Libon).
La migration technologique vers React : Vue.js n'étant plus mis à jour dans notre stack, l'équipe technique a acté la migration progressive vers React, adossée à la librairie Radix comme socle de composants non-stylisés.
Optimisation des parcours & leviers de conversion
Optimisation des parcours & leviers de conversion
Optimisation des parcours & leviers de conversion
Onboarding : Réduction des points de friction
Problème identifié : L'obligation de renseigner un numéro de téléphone représentait un goulot d'étranglement majeur à l'inscription.
Solution UI : Ajout d'une option secondaire permettant d'ignorer temporairement cette étape (skip).
Résultat : +15 % de passage à l'étape suivante et +3 % sur la conversion finale du parcours.
Onboarding : Réduction des points de friction
Problème identifié : L'obligation de renseigner un numéro de téléphone représentait un goulot d'étranglement majeur à l'inscription.
Solution UI : Ajout d'une option secondaire permettant d'ignorer temporairement cette étape (skip).
Résultat : +15 % de passage à l'étape suivante et +3 % sur la conversion finale du parcours.
Onboarding : Réduction des points de friction
Problème identifié : L'obligation de renseigner un numéro de téléphone représentait un goulot d'étranglement majeur à l'inscription.
Solution UI : Ajout d'une option secondaire permettant d'ignorer temporairement cette étape (skip).
Résultat : +15 % de passage à l'étape suivante et +3 % sur la conversion finale du parcours.
Consentement aux notifications : Clarté de la proposition de valeur
Problématique : Un faible taux d'adhésion initial aux notifications push.
Solution : Refonte du parcours de consentement pour mieux contextualiser la demande auprès de l'utilisateur.
Résultat mesuré : Le taux d'acceptation est passé de 30 % à 60 %.
Consentement aux notifications : Clarté de la proposition de valeur
Problématique : Un faible taux d'adhésion initial aux notifications push.
Solution : Refonte du parcours de consentement pour mieux contextualiser la demande auprès de l'utilisateur.
Résultat mesuré : Le taux d'acceptation est passé de 30 % à 60 %.
Consentement aux notifications : Clarté de la proposition de valeur
Problématique : Un faible taux d'adhésion initial aux notifications push.
Solution : Refonte du parcours de consentement pour mieux contextualiser la demande auprès de l'utilisateur.
Résultat mesuré : Le taux d'acceptation est passé de 30 % à 60 %.
Upsell & Cross-sell : Tester des leviers business
Upsell : Conception d'une mécanique proposant une carte au montant supérieur avec un ratio de frais plus avantageux pour l'utilisateur. Constat : L'expérimentation n'a pas validé l'hypothèse de rentabilité attendue, apportant des enseignements précieux sur les réelles intentions d'achat de nos utilisateurs.
Cross-sell : Intégration de suggestions pour encourager l'ajout de produits complémentaires au panier.
Upsell & Cross-sell : Tester des leviers business
Upsell : Conception d'une mécanique proposant une carte au montant supérieur avec un ratio de frais plus avantageux pour l'utilisateur. Constat : L'expérimentation n'a pas validé l'hypothèse de rentabilité attendue, apportant des enseignements précieux sur les réelles intentions d'achat de nos utilisateurs.
Cross-sell : Intégration de suggestions pour encourager l'ajout de produits complémentaires au panier.
Du Produit Unique au Panier Multi-Produits
Du Produit Unique au Panier Multi-Produits
Du Produit Unique au Panier Multi-Produits
Historiquement, l'achat de cartes se faisait à l'unité (une transaction distincte par carte). Pour répondre à une initiative business visant à augmenter le panier moyen, nous avons conçu l'expérience du panier multi-cartes.
Mon intervention : Adaptation des écrans de sélection de produits pour permettre la gestion des quantités et du panier.
Apprentissage produit : Si le panier a représenté un vrai gain de confort et de temps pour les utilisateurs qui achetaient déjà plusieurs cartes, il n'a pas suffi à inciter ceux qui n'en voulaient qu'une seule à dépenser plus. Cet écart entre l'objectif business et l'usage réel m'a appris à analyser lucidement l'impact d'une fonctionnalité.
4. Approche Data-Informed (Amplitude & Metabase)
4. Approche Data-Informed (Amplitude & Metabase)
4. Approche Data-Informed (Amplitude & Metabase)
L'analyse de données quantitatives a été le moteur principal de mon travail chez MONI :
Analyse de funnels : Identification précise des étapes de friction et des taux d'abandon (drop-offs) sur nos parcours d'achat.
Définition du tracking : Rédaction et documentation des plans de marquage (événements et propriétés) pour mesurer systématiquement l'impact de chaque refonte d'interface.
Prise de décision factuelle : Utilisation des métriques d'usage pour prioriser les chantiers UI et arbitrer les choix de conception.
L'analyse de données quantitatives a été le moteur principal de mon travail chez MONI :
Analyse de funnels : Identification précise des étapes de friction et des taux d'abandon (drop-offs) sur nos parcours d'achat.
Définition du tracking : Rédaction et documentation des plans de marquage (événements et propriétés) pour mesurer systématiquement l'impact de chaque refonte d'interface.
Prise de décision factuelle : Utilisation des métriques d'usage pour prioriser les chantiers UI et arbitrer les choix de conception.
L'analyse de données quantitatives a été le moteur principal de mon travail chez MONI :
Analyse de funnels : Identification précise des étapes de friction et des taux d'abandon (drop-offs) sur nos parcours d'achat.
Définition du tracking : Rédaction et documentation des plans de marquage (événements et propriétés) pour mesurer systématiquement l'impact de chaque refonte d'interface.
Prise de décision factuelle : Utilisation des métriques d'usage pour prioriser les chantiers UI et arbitrer les choix de conception.
Collaboration Tech & Culture Delivery
Collaboration Tech & Culture Delivery
Collaboration Tech & Culture Delivery
Au quotidien, je travaillais en étroite collaboration avec les développeurs de la squad.
Dailies & Pitchs : Revue quotidienne des tickets, suivi de l'avancement et présentation des nouveaux sujets afin d'expliquer le besoin, le contexte et les choix de conception.
Documentation fonctionnelle : Les tickets étaient documentés avec le besoin et sa justification, ainsi que les différents scénarios et comportements attendus sous forme de règles du type Given / If / Then, afin de limiter les ambiguïtés lors du développement. (Acceptance Criterias)
Tracking & Data : lorsque cela était nécessaire, je participais à la définition et à la documentation des événements et propriétés à tracker dans Amplitude, afin de pouvoir mesurer les usages et les résultats après mise en production.
Cette collaboration quotidienne m'a appris à concevoir des solutions en tenant compte à la fois de l'expérience utilisateur, des contraintes d'implémentation et de la mesure de leur impact.
Au quotidien, je travaillais en étroite collaboration avec les développeurs de la squad.
Dailies & Pitchs : Revue quotidienne des tickets, suivi de l'avancement et présentation des nouveaux sujets afin d'expliquer le besoin, le contexte et les choix de conception.
Documentation fonctionnelle : Les tickets étaient documentés avec le besoin et sa justification, ainsi que les différents scénarios et comportements attendus sous forme de règles du type If / Then, afin de limiter les ambiguïtés lors du développement.
Tracking & Data : lorsque cela était nécessaire, je participais à la définition et à la documentation des événements et propriétés à tracker dans Amplitude, afin de pouvoir mesurer les usages et les résultats après mise en production.
Cette collaboration quotidienne m'a appris à concevoir des solutions en tenant compte à la fois de l'expérience utilisateur, des contraintes d'implémentation et de la mesure de leur impact.
Au quotidien, je travaillais en étroite collaboration avec les développeurs de la squad.
Dailies & Pitchs : Revue quotidienne des tickets, suivi de l'avancement et présentation des nouveaux sujets afin d'expliquer le besoin, le contexte et les choix de conception.
Documentation fonctionnelle : Les tickets étaient documentés avec le besoin et sa justification, ainsi que les différents scénarios et comportements attendus sous forme de règles du type Given / If / Then, afin de limiter les ambiguïtés lors du développement. (Acceptance Criterias)
Tracking & Data : lorsque cela était nécessaire, je participais à la définition et à la documentation des événements et propriétés à tracker dans Amplitude, afin de pouvoir mesurer les usages et les résultats après mise en production.
Cette collaboration quotidienne m'a appris à concevoir des solutions en tenant compte à la fois de l'expérience utilisateur, des contraintes d'implémentation et de la mesure de leur impact.
Fondations & Design System
Fondations & Design System
Fondations & Design System
En parallèle des fonctionnalités produit, j'ai fortement contribué à la structuration du Design System de l'entreprise (tokens, modularité, auto-layout avancé et alignement avec le code React).
En parallèle des fonctionnalités produit, j'ai fortement contribué à la structuration du Design System de l'entreprise (tokens, modularité, auto-layout avancé et alignement avec le code React).
En parallèle des fonctionnalités produit, j'ai fortement contribué à la structuration du Design System de l'entreprise (tokens, modularité, auto-layout avancé et alignement avec le code React).
Découvrir l'étude de cas Moniik V3 ->
Découvrir l'étude de cas Moniik V3 →
Ce que cette expérience m'a apporté
Ce que cette expérience m'a apporté
Ce que cette expérience m'a apporté
Cette année chez MONI a marqué une étape clé dans ma maturité de Product Designer :
Rigueur data : Passer d'une intuition visuelle à une démarche d'optimisation guidée par la donnée d'usage.
Pragmatisme business : Comprendre qu'une amélioration de l'utilisabilité ne résout pas automatiquement un enjeu de chiffre d'affaires, et savoir mesurer objectivement un échec ou un succès.
Posture d'équipe : Savoir argumenter mes arbitrages fonctionnels face aux contraintes techniques des développeurs.
Cette année chez MONI a marqué une étape clé dans ma maturité de Product Designer :
Rigueur data : Passer d'une intuition visuelle à une démarche d'optimisation guidée par la donnée d'usage.
Pragmatisme business : Comprendre qu'une amélioration de l'utilisabilité ne résout pas automatiquement un enjeu de chiffre d'affaires, et savoir mesurer objectivement un échec ou un succès.
Posture d'équipe : Savoir argumenter mes arbitrages fonctionnels face aux contraintes techniques des développeurs.
Cette année chez MONI a marqué une étape clé dans ma maturité de Product Designer :
Rigueur data : Passer d'une intuition visuelle à une démarche d'optimisation guidée par la donnée d'usage.
Pragmatisme business : Comprendre qu'une amélioration de l'utilisabilité ne résout pas automatiquement un enjeu de chiffre d'affaires, et savoir mesurer objectivement un échec ou un succès.
Posture d'équipe : Savoir argumenter mes arbitrages fonctionnels face aux contraintes techniques des développeurs.