John Bargoni

À propos

Voir mon CV ->

À propos

Voir mon CV ->

Projet commandité · Gobelins Paris

Projet commandité · Gobelins Paris

Projet commandité · Gobelins Paris

Product Design @ReWear

Product Design @ReWear

ReWear : Product Design & Économie Circulaire

ReWear : Product Design & Économie Circulaire

ReWear : Product Design & Économie Circulaire

Métadonnées du projet

Métadonnées du projet

Métadonnées du projet

  • Rôle : Product Designer

  • Méthodologie : UX/UI, prototypage, tests d'utilisabilité, itérations

  • Outils : Figma, Google Meet, Rainbow Chart

Prolonger la vie des équipements outdoor

Prolonger la vie des équipements outdoor

Prolonger la vie des équipements outdoor

ReWear est un projet entrepreneurial visant à faciliter l'accès aux services de réparation et de réemploi dans le secteur outdoor.

L'idée : permettre à un utilisateur de trouver facilement un réparateur, de consulter les informations utiles et de prendre rendez-vous pour faire réparer son équipement.

L'enjeu était de rendre cette expérience aussi simple et accessible qu'une expérience d'achat en ligne.


J'ai travaillé sur la conception de l'expérience et sur son itération à partir de tests d'utilisabilité.

  • 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.

Tester plutôt que supposer

Tester plutôt que supposer

Tester plutôt que supposer

Après une première phase de conception et de prototypage, nous avons voulu confronter l'expérience à de vrais utilisateurs.

Nous avons mené des tests à distance auprès de 5 participants, correspondant aux deux archétypes définis pour le projet : l'Écologiste Pratique et l'Explorateur Économique.

Les participants devaient réaliser plusieurs tâches représentatives de l'expérience :

  • trouver un réparateur à proximité ;

  • sélectionner un type de réparation ;

  • choisir un créneau ;

  • prendre rendez-vous ;

  • ou simplement récupérer l'adresse d'un réparateur.

Nous avions défini en amont des hypothèses et critères de réussite pour chaque scénario afin de pouvoir comparer les comportements observés à nos attentes.

Les résultats ont ensuite été synthétisés à l'aide d'une Rainbow Chart, afin d'identifier rapidement les tendances et de prioriser les améliorations.

Après une première phase de conception et de prototypage, nous avons voulu confronter l'expérience à de vrais utilisateurs.

Nous avons mené des tests à distance auprès de 5 participants, correspondant aux deux archétypes définis pour le projet : l'Écologiste Pratique et l'Explorateur Économique.

Les participants devaient réaliser plusieurs tâches représentatives de l'expérience :

  • trouver un réparateur à proximité ;

  • sélectionner un type de réparation ;

  • choisir un créneau ;

  • prendre rendez-vous ;

  • ou simplement récupérer l'adresse d'un réparateur.

Nous avions défini en amont des hypothèses et critères de réussite pour chaque scénario afin de pouvoir comparer les comportements observés à nos attentes.

Les résultats ont ensuite été synthétisés à l'aide d'une Rainbow Chart, afin d'identifier rapidement les tendances et de prioriser les améliorations.

Ce que les tests nous ont appris

Ce que les tests nous ont appris

Ce que les tests nous ont appris

Les tests ont montré que plusieurs éléments que nous pensions suffisamment évidents ne l'étaient pas nécessairement pour les utilisateurs.

Plutôt que de simplement corriger des détails d'interface, nous avons utilisé ces observations pour remettre en question certaines parties du parcours.

  1. Comprendre la valeur avant de s'inscrire

  1. Comprendre la valeur avant de s'inscrire

Le problème

Lors des tests, l'application s'ouvrait directement sur l'interface principale ou sur une demande d'inscription. Conséquence : les participants ne comprenaient pas l'intérêt du service, et se retrouvaient perdus face à la carte et ses filtres.


L'itération

Nous avons comblé ce vide en créant un parcours d'onboarding. Il permet de présenter clairement la valeur du service dès l'ouverture de l'application. L'utilisateur peut y sélectionner son sport pour personnaliser son expérience, sans être bloqué par une création de compte immédiate.

  1. Simplifier la prise de rendez-vous

  1. Simplifier la prise de rendez-vous

