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 Manager
  • 2 Engineering Manager
  • 2 Développeur iOS
  • 2 Développeur Android
  • 4 Développeur Front Web
  • 4 Développeur Back-End

Sommaire

1 - Contexte

2 - Mise en place d'une stratégie de recherche

3 - Vision et stratégie

4 - Refonte du Design System

5 - Fonctionnalités

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 de 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égies

Définition d’une vision design sur les roadmap 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

MISE EN PLACE D'UNE STRATEGIE UTILISATEUR

Problème

À 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 et pourquoi​

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és 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ème

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 et pourquoi​​

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é ponctuelle

Équipe

  • 1 Product Manager
  • 1 Engineering Manager
  • 1 Développeur iOS
  • 1 Développeur Android
  • 2 Développeur Front Web
  • 2 Développeur 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 et pourquoi​​​

Remplacer la logique "jour" par une logique "période par date". Simple en apparence, mais cette décision nécessitait de recenser tous les cas d'usage propriétaires pour ne pas créer de nouveaux problèmes. J'ai conduit les interviews et les tests avant tout développement.

Ce que j'ai choisi de ne pas faire

Via mes interviews, j’ai pu identifier cette problématique et travailler avec les propriétaires pour analyser, déterminer tous les use-cases et de tester la solution avec eux.
J'ai pu faire des tests utilisateurs fonctionnels avec des employés Ouicar pour évaluer la difficulté à mettre une indisponibilité dans l'application avant de faire un test avec les propriétaires.

Ma contribution

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.

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

Équipe

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

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 et pourquoi​​​​

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 et pourquoi

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 et pourquoi

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.

RESULTAT

Développement personnel

Cette expérience au sein de OuiCar a été très enrichissante et répondait à mes attentes.
Je voulais gérer une plateforme qui soit Desktop et surtout Mobile, en faisant de l'amélioration continue et en apprenant des utilisateurs de OuiCar.

J'ai pu mettre en place toute une méthodologie sur la recherche utilisateur, des tests utilisateurs et intégrer des fonctionnalités. En termes de compétence personnelle, j'ai été plus autonome sur la prise de décision et j'ai eu la chance de travailler sur énormément d'évolutions et diversifier mon travail, que ce soit la recherche utilisateur, la création et l'amélioration de fonctionnalités, de parcours, de faire évoluer et maintenir un design system et de créer des illustrations, micro-interactions et animations pour la plateforme.

Prochaine étude de cas : UP