UX/UI Design / UX Writing
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.
Figma / Figjam
Canva
Photoshop
Trello
Moi (UX/UI)
Microcopie
Prototype hi-fi
Durée : 25 jours
Design & tests : 7 jours
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.
Sans oublier d’encourager l’utilisateur à prioriser les véhicules électriques.
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.
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 :
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.
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.
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 :
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”.
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 :
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.
Il m’a été spécifié que les chauffeurs peuvent proposer aux clients plusieurs services sous forme d’options :
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.
Sur ce point, plusieurs spécificités m’ont été communiquées :
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.
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.
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.
Il m’a été indiqué que le service devait pouvoir couvrir plusieurs cas de figure. Car il s’adresse aussi bien :
C’est pourquoi l’onboarding comprend trois étapes :
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é.
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.
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.
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.
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.
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.
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 :
Ces indicateurs sont donc placés directement sur le dashboard d’activité du chauffeur.
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”.
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.
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.
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.
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.
Tickie, start-up dans la billetterie de matchs sportifs au format NFT, a fait appel à mes services pour concevoir le MVP de leur flux d’achat de billets.
Figma / Figjam
Trello
Canva
Damien (Webdev/UI)
Moi (UX/UI)
Recherche utilisateur
Ideation
Tests utilisateurs
Sketchs & wireframe
Microcopie
Prototype hi-fi
En tout : 13 jours
Phase de recherche : 6 jours
Design & tests : 7 jours
Sécuriser les billets en éliminant le risque de fraude lors de l’achat / vente en seconde main
Valoriser les billets en les rendant unique et “collector“. En fonction de l’événement, ceux-ci peuvent même prendre de la valeur dans le temps.
Peu de confiance dans le format NFT (vu comme trop spéculatif)
“Un supporter occasionnel a besoin d'acheter le bon billet dans la bonne quantité pour un événement sportif, grâce à une plateforme rapide, fluide et certifiée avant que les places ne soient épuisées. Car même si les plateformes de revente offrent une seconde chance, elles n'offrent pas une sécurité suffisante contre la fraude.”
L’offre d’événements sportifs revêt une certaine complexité :
Comment donner à l’utilisateur un accès simple à la complexité de cette offre ?
Pour moi, une contrainte similaire s’applique aux applications de musique (Spotify, Deezer,…).
A l’instar de ces applications, une solution consiste à proposer :
La phase de recherche nous a appris que la sécurité était le principal soucis des utilisateurs.
Comment transmettre aux utilisateurs le sentiment que leurs billets sont uniques et sécurisés ?
Réponse (en partie) : en leur montrant une animation de “fabrication” de leur billet.
A la manière d’une forge ou d’une presse, le billet est “confectionné à la main” par l’application.
Cette idée m’est venue lors d’une session de brainstorming en Crazy-8.
Le texte ne fait pas “sport”.
Cela me fait plus penser à un réseau social qu’à une billetterie.
Ca fait assez “mou”, pas très dynamique.
Nous avons donc décidé de reprendre le style à zéro.
Sport
Dynamisme
Confiance
Inspiration : style de typographie utilisé par le journal “L’équipe”
Nous avons opté pour une couleur primaire bleue.
Objectif : donner un maximum de place aux espaces blancs pour renforcer la lisibilité dans un contexte d’informations nombreuses.
Donner de l’importance aux contenus textuels dés la phase de mid-fi, a permis d’améliorer le wording au fil des itérations en étant guidé par les tests d’utilisabilité.
Lors des interviews utilisateur, nous avons noté que ceux-ci avaient une confiance limitée dans la technologie NFT. Bien que Tickie en ait fait son principal “argument innovation”, nous devions éviter de mentionner directement cette technologie dans l’interface.
Nous avons donc choisi de parler de “Crypto-billet” plutôt que de “billets NFT”.
Il nous a semblé important d’informer explicitement les utilisateurs de la sécurité et des avantages que les crypto-billets leur apporte.
Pour cela, nous avons inclus une modale d’explication derrière un lien “info”, partout ou l’expression “crypto-billet” était employée.
La réalisation du prototype hi-fi a été l’occasion d’appliquer notre compréhension du besoin utilisateur :
Engageant
Direct
Attractif
Amical
Invitant
Lors des tests de désirabilité, les utilisateurs ont rapporté d’autres qualificatifs.
Les résultats de ces tests ont été particulièrement gratifiants, les fonctionnalités les plus appréciées étant :
Avec l’autorisation de Tickie, nous avons présenté ce projet dans le cadre du concours UX/UI Design Ironhack.
Outre une démonstration du prototype Figma, nous avons présenté les différentes étapes de notre travail ainsi que les méthodes utilisées.
Cette présentation, soutenue en Anglais devant un jury composé d’experts du design, nous a permis de décrocher la 3ème place du podium (sur 13 compétiteurs).
Un prix d’honneur nous a alors été décerné.
Bienvenue dans un monde sans tabac avec ActiQuit ! Une application pour assister l’arrêt de la cigarette, conçue à l’aide du Design Thinking.
Figma / Figjam
Trello
Canva
Moi (UX/UI)
Recherche utilisateur
Ideation
Tests concept & utilisabilité
Sketchs & wireframe
Microcopie
Prototype hi-fi
En tout : 7j
Phase de recherche : 2j
Design & tests : 5j
Notre équipe a été contactée par la Daily Health Conference pour concevoir une application de bien-être.
Les contraintes :
3 applications d’aide à l’arrêt du tabagisme :
L’analyse de ces applications nous a permis d’identifier plusieurs fonctionnalités communes, comme :
Basé sur notre user persona et les interviews utilisateurs, nous avons défini une User Journey Map.
L’état émotionnel d’Alex Russo atteint son plus fort creux lorsqu’il a déjà essayé d’arrêter le tabac une première fois, seul et sans succès et qu’il réalise son réel niveau de dépendance.
C’est à cette étape que l’application doit intervenir pour l’aider.
Un fumeur régulier qui souhaite arrêter le tabac a besoin d'aide pour gérer la tentation de fumer dans un environnement social, car il a déjà rechuté après des tentatives sans assistance extérieure.
A permis de faire émerger un premier concept : un “supporter” qui soutient l’utilisateur.
A été choisie pour explorer ce concept de supporter, et dégager des idées plus claires dans une problématique plutôt complexe (l’aide au sevrage).
Permettre à l'utilisateur de trouver un "supporter anti-tabac" dans la même zone géographique, avec qui se soutenir mutuellement et avec qui se rendre dans des événements entièrement non-fumeurs.
Les autres fonctionnalités de l’app sont alignées sur la concurrence :
Les utilisateurs test – surtout les utilisatrices – ont pointé du doigt le risque d’abus liés au concept de rencontre entre utilisateurs.
Leur crainte : que le prétexte de soutien entre fumeurs soit utilisé par certains utilisateurs pour chercher à faire des rencontres amoureuses.
Ce risque est compliqué à limiter de manière certaine et peut engendrer des abus.
Permettre à l'utilisateur de participer à des événements entièrement non-fumeurs.
Nous avons recentré notre concept sur la fonctionnalité d’organisation d’événements non-fumeurs.
C’est une idée qui a été largement validée lors des concept tests.
Une session de brainstorming nous a permis de définir les valeurs de l’application. C’est ce qui va guider le moodboard et le choix de style.
Dynamisme
Motivation
Communauté
Sérénité
Pour cette mission, le brief précisait qu’une application “compagnon” devait être également conçue.
Nous avons donc décidé de concevoir celle-ci pour une smart watch.
Cette app compagnon permet d’accéder rapidement à la fonctionnalité de soutien lors des moments de tentation :
Pour nous assurer de l’accessibilité de notre interface, nous avons utilisé le plugin “Contrast” sur Figma.
Cela nous a permis de choisir des couleurs et des polices qui offrent une lisibilité suffisante.
Sur un standard de lisibilité de niveau “AA”, nous avons obtenu un sans faute.
Les 3 seules erreurs apparaissant sont dues à des couches volontairement masquées pour l’animation de notre splash screen.
Pour tester l’utilisabilité de notre solution, nous avons donné aux utilisateurs tests, 3 tâches à accomplir sur l’application :
Observer les utilisateurs accomplir ces tâches sur le prototype, nous a permis d’optimiser l’utilisabilité de l’interface.
Par exemple, le bouton “supprimer mes données” était majoritairement recherché dans le menu “Gestion de compte” plutôt que “Gestion des données”. Nous avons donc réorganisé les menus pour correspondre à cet usage.
Pour évaluer la désirabilité de notre application, nous avons employé la méthode des “Reaction Cards” de Microsoft.
Amical – Direct – Utile : les adjectifs majoritairement choisis par nos utilisateurs correspondent au comportement de soutien préconisé par l’addictologue que nous avions interrogé lors de la recherche.
