OuiCar

Créer une expérience satisfaisante aux utilisateurs (locataires & propriétaires) en réduisant le taux de contact au service client, augmenter la conversion, offrir des fonctionnalités pour répondre aux besoins des utilisateurs afin de maintenir une plateforme stable et à l'écoute des utilisateurs.
Rôle

UX/UI Designer

Date

Juin 2021 – Décembre 2022

Équipe
  • 2 Équipes
  • 2 Product Managers
  • 2 Engineering Managers
  • 2 Développeurs iOS
  • 2 Développeurs Android
  • 4 Développeurs Front Web
  • 4 Développeurs Back-End
Sommaire

Contexte

Vue d'ensemble

OuiCar est une plateforme de location de véhicules (voitures et utilitaires). Le principe ? Les particuliers louent leur véhicule à d'autres particuliers partout en France, y compris en Corse. Les tarifs sont moins chers qu'auprès des loueurs classiques comme Europcar, Hertz ou Sixt.​

Fonctionnement

Deux types d'utilisateurs se rencontrent sur la plateforme :
le propriétaire, qui met son véhicule en location, et le locataire, qui le réserve.
Le schéma ci-dessous montre les grandes étapes d'une location, de la mise en ligne de l'annonce jusqu'au retour du véhicule.

Schéma du fonctionnement d'OuiCar

Mes contributions

Recherche et test utilisateurs

J’ai interrogé des utilisateurs via des formulaires, des interviews en personne ou par téléphone, j’ai analysé leur retour d’information et j’ai effectué des tests d’utilisation.

Vision & Stratégie

Définition d’une vision design sur les roadmaps suite aux insights de nos utilisateurs et des feedbacks du service client.

Refonte Design System & Delivery

Mise à jour du Design System en se basant sur les principes de l’Atomic Design, mise à jour des écrans dans Figma et amélioration du delivery pour les PM et les développeurs.

Fonctionnalités

Création / amélioration de parcours ou de fonctionnalités pour la plateforme.

Résultats globaux

  • +8 % du taux de finalisation des réservations (confiance accrue des clients et processus de réservation plus fluide)

  • +3 % du taux d'acceptation des propriétaires, grâce à la mise à jour des calendriers qui leur permet de ne recevoir que les demandes auxquelles ils peuvent répondre

  • +15 % de taux de complétion des annonces ce qui a permis de faire + 20 % du taux d'occupation des véhicules présents sur la plateforme

  • -18 % de contacts au service client sur les questions fréquentes.

  • Amélioration globale de l'expérience utilisateur, réduction des frictions pour les propriétaires et renforcement de la confiance dans la plateforme

Stratégie utilisateur

Problématique

À mon arrivée, la recherche utilisateur était insuffisante et non structurée. Les décisions produit reposaient sur des croyances internes plutôt que sur des données terrain.​

Ce que j'ai choisi

J'ai mis en place une infrastructure de recherche continue : questionnaires, interviews, tests utilisateurs systématiques y compris pour chaque nouvel employé lors de son onboarding. Centralisation des insights dans ProductBoard via le principe Atomic Research pour alimenter directement les roadmaps.

Ce que j'ai choisi de ne pas faire

Traiter la recherche comme une étape ponctuelle avant chaque feature. L'enjeu était de créer un flux d'insights permanent pour prioriser avec fiabilité.

Avec le recul, l'impact le plus structurant n'était pas les outils mis en place, mais le changement de culture de décision dans l'équipe. Avant, les features étaient priorisées sur des intuitions internes. En rendant les insights utilisateurs accessibles et lisibles par les PM, la recherche est devenue une étape non négociable dans chaque cycle de roadmap, ce qui a réduit le nombre de features retravaillées après livraison.​

Ce que j'ai fait

  • Mise en place des questionnaires et interviews utilisateurs. Centralisation des insights (Coda → ProductBoard).

  • Tests utilisateurs obligatoires à l'onboarding de chaque nouveau collaborateur.

  • Co-priorisation des opportunités avec les PM via les insights collectés.
​

Vision & stratégie

Améliorer la façon de louer un véhicule par l'éducation

Avec les insights et les tests utilisateurs, j’ai pu remarquer que les utilisateurs ne savaient pas comment louer un véhicule sur notre plateforme.

