Prendre rendez-vous en ligne

Avant ce projet, prendre rendez-vous avec sa banque passait par un appel, une attente, un rappel, puis un créneau proposé. Le nouveau parcours donne au client le choix du sujet, du canal et du créneau, directement en ligne.

Rôle
Lead designer
Contexte
App mobile + web
Période
2024
Ma mission

Concevoir un parcours de prise de rendez-vous en ligne.

Impact mesuré· 6 mois après mise en production (2024)

-35%

Appels service client

sur les objets concernés

40%

Taux de complétion

sur le MVP

Stats

Motifs demandés

génération automatique

Le problème

Les utilisateurs pouvaient appeler ou demander à être rappelés, mais ils ne choisissaient ni leur créneau, ni leur canal, ni toujours le bon interlocuteur.

Côté banque, la gestion manuelle consommait beaucoup de temps opérationnel et ne remontait pas automatiquement de données sur les motifs de rendez-vous les plus demandés.

L'enjeu allait au-delà de l'interface : il fallait qualifier précisément l'objet du rendez-vous pour interroger les bons agendas, gérer des règles métier spécifiques (canal imposé selon le motif, délais minimum, limite de 2 rendez-vous actifs, exclusion des mineurs et personnes sous tutelle), et couvrir des cas particuliers comme le retrait en devises étrangères — sans exposer cette complexité à l'utilisateur.

Ce que j'ai fait - et pourquoi

01. Benchmarker les bonnes pratiques bancaires.

J’ai identifier les patterns établis et l’effort utilisateur de plusieurs concurrents avant de concevoir.

Extrait du benchmark
Extrait du benchmark sur l’effort utilisateur chez chaque concurrent.

02. Cadrer les règles métier avec toutes les parties prenantes.

Cadrage réalisé avec CP, BA, IT, service client, conseillers agence. Chaque motif de rendez-vous a ses propres règles : canal imposé (téléphone ou agence), délai minimum, interlocuteur cible. Ce cadrage a directement alimenté le wireflow.

03. Prototyper le parcours mobile.

Le wireflow et les wireframes ont été construits en parallèle, mobile-first. Une fois validé, le parcours a servi de base de référence pour la suite du projet.

Wireflow du parcours
Wireflow du parcours.

04. Décliner en desktop.

C'est lors du développement desktop que le dev web a signalé un problème non anticipé sur l'affichage des créneaux : le volume possible rendait l'interface ingérable. On a co-construit une solution : première liste de créneaux affichée, bouton "voir plus d'horaires" pour les suivantes.

Affichage des créneaux sur desktop
Affichage de première plages horaire. Un bouton “voir plus” pour voir les suivantes.

05. Accompagner jusqu'en production.

Traductions transmises avec liens textes/écrans pour les développeurs, Design Quality Check réalisé.

Décisions clés

Qualifier l'objet en premier

Délai de 48h, aucun créneau disponible, limite de 2 rendez-vous actifs : chaque cas a un message précis et une sortie de parcours claire, plutôt qu'un renvoi générique vers le service client.

Rendez-vous affiché
Rendez-vous affiché
Maximum 2 rendez-vous
Maximum 2 rendez-vous
Ajout d'une aide dédiée pour expliciter Luxtrust Mobile et réduire les zones d'incertitude autour de l'authentification.

Cas particulier : retrait en devises

À la sélection de ce motif, une zone d'information s'affiche immédiatement (les retraits inférieurs à 5 000 € en euros ne nécessitent pas de rendez-vous). Le champ montant bloque la progression tant que les conditions ne sont pas réunies. L'utilisateur reçoit ensuite une date de disponibilité des fonds : pas un créneau strict, mais le moment à partir duquel il peut venir retirer.

Ecran pour les retraits
Etape bloquée si le montant est inférieur à 5.000 EUR
Ecran de confirmation du retrait
Indication du créneau pour venir retirer les fonds en agence

Création du composant bottom sheet contextuel

Pour afficher les cas d’erreur, les créneaux réservés au même moment ou les confirmations de suppression, j’ai mis en place un composant bottom sheet contextuel.

Conçu pour remplacer les anciennes pop-ups héritées du web, je l’ai documenté et il a pu être réutilisé sur d'autres projets, notamment la refonte du parcours de connexion.

4 variantes selon le contexte : succès (vert), info (bleu), warning (orange), erreur/suppression (rouge).

Annotation pour création du composant bottom sheet
Annotation pour création du composant bottom sheet.

Détails qui comptent

Agence habituelle du client remontée en priorité dans le sélecteur. Jours fériés affichés comme désactivés dans le calendrier. Barre de progression et récapitulatif avant confirmation — pour que l'utilisateur garde le contrôle à chaque étape.

Résultats et preuves

Le MVP a réduit de 35% les appels au service client sur les motifs concernés, avec 40% de taux de complétion dès la mise en production.

La banque dispose désormais de statistiques automatiques sur les motifs les plus demandés — une donnée inexistante avant ce projet, et qui alimente directement la priorisation du lot 2.

Les données de production ont aussi révélé un taux d'abandon sur l'étape de sélection du motif. L'analyse pointe deux causes : une zone de friction réelle sur la liste, et une curiosité utilisateur — des clients qui exploraient sans intention de réserver immédiatement.

Ce signal, et les fondations techniques posées par ce projet, définissent clairement le périmètre du lot 2 : simplification de la liste des motifs, regroupement, meilleure signalétique d'entrée.

Ce que j'en retiens

"Co-construire avec les devs produit de meilleures solutions. L'affichage progressif des créneaux n'est pas né d'un brief : il est né d'un problème signalé en cours de développement. Rester disponible et réactif après la livraison des maquettes fait partie du travail."

"Un composant bien documenté dépasse le projet qui l'a créé. La bottom sheet née ici a été reprise sur la refonte de la connexion, puis plus largement sur chaque projet. Concevoir avec une logique de réutilisabilité dès le départ, c'est contribuer à quelque chose qui dure au-delà du livrable."

Prochain case study

Un objectif simple en apparence, mais qui cache beaucoup de complexité.