Prototypage d’une app de VTC pour un appel d’offres
Un appel d’offre a été lancé pour créer l’application VTC d’une compagnie de taxis & VTC.
Mon rôle dans ce projet, a été de dessiner les sketchs des écrans de cette application et de réaliser son prototype sur Figma.
Outils utilisés
-
Figma / Figjam
-
Canva
-
Photoshop
-
Trello
L’équipe
-
Moi (UX/UI)
Mon rôle
- Sketchs
-
Microcopie
-
Prototype hi-fi
Timeline
-
Durée : 25 jours
-
Design & tests : 7 jours
📱 Projet "prototypage only"
Mon client est une entreprise de services automobiles. Souhaitant répondre à l’appel d’offre lancé par une compagnie de taxis et VTC, il devait pour cela développer une application de mobilité.
Ma mission a donc consisté à concevoir cette application de mobilités pour permettre à mon client de répondre à l’appel d’offre.
Le but de l’application
Sans oublier d’encourager l’utilisateur à prioriser les véhicules électriques.
Une application, deux interfaces
Dans ce contexte, mon client a choisi de faire appel à mes services pour réaliser le prototype Figma de cette application.
Celle-ci sera faite en deux parties : une version destinée aux utilisateurs et l’autre aux chauffeurs.
Les conditions d’un nouveau challenge
- Mon rôle : uniquement prototypage sur Figma
- Pas de recherche ou de test utilisateur en amont
- Exploration limitée au benchmarking de la concurrence
- Pas de cahier des charges : fonctionnalités et parcours utilisateur imposés et communiqués avec peu de détails
Focus sur les interfaces
Pourquoi ce choix ?
- Pour plus de confidentialité (je ne peux pas montrer l’intégralité de l’interface),
- Pour se focaliser sur les éléments les plus représentatifs du travail que j’ai réalisé.
Ce case study a été anonymisé
Les couleurs et le logo ont été changés pour préserver la confidentialité de l’entreprise concernée.
Le nom « CABY » est fictif.
L’accessibilité de l’interface s’en trouve diminuée par le manque de contraste à certains endroits.
✏️ Sketching
Pourquoi ?
Pour s’assurer de l’alignement de l’UI avec les fonctionnalités et les parcours utilisateur spécifiés.
Cet alignement a été validé en amont avec les parties prenantes avant de passer au prototypage sur Figma.
Sur ce projet, il n’y a pas de wireframes :
- car mon client souhaitait avancer sans phase de tests,
- car il souhaitait avoir directement un rendu stylisé des interfaces après les sketchs.
Application côté client
Parcours onboarding
Compte entreprise
La demande de mon client spécifiait une utilisation du service par les salariés d’une entreprise, elle-même détentrice d’un abonnement.
Il était donc important de permettre aux salariés de renseigner les informations de l’entreprise dont ils utilisent le compte.
Si le bouton « Compte entreprise » n’est pas activé, le processus de création de compte est « standard » et l’écran suivant demande les coordonnées du client.
Si ce bouton est activé par l’utilisateur, l’écran suivant – spécifique aux comptes entreprise – permet de renseigner les identifiants de l’entreprise détentrice de l’abonnement.
Création de compte lors de la commande
Lorsqu’un nouvel utilisateur ouvre l’application pour la première fois, celle-ci lui permet d’entamer la commande de son premier trajet avant même de créer un compte. Le parcours de création de compte est alors proposé au moment de valider la commande.
Pourquoi ?
La création d’un compte est généralement perçue comme une corvée par les utilisateurs.
Le fait de pouvoir d’emblée accéder au service, choisir ses options et passer commande avant cette étape permet de :
- Créer de l’engagement client en amont de cette « corvée », donc réduire le churn liée à celle-ci
- Permettre au client d’appréhender le service rapidement et d’être rassuré sur la capacité de celui-ci à répondre à son besoin
La demande de mon client spécifiait la possibilité d’utiliser tout de même le service sans créer de compte. Cela permet également de réduire l’effet « dark pattern ».
Passer la création de compte
Voici une spécification communiquée par mon client.
Dans le cas où l’utilisateur préfère passer la création de compte, un disclaimer le prévient des conséquences de ce choix :
- Il ne pourra payer qu’en espèces, directement au chauffeur,
- Un code de sécurité lui sera donné après sa commande, code qu’il devra communiquer au chauffeur.
Choix du moyen de paiement
Après avoir renseigné ses coordonnées, l’utilisateur peut choisir un moyen de paiement à enregistrer : CB ou Paypal. Il peut également choisir de ne régler qu’en espèces, auprès du chauffeur.
Parcours de commande
Sélection du véhicule et des options
Il m’a été spécifié que les chauffeurs peuvent proposer aux clients plusieurs services sous forme d’options :
- Accès PMR (personnes handicapées),
- Siège bébé,
- Transport d’animaux,
- Etc.
Ces options doivent être proposées à l’utilisateur lors de sa commande.
A la demande de mon client, les véhicules à hydrogène doivent être mises en avant dans des catégories à part entière.
Moyens de paiement
Sur ce point, plusieurs spécificités m’ont été communiquées :
- Pour enregistrer un moyen de paiement (CB ou Paypal), l’utilisateur doit obligatoirement créer un compte.
- Mais il doit pouvoir commander une course même s’il n’a pas créé de compte. Auquel cas, il ne peut régler qu’en espèces.
- L’utilisateur peut avoir créé un compte, mais ne pas avoir enregistré de moyen de paiement. Dans ce cas, il ne pourra également régler qu’en espèces.
En cas d’interaction avec l’utilisateur, le sélecteur de moyens de paiement doit donc adapter son affichage ainsi que la « modale/CTA » qu’il déclenche pour informer l’utilisateur et lui proposer une action en conséquence.
Cela permet d’adapter le comportement du sélecteur de paiement en fonction de la situation dans laquelle se trouve l’utilisateur.
Il reste un problème à résoudre.
Si l’utilisateur ne peut payer qu’en espèce, il est capital qu’il soit conscient de cela avant de valider la commande.
Sinon, il y a un risque pour qu’il n’ait pas prévu d’espèces pour régler sa course lorsque le chauffeur arrive…
Pour s’assurer que cette situation ait le moins de chances de survenir, un rappel est automatiquement affiché dans le cas d’un paiement en espèces.
Recherche d’un chauffeur et trajet
Une fois que la commande est passée, l’application doit trouver un chauffeur pour le client.
A cette étape, la recherche et le trajet sont simulés dans le prototype par une animation.
Lorsqu’un chauffeur est trouvé, les détails sont communiqués à l’utilisateur concernant le chauffeur et son véhicule.
Parmi ces détails, on retrouve le code d’identification demandé par mon client dans le cas d’un paiement en espèces.
Application côté chauffeur
Parcours onboarding
Il m’a été indiqué que le service devait pouvoir couvrir plusieurs cas de figure. Car il s’adresse aussi bien :
- aux chauffeurs indépendants avec une seule voiture et un seul chauffeur,
- qu’aux entreprises (compagnies de taxis par exemple) avec plusieurs véhicules et plusieurs chauffeurs.
C’est pourquoi l’onboarding comprend trois étapes :
- Enregistrement de l’activité
- Enregistrement du/des véhicule(s)
- Enregistrement du/des chauffeur(s)
Enregistrement de l’activité
A la fin de cette première étape d’onboarding, il est proposé à l’utilisateur d’uploader les documents demandés (ID, permis de conduire,…) plus tard.
Il lui est également rappelé que ces documents sont indispensables au démarrage de l’activité.
Pourquoi ?
Car l’on considère que l’utilisateur n’a pas forcément ces documents sous la main au moment de l’inscription.
C’est un choix qui a été guidé par mon client, ayant lui-même pu interroger plusieurs utilisateurs-cible à ce sujet.
Enregistrement du/des véhicule(s)
A tous moments, l’utilisateur est libre d’interrompre le processus d’onboarding véhicule. Il lui est alors indiqué que les données déjà entrées seront reprises.
Pourquoi ?
Suivant la même logique que celle des documents à uploader lors de l’étape précédente, mon client a souhaité que l’utilisateur puisse mettre en pause l’onboarding de cette manière.
En effet, il peut avoir besoin de retrouver certaines informations pour continuer (contrat d’assurance, par exemple) et vouloir explorer le reste de l’application en attendant.
Enregistrement du/des chauffeur(s)
Pour qu’un chauffeur soit actif, tous ses documents doivent être uploadés (ID, RIB, casier judiciaire,…).
Mais on permet tout de même à l’utilisateur de continuer à enregistrer le chauffeur, même s’il manque des documents.
Pourquoi ?
Mon client m’a spécifié le cas où le dirigeant d’une compagnie de taxis enregistre lui-même les chauffeurs de son entreprise.
Il fallait permettre à un tel dirigeant d’enregistrer ses chauffeurs tout en leur laissant le soin de compléter eux-mêmes les documents manquants.
C’est d’ailleurs pour cette raison qu’il est proposé à l’utilisateur d’envoyer un mail de rappel au chauffeur qui est en cours d’enregistrement.
Dashboard d’activité
Une vue sur les chiffres de la journée
Mon client m’a indiqué que les chauffeurs doivent avoir une vue claire et simple sur leurs chiffres de la journée.
C’est à dire :
- Nombre de courses effectuées
- Chiffre d’affaire réalisé
Ces indicateurs sont donc placés directement sur le dashboard d’activité du chauffeur.
Réservations VS courses
Les chauffeurs peuvent prendre des courses « classiques », qui leurs sont proposées à la volée.
Mais ils peuvent également accepter des réservations. Celles-ci sont faites à l’avance par les clients.
Le dashboard permet donc une distinction claire entre ces deux formes de mission, à l’aide d’un sélecteur.
Celui-ci permet de passer d’une vue sur les courses entrantes, à une vue qui récapitule les réservations à venir.
La prochaine réservation est tout de même affichée en haut de la vue « courses ».
Pourquoi ?
Car mon client m’a indiqué que les chauffeurs doivent faire attention à ne pas prendre une course qui les mette en retard pour assurer une réservation.
Le sélecteur d’activité
Les chauffeurs ne sont pas en activité en permanence. Que ce soit pour une pause ou pour une fin de journée, ils doivent indiquer leur statut à l’application.
La pause
Lorsque le chauffeur veut prendre une pause, ce bouton lui permet d’indiquer à l’application qu’il ne prend temporairement pas de courses… Tout en gardant un oeil sur les courses entrantes.
Pourquoi ?
Cela permet au chauffeur d’interrompre sa pause et de reprendre l’activité rapidement s’il souhaite finalement prendre une course qu’il juge plus intéressante.
La fin d’activité
Lorsque le chauffeur termine sa journée, il indique à l’application qu’il ne prend plus de courses pour cette session.
Les courses entrantes ne sont logiquement plus affichées.
S’il quitte l’application, ce bouton revient automatiquement en « inactif », de sorte qu’il n’a pas besoin de penser à le désactiver manuellement en fin de session.
L'appel d'offre
Le prototype réalisé pour cette application, a été montré lors de la soutenance de l’appel d’offre.
Il a eu un impact certain lors la présentation.
A l’heure actuelle, cet appel d’offre est toujours en cours. Aussitôt que son résultat final sera connu, je le communiquerai ici.