Suite à des retours utilisateurs via le service client, beaucoup de questions qui étaient envoyées par les locataires se trouvent dans la FAQ OuiCar. Avec le responsable du service client nous avons analysé tout le parcours de réservation d’un véhicule et nous avons revu l’architecture de la FAQ en ajoutant des questions dans chaque étape clé des parcours locataires mais aussi la refonte de la FAQ en rangeant les questions les plus fréquentes par thématique.

L’idée était d’éduquer les nouveaux utilisateurs tout au long de leur réservation mais aussi de leur location (état des lieux aller et retour).

Recherche

Pour obtenir une nouvelle architecture de la FAQ, j'ai organisé un atelier utilisateur pour comprendre comment les utilisateurs verraient la FAQ OuiCar. Pour obtenir de bons retours, j'ai décidé pour cet atelier de mettre en place un tri de cartes ouvert à partir duquel les utilisateurs font leurs propres catégories.

Avec le responsable du service client, nous avons identifié des redondances de catégories dans les résultats et créé une arborescence finale qui permettra de créer la nouvelle FAQ.

Résultat

Avec la mise en place de questions qui redirigeaient vers la FAQ, nous avons pu constater une baisse de 18 % des taux de contacts au service client pour les questions les plus fréquentes.

Refonte Design System & Delivery

Problématique

3 Design Systems séparés (iOS, Android, Web), des composants non synchronisés avec la production, un nommage incohérent qui générait des erreurs de communication avec les développeurs.

Ce que j'ai choisi

Fusionner les 3 Design Systems en un seul, basé sur l'Atomic Design.
La décision clé : traiter le Design System comme un langage commun entre design, PM et dev, pas comme une bibliothèque de composants. Cette fusion a rendu le système scalable et a accéléré le delivery sur toutes les features suivantes.

Ce que j'ai choisi de ne pas faire

Maintenir des DS séparés avec des règles de synchronisation. Une solution de compromis qui aurait perpétué les problèmes de nommage sans les résoudre.

Avec le recul, la partie la plus complexe n'était pas technique mais organisationnelle. Fusionner 3 DS impliquait de convaincre deux équipes de renoncer à leurs composants existants. J'ai construit un cas concret : temps perdu en maintenance, erreurs de dev générées par les incohérences de nommage. C'est cet argument business, plus que l'argument design, qui a débloqué la décision.

Ce que j'ai fait

  • Fusion des 3 DS en un.
  • Refonte du nommage et de l'architecture des composants.
  • Mise à jour de l'accessibilité (polices, couleurs).
  • Regroupement des OS dans un même projet Figma pour faciliter la rédaction des specs PM et la lecture dev.

Fonctionnalités

1 - Indisponibilités ponctuelle

Équipe
  • 1 Product Manager
  • 1 Engineering Manager
  • 1 Développeur iOS
  • 1 Développeur Android
  • 2 Développeurs Front Web
  • 2 Développeurs Back-End

Problématique

Le système d'indisponibilité fonctionnait par jour de la semaine, pas par période. Un propriétaire qui prenait un lundi en absence se retrouvait indisponible tous les lundis de l'année et donc une perte de C.A directe pour lui et pour OuiCar.​

Ce que j'ai choisi

Passer d'une indisponibilité par jour de la semaine à une indisponibilité par période. Le propriétaire bloque uniquement les dates où il est absent, sans que ce choix se répète sur le reste de l'année. Une seule logique, claire, plutôt qu'une cohabitation des deux systèmes.

Ce que j'ai choisi de ne pas faire

Proposer une solution hybride qui gardait les deux logiques en parallèle pour ménager la transition. Une UX ambiguë sur un parcours aussi critique que le calendrier aurait généré plus de problèmes qu'elle n'en résolvait.

Avec le recul, la décision la plus risquée était d'imposer un changement de logique aux propriétaires habitués à l'ancien système. J'ai choisi de trancher clairement plutôt que de ménager une transition hybride, parce qu'une UX ambiguë sur la gestion du calendrier aurait été plus dangereuse qu'une courbe d'apprentissage courte.

Ce que j'ai fait

Via mes interviews, j'ai identifié cette problématique et travaillé avec les propriétaires pour analyser et déterminer tous les cas d'usage, puis tester la solution avec eux.

Avant de la tester avec les propriétaires, j'ai mené des tests utilisateurs fonctionnels avec des employés OuiCar pour évaluer la difficulté à poser une indisponibilité dans l'application.

Résultat

  • +3 % de taux d'acceptation des propriétaires.

  • Réduction des créneaux bloqués par erreur.

2 - Amélioration du dépôt du véhicule

Problématique

55% des fiches véhicules avaient en moyenne 2 photos seulement. Le catalogue était peu attractif comparé à la concurrence.​

Ce que j'ai choisi

Imposer un minimum de 4 photos avec des angles guidés, en trouvant le seuil d'acceptabilité auprès des propriétaires afin de garantir la qualité, mais pas assez pour décourager le dépôt. J'ai créé les illustrations des angles de prise de vue sous Illustrator pour rendre la contrainte intuitive.

Ce que j'ai choisi de ne pas faire

Laisser la prise de photos libre avec des recommandations non contraignantes. L'expérience montrait que sans obligation, les propriétaires restaient en dessous du seuil minimal de qualité.

Avec le recul, c'est probablement le meilleur ROI design du portfolio OuiCar. Et c'était aussi la feature la plus résistée en interne. Imposer une contrainte aux propriétaires faisait peur. La décision clé n'était pas le design de l'interface, c'était de convaincre le PM que la friction à court terme valait les +20 % d'occupation à moyen terme.

Résultat

+15 % de taux de complétion des annonces → +20 % de taux d'occupation des véhicules.

3 - Illustration

Problématique

L'application était purement fonctionnelle, froide, sans dimension émotionnelle. Les illustrations existantes étaient datées.​

Ce que j'ai choisi

Introduire une couche émotionnelle via des illustrations et micro-animations sur les moments clés du parcours (réservation instantanée, check-in). L'objectif n'était pas esthétique mais de renforcer la confiance et réduire l'anxiété aux étapes critiques.​

Ce que j'ai choisi de ne pas faire

Déprioriser ce chantier au profit de features à impact direct mesurable, même si l'argument était recevable en termes de priorité roadmap.

Avec le recul, défendre ce chantier était un pari. On aurait pu allouer ce temps à des features à impact direct plus facilement mesurable. J'ai défendu ce choix parce que la confiance utilisateur se construit aussi sur des signaux non fonctionnels et les retours ont confirmé que ces moments réduisaient l'anxiété aux étapes critiques du parcours.​

Écran de réservation instantanée

Animation pour la prise de photos du véhicule lors du check in​

4 - Redesign Homepage

Problématique

La homepage ne donnait pas envie. Elle était en retard sur la concurrence et ne contextualisait pas l'expérience de location.​

Ce que j'ai choisi

Introduire la photographie contextuelle comme élément central. Plutôt qu'un redesign complet du parcours, traiter la homepage comme une vitrine émotionnelle qui est le premier signal de confiance avant toute interaction.

Note : Selon la saison de l'année, la photo change.

Ce que j'ai choisi de ne pas faire

Engager une refonte complète de la homepage fonctionnelle car trop coûteuse pour le gain attendu à ce stade.

Avec le recul, utiliser la photographie contextuelle plutôt qu'un redesign fonctionnel complet était un choix de priorité autant que de design. On avait un impact rapide à aller chercher sur la première impression sans mobiliser une équipe entière sur une refonte lourde.​

Résultat

Les retours qualitatifs en tests utilisateurs ont confirmé une première impression plus chaleureuse et plus rassurante.

Conclusion

Chez OuiCar, je voulais faire vivre une plateforme mobile et desktop en amélioration continue, au plus près de ses utilisateurs. C'est ce que j'ai pu faire, de la recherche jusqu'à la livraison.

Les résultats en témoignent : −18 % de contacts au service client sur les questions fréquentes, +15 % d'annonces complètes et +20 % de taux d'occupation des véhicules, +8 % de réservations finalisées.

Mais ce que je retiens avant tout, c'est le changement de culture de décision. À mon arrivée, les features étaient priorisées sur des intuitions internes. En rendant les insights utilisateurs accessibles aux PM, la recherche est devenue une étape non négociable de chaque roadmap.

Sur le plan personnel, j'ai gagné en autonomie dans la prise de décision, et j'ai pu couvrir tout le spectre du métier : recherche, parcours et fonctionnalités, design system, illustrations et animations.

Prochaine étude de cas : UP