Le problème

Le calendrier et les créneaux horaires étaient difficiles à manipuler dans leur première version.

Les observations ont notamment fait ressortir des problèmes de lisibilité et de compréhension de l'interaction avec le calendrier. Certains participants ont également eu des difficultés à visualiser comment naviguer dans les dates.


L'itération

Nous avons isolé le calendrier sur une page dédiée afin de donner davantage d'espace à cette étape et de rendre la sélection du créneau plus claire.

L'objectif était de réduire la surcharge visuelle et de permettre à l'utilisateur de se concentrer sur une seule décision à la fois.

  1. Rendre la confirmation impossible à manquer

  1. Rendre la confirmation impossible à manquer

Le problème

La validation d'un rendez-vous n'était pas suffisamment perceptible.

Plusieurs observations montrent que la notification de confirmation pouvait passer inaperçue après la validation du rendez-vous.


L'itération

Nous avons renforcé le feedback système avec une confirmation plus explicite directement dans l'interface, accompagnée d'une notification.

L'objectif était simple : après une action importante, l'utilisateur devait comprendre immédiatement que son rendez-vous avait bien été pris en compte.

De l'hypothèse à l'itération

De l'hypothèse à l'itération

De l'hypothèse à l'itération

Ce projet m'a surtout appris à remettre mes décisions de conception en question.


Une interface peut sembler évidente lorsqu'on la conçoit dans Figma, puis révéler des incompréhensions dès qu'elle est confrontée à quelqu'un qui ne connaît ni le produit ni nos intentions.


Les tests nous ont permis de passer d'une logique de :


« Est-ce que cette interface nous semble claire ? »

à

« Qu'est-ce que l'utilisateur comprend réellement lorsqu'il l'utilise ? »


Chaque friction observée nous a permis de revenir sur la conception, de prioriser les problèmes et d'itérer sur le prototype.

Ce que j'en retiens


Tester tôt.
Confronter rapidement une idée à des utilisateurs permet d'identifier des problèmes avant qu'ils ne deviennent coûteux à corriger.


Observer plutôt que supposer.
Les comportements réels révèlent des problèmes qu'une revue interne ne permet pas toujours de détecter.


Itérer avec intention.
Chaque modification du prototype doit répondre à une observation concrète et non simplement à une préférence esthétique.

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.

Ce projet m'a surtout appris à remettre mes décisions de conception en question.


Une interface peut sembler évidente lorsqu'on la conçoit dans Figma, puis révéler des incompréhensions dès qu'elle est confrontée à quelqu'un qui ne connaît ni le produit ni nos intentions.


Les tests nous ont permis de passer d'une logique de :


« Est-ce que cette interface nous semble claire ? »

à

« Qu'est-ce que l'utilisateur comprend réellement lorsqu'il l'utilise ? »


Chaque friction observée nous a permis de revenir sur la conception, de prioriser les problèmes et d'itérer sur le prototype.

Ce que j'en retiens


Tester tôt.
Confronter rapidement une idée à des utilisateurs permet d'identifier des problèmes avant qu'ils ne deviennent coûteux à corriger.


Observer plutôt que supposer.
Les comportements réels révèlent des problèmes qu'une revue interne ne permet pas toujours de détecter.


Itérer avec intention.
Chaque modification du prototype doit répondre à une observation concrète et non simplement à une préférence esthétique.

ReWear en quelques chiffres

ReWear en quelques chiffres

ReWear en quelques chiffres

5 participants testés

3 scénarios principaux évalués

Plusieurs itérations issues directement des observations utilisateurs

5 participants testés

3 scénarios principaux évalués

Plusieurs itérations issues directement des observations utilisateurs

5 participants testés

3 scénarios principaux évalués

Plusieurs itérations issues directement des observations utilisateurs

Consulter une autre étude de cas UX ?

Consulter une autre étude de cas UX ?

Retour projets

Cas d'étude UX : Jean Beaumont

John Bargoni

Linkedin

Contact

Linkedin

Contact

John Bargoni

John Bargoni

Linkedin

Contact

Create a free website with Framer, the website builder loved by startups, designers and agencies.