OuiCar
Le Airbnb des voitures
Optimiser la conversion et industrialiser la production design d'une marketplace de location entre particuliers
Louer une voiture à deux pas de chez vous
OuiCar est une marketplace de location de voitures entre particuliers, fondée en 2012 et rachetée par Turo en 2021. Comme toute marketplace, le modèle repose sur la transaction : chaque réservation qui aboutit génère du revenu. Autrement dit, chaque point de friction dans le parcours, chaque demande qui n'aboutit pas, a un coût business direct.
Bonjour OuiCar !
En arrivant, j'ai commencé par comprendre le contexte produit et les méthodes de travail en place. OuiCar adresse deux cibles aux besoins très différents : les locataires qui cherchent un véhicule, et les propriétaires qui mettent le leur à disposition. La conversion ne dépend pas que du locataire: une demande n'a de valeur que si le propriétaire l'accepte. Cette dépendance entre les deux faces du marché a orienté la majorité de mes décisions.
Tout commence par des dates
Premier levier de friction identifié : la sélection des dates en mobile, qui remontait régulièrement dans les retours utilisateurs. Pour comprendre le problème avant de le traiter, j'ai croisé trois sources : l'analyse des comportements via Amplitude, un questionnaire et des interviews utilisateurs.
Le diagnostic était net. Le formulaire imposait de saisir une date de départ, puis de recliquer pour saisir une date de retour. Une double interaction qui cassait le geste naturel de sélection d'une plage.
Je n'ai pas aimé mettre la date de départ et de devoir recliquer pour la date de fin
— Un utilisateur
Supprimer un champ
La solution évidente aurait été de mieux signaler le second champ. J'ai tranché autrement : supprimer purement et simplement le champ "Date de retour" et passer sur une sélection de plage continue. Un champ en moins dans le formulaire, un geste unique au lieu de deux, et la plage complète visible d'un coup d'oeil.
Supprimer un élément plutôt que d'en ajouter un, c'est souvent la décision qui demande le plus de conviction et qui a le plus d’impact.
C'est mieux ou c'est moins bien ?!
Avant d'engager le moindre coût de développement, j'ai conçu un prototype interactif sous Figma pour mettre les deux versions en confrontation. Chaque participant testait l'ancienne interface puis la nouvelle, et répondait à un questionnaire à la fin de chaque session pour évaluer les deux objectivement.
Cette étape avait un but précis : dérisquer la décision avant l'A/B test en production. On ne déploie pas une refonte de formulaire de recherche sur la base d'une intuition.
Objectif atteint !
La nouvelle version a été préférée et perçue comme plus simple, puis confirmée par la mesure du temps de parcours en production.
Les deux premiers chiffres mesurent la préférence en test, le troisième un gain de friction réel mesuré en production.
Six secondes sur une recherche, multipliées par le volume de recherches quotidiennes d'une marketplace, ce n'est pas un détail : c'est de la friction retirée à l'entrée du funnel.
62,5 %
des participants préféreraient utiliser cette nouvelle version.
62,5 %
des participants ont trouvé cette nouvelle version plus simple à utiliser.
6 secondes
c’est le temps gagné sur le tunnel de recherche d’un véhicule.
Un plaisir de trouver des dates de location
En supprimant le champ « Date de retour », l'utilisateur sélectionne ses dates en une seule interaction, ce qui représente 6 secondes gagnées sur le tunnel de recherche. La plage de jours sélectionnée est désormais visible d'un seul coup d'œil.
Avant
Après
Sélection de la date de départ
Sélection de l'horaire de départ
Sélection de la date de retour
Sélection de l'horaire de retour
Objectif réservation !
Deuxième chantier de conversion, plus en profondeur dans le funnel : faire passer la demande du locataire à l'acceptation du propriétaire. C'est l'étape la plus critique du modèle, parce qu'elle dépend des deux faces du marché en même temps.
Plutôt que de partir directement sur des pistes de design, j'ai voulu élargir le champ des solutions. J'ai organisé, avec mon PM, trois ateliers d'impact mapping avec des collaborateurs de différents métiers, pour concentrer les efforts sur ce qui a un impact réel sur l'objectif.
Une collaboratrice en train de noter une idée sur un post-it
Moi-même en train d'animer un atelier de carte d'impact
L'après post-it
Au-delà des idées, ces ateliers ont eu un effet de conduite du changement. J'ai embarqué des collaborateurs qui n'avaient jamais participé à une démarche d'idéation structurée, et la restitution leur a montré concrètement l'utilité de l'exercice. Une compétence de facilitation autant que de conception : faire travailler ensemble des métiers non-design sur un objectif produit commun.
90 %
des participants ont attribué une note de plus de 4 sur 5 à l’atelier.
J’ai aimé le fait de le faire en équipe car cela permet de mettre en commun nos idées et de pouvoir rebondir dessus pour être plus complet.
Un participant à l’atelier
Demandez, demandez, demandez… !
La recherche utilisateur a révélé que le problème n'était pas vraiment un problème de design, mais de comportement. Les nouveaux locataires envoient une seule demande, attendent la réponse du propriétaire, et ne recommencent qu'en cas de refus. Quand un propriétaire tarde à répondre, la frustration monte et le locataire abandonne.
La décision stratégique a donc été de concevoir pour casser ce comportement : inciter le locataire à envoyer plusieurs demandes en parallèle dès le départ.
Ancienne interface
Nouvelles interfaces
Objectif atteint !
+17 %. Le chiffre porte précisément sur l'acceptation de la demande par le propriétaire, une étape du funnel et non la réservation finalisée : entre l'acceptation et la location effective, le locataire comme le propriétaire peuvent encore annuler.
Industrialiser la cohérence visuelle des interfaces
En arrivant chez OuiCar, je découvre trois design systems distincts : Android, iOS et web.
Résultat : des composants dupliqués en triple, des coûts de maintenance élevés et une conception des interfaces ralentie à chaque nouveau projet.
iOS
Android
Web
1 + 1 + 1 = 1
Réunifier les trois design systems en un seul a réduit les coûts de maintenance, fait table rase sur les composants obsolètes et unifié les interfaces sur tous les supports.
J'en ai profité pour mettre à jour les composants avec les dernières fonctionnalités de Figma et établir un langage commun avec les développeurs.
L'arbitrage clé n'était pas de tout fusionner aveuglément. J'ai conservé les composants natifs propres à chaque OS, là où l'unification aurait dégradé l'expérience native.
Présentation d'un composant dans Figma
Primaire, secondaire, tertiaire, bordure…
Je n'ai pas retravaillé la charte graphique de OuiCar, mais j'ai contribué à la rendre plus accessible. En m'appuyant sur le plugin Stark, j'ai vérifié et ajusté les ratios de contraste de la palette tout en conservant les nuances originelles, puis mis à jour l'ensemble des composants du design system.
Toujours volontaire, force de propositions avec des retours toujours pertinents, sa présence et ses retours étaient pour moi indispensables pour mener des projets dans de bonnes conditions.
— Benjamin, product designer chez OuiCar