Projets
EN FR
Étude de cas · Skyjetz (UX Design Institute brief) · 2023 · 9 min de lecture

C'est à la réservation que les compagnies perdent leurs clients. J'ai conçu l'étape que tout le monde déteste.

Un processus UX complet pour une compagnie aérienne fictive, de la recherche au transfert annoté. La recherche a nommé où la conversion casse, le choix du siège répond.

Client
Skyjetz (UX Design Institute brief)
Rôle
UX Researcher / Product Designer
Année
2023
Disciplines
UX ResearchSynthesisInteraction DesignPrototypingDeveloper Handoff
Booking is where airlines lose people. I designed the part everyone hates.

La plupart des parcours de réservation aérienne sont l'endroit où les bonnes intentions meurent.

Trop d'étapes. Des coûts obligatoires cachés. Un écran de sélection de siège qui semble fait pour vous pousser à payer plus. Les utilisateurs le savent, et la recherche l'a confirmé : l'étape la plus pénible n'est ni la recherche ni le paiement, c'est le passage du milieu, où l'on choisit un vol avant d'être canalisé vers des options qu'on n'a pas demandées.

Skyjetz est une compagnie aérienne fictive en phase de lancement. Le brief consistait à concevoir son expérience de réservation de bout en bout, fondée sur une vraie recherche utilisateur. Je l'ai pris comme l'occasion de dérouler le processus complet sans les compromis qu'impose un calendrier commercial : benchmark, sondage, tests utilisateurs, synthèse, conception de flux, prototypage, et un transfert annoté complet, sur un seul projet. Après quinze ans de métier, j'ai rarement l'occasion de mener chaque étape correctement. Ce projet l'a permis.

Cette étude de cas est construite comme le travail l'a été : la recherche d'abord, les décisions ensuite, le design en troisième. Le microapp de sélection de siège, à la fin, n'est pas un showpiece séparé. C'est la preuve que la recherche a payé, la réponse à la douleur exacte que la carte de parcours a identifiée.

Une note sur le périmètre. Le flux de réservation de base a été fourni par le UX Design Institute. La recherche, la synthèse, le design d'interaction, les cas limites et états d'erreur, et le transfert sont les miens. C'était un projet UX : le livrable, ce sont des wireframes annotés en moyenne fidélité et un prototype cliquable, le flux, les états et la logique d'interaction, pas la couche de design visuel.

La recherche

Avant de concevoir quoi que ce soit, je devais savoir où la réservation casse réellement. J'ai mené trois méthodes de recherche et je les ai triangulées.

Benchmark concurrentiel. J'ai comparé l'utilisabilité de la réservation de plusieurs compagnies de référence, Air France, Air Canada, Norwegian, plus Google Flights en joker, sur trois zones : page d'accueil, recherche et sélection de vol, détails et paiement. Le but : identifier les conventions à suivre et repérer les mauvais schémas à corriger.

Un sondage en ligne. Quantitatif et qualitatif, pour comprendre objectifs, comportements et douleurs. Les résultats qui ont façonné le projet : une nette majorité réservait sur ordinateur plutôt que sur mobile, ce qui a fixé mon focus principal sur le desktop ; 50% priorisaient les dates sur le prix ; et surtout, les répondants désignaient les options ajoutées, choix du siège et bagages, comme la partie la plus pénible et la moins transparente. Dans leurs mots : trop d'étapes avant le paiement, et des prix qui cachent les coûts obligatoires jusqu'au dernier moment.

Tests utilisateurs et entretiens approfondis. Trois sessions menées par moi (deux à distance, une en présentiel) plus deux sessions enregistrées analysées en détail, sur quatre compagnies. Les constats récurrents : surcharge d'information, fonctionnalités qui déroutent sans explication, incertitude sur le fait qu'un prix couvre un ou plusieurs passagers, et un processus tout simplement difficile à suivre.

Trois méthodes, un signal cohérent. Le travail suivant : transformer un tas de constats en une direction.

Affinity diagram clustering research findings into booking-flow stages, a working artefact
Diagramme d'affinité regroupant les constats de recherche par étapes du flux de réservation, un artefact de travail

La synthèse

La recherche brute n'est pas une direction. Une liste de constats reste une liste de constats jusqu'à ce que quelque chose en fasse sortir une décision.

J'ai regroupé chaque observation sur des notes individuelles, par triangulation, d'abord selon les étapes du flux de réservation (formulaire de recherche, résultats, sélection de vol, upsell, paiement), puis en sous-groupes plus fins comme le sélecteur de dates et la carte de vol. Ordonner ces groupes dans l'ordre de réservation s'est traduit directement en une carte de parcours client, avec objectifs, comportements, moments positifs et points de douleur à chaque étape, les citations des tests épinglées là où elles tombaient.

La carte de parcours a confirmé la colonne vertébrale du projet. À chaque étape, une zone ressortait comme la plus pénible, et de loin : résultats de recherche, sélection de vol et upsell. L'upsell en particulier était décrit comme inutile et agaçant, l'endroit où les utilisateurs sentaient la réservation se retourner contre eux.

Cette synthèse m'a donné un focus plutôt qu'une liste de souhaits. L'effort de conception se concentrerait là où la douleur était la plus dense, le milieu du flux, et traiterait l'upsell non comme un ajout de revenu à tolérer, mais comme le problème UX le plus difficile à résoudre honnêtement. Chaque décision de design après ce point remonte à cette seule conclusion.

ÉTAPE 01

Des constats à un focus

Le problème
La recherche brute n'est pas une direction. Trois méthodes ont produit une montagne de constats, et une montagne de constats n'est pas un brief de conception. Il fallait que quelque chose en fasse sortir une décision.
La méthode
J'ai tout structuré par triangulation dans un diagramme d'affinité, puis ordonné les groupes dans l'ordre de réservation pour bâtir une carte de parcours client, objectifs, comportements, moments positifs et points de douleur à chaque étape, avec les citations des tests épinglées à leur place.
Je maîtrise
La décision de synthèse. Lire les données regroupées et la carte de parcours, et nommer la seule zone qui comptait le plus, plutôt que d'éparpiller l'effort de conception sur tout ce que les utilisateurs ont mentionné.
Le résultat
Un focus unique et défendable, recherche, sélection de vol et upsell, identifié comme la zone la plus pénible, et de loin. Un focus, pas une liste de souhaits. Chaque décision ultérieure y remonte.
Customer journey map identifying search and selection as the most painful zone, a working artefact
Carte de parcours client identifiant la recherche et la sélection comme la zone la plus pénible, un artefact de travail
ÉTAPE 02

Un parcours où l'on peut toujours se situer

Le problème
La réservation est multi-étapes par nature. Les utilisateurs se perdent, perdent confiance et abandonnent quand ils ne savent pas où ils en sont ni ce qui vient ensuite.
La méthode
À partir de la carte de parcours, j'ai construit le diagramme de flux, puis conçu la réservation autour d'un indicateur de progression persistant ancré sous l'en-tête, montrant les étapes terminées, l'étape en cours et ce qu'il reste, sur les huit étapes, de la recherche à la confirmation. Chaque écran garde l'utilisateur orienté.
Je maîtrise
L'architecture du flux et le choix de rendre la progression lisible à chaque étape. La structure en huit étapes et ses embranchements, invité ou connexion, récupération en l'absence de vol.
Le résultat
Un parcours linéaire sans impasse, où l'utilisateur sait toujours où il est et ce qu'il reste. L'orientation conçue dès le départ, et traçable directement jusqu'à la carte de parcours.
Booking flow diagram, eight stages with guest/login and no-flights branches
Diagramme du flux de réservation, huit étapes avec embranchements invité/connexion et absence de vol
ÉTAPE 03

Un formulaire de paiement qui detecte les erreurs avant la banque

Le problème
Le paiement est l'endroit où l'abandon coûte le plus cher. Un formulaire qui rejette une saisie trop tard, ou sans clarté, perd la réservation au dernier mètre.
La méthode
J'ai spécifié le formulaire de paiement jusqu'au détail d'interaction pour le transfert. Numéro de carte limité aux chiffres, regroupés par quatre avec espaces, validé au blur avec messages d'erreur précis, et détection du type de carte qui fait apparaître le logo de l'émetteur dans le champ après les premiers chiffres. La date d'expiration ajoute automatiquement le slash entre MM et AA. Le CVC est masqué avec une infobulle contextuelle. Le bouton Payer reste désactivé tant que tous les champs ne sont pas validés et les conditions acceptées.
Je maîtrise
Chaque regle de validation, message d'erreur, contrainte de saisie, et le moment ou le retour apparait. Le tissu conjonctif que la plupart des flux laissent au hasard.
Le résultat
Un formulaire documenté si complètement qu'un développeur pourrait le construire sans une seule supposition, et un utilisateur corrigé en douceur, sur place, avant tout échec. See full specs handoff document here
Annotated payment form specification with validation rules and error states
Spécification annotée du formulaire de paiement avec règles de validation et états d'erreur
ÉTAPE 04

Concevoir pour le moment où ça tourne mal

Le problème
La plupart des flux conçoivent le chemin idéal et oublient que les paiements échouent, que les vols se remplissent, que les serveurs ralentissent. C'est précisément là qu'un utilisateur risque le plus de partir pour de bon.
La méthode
J'ai conçu les états d'échec et les cas limites comme des écrans à part entière. Paiement échoué : on rassure d'abord (Pas d'inquiétude, aucun montant n'a été débité), puis on représente le formulaire pour une nouvelle tentative. Aucun vol disponible : un sélecteur de dates adjacentes plutôt qu'une impasse. Des écrans de traitement couvrent les temps d'attente pendant que la recherche et le paiement se résolvent.
Je maîtrise
Le choix de traiter la récupération d'erreur comme une expérience conçue, le texte rassurant, le chemin de récupération, la décision de ne jamais laisser un utilisateur bloqué.
Le résultat
Un parcours qui tient quand les choses cassent, le seul moment où une expérience de réservation est vraiment mise à l'épreuve. See full specs handoff document here
Payment unsuccessful screen with reassurance copy and recovery path
Écran de paiement échoué avec message rassurant et chemin de récupération

L'upsell, rendu honnête

Skyjetz (UX Design Institute brief) · 2023

La recherche avait nommé le coupable : l'upsell. La sélection de siège en particulier, le moment où, selon les utilisateurs, la réservation cessait de sembler honnête. Le choix du siège est donc devenu la partie du projet que je voulais le plus réussir, car la résoudre, c'était résoudre ce que la carte de parcours désignait comme le pire.

La réponse : un microapp de sélection de siège autonome, lancé depuis l'étape des options. Pas une page de plus dans la chaîne. Un module ciblé avec sa propre logique interne, conçu pour rendre la partie la plus mal aimée de la réservation la plus transparente.

Voici ce qu'il devait gérer. Deux passagers, deux tronçons d'un aller-retour, quatre décisions de siège indépendantes. Chaque passager a sa propre piste de sélection avec trois états : aucun siège sélectionné, sélection en cours, siège confirmé. On clique sur Sélectionner et le bouton devient Annuler tandis qu'une invite choisir un siège et le plan de cabine se mettent en évidence, l'interface signale que c'est à vous d'agir. On choisit un siège et l'état bascule : le bouton devient Modifier, et un contrôle libérer le siège ramène le passager au défaut. Un passager peut être entièrement réservé pendant que l'autre affiche encore aucun siège sélectionné, et le flux gère cet état partiel sans broncher. Le même processus se répète pour le tronçon retour dans son propre onglet.

Trois catégories tarifaires, Espace jambes accru, Économie confort, Économie standard, sont affichées ouvertement dans le panneau, le prix visible à chaque étape. La barre ancrée montre le total courant pour tous les passagers, mis à jour en direct (664 euros, puis 679,99, puis 727,96). La barre latérale détaille chaque frais par passager et par tronçon. Rien n'est caché jusqu'au paiement. Rien n'est une surprise.

C'est la recherche qui paie. La carte de parcours disait que la sélection de siège est l'endroit où la réservation semble trompeuse. J'ai donc conçu la version où le prix n'est jamais caché, l'état toujours clair, et l'utilisateur jamais piégé. L'upsell, rendu honnête, parce que la recherche m'a dit exactement quel moment rendre honnête.

Seat microapp in selecting state, button switched to Cancel and seat map highlighted
Microapp de siège en état de sélection, bouton passé à Annuler et plan de cabine mis en évidence
Seat microapp with one passenger seated and one still unselected, sidebar reflecting partial state
Microapp de siège avec un passager placé et un autre non sélectionné, barre latérale reflétant l'état partiel
Seat microapp with seats confirmed for both passengers across both legs, running total updated
Microapp de siège avec sièges confirmés pour les deux passagers sur les deux tronçons, total mis à jour

Ce que ça a livré

Un processus complet, du début à la fin

Benchmark, sondage, tests utilisateurs, diagramme d'affinité, carte de parcours, conception de flux, prototype et transfert développeur annoté. Chaque étape du processus UX, menée correctement sur un seul projet.

Une synthèse qui a choisi le combat

Le choix de se concentrer sur la recherche, la sélection et l'upsell n'était pas une intuition. Le diagramme d'affinité et la carte de parcours l'ont identifié comme la zone la plus pénible, et nommer ce focus est la décision sur laquelle reposent toutes les suivantes.

L'upsell, rendu honnête

Le microapp de siège a transformé la partie la plus mal aimée de la réservation en la plus transparente. Tarifs affichés, état clair, total courant en direct, aucun coût caché, une réponse directe au constat de la carte de parcours.

Un transfert sans devinette

Chaque page, composant, état d'écran, message d'erreur et interaction documentés pour l'ingénierie. Le genre de transfert qui se construit tel qu'il a été conçu.

The annotated wireframe handoff, every screen, state, and interaction documented
Le transfert en wireframes annotés, chaque écran, état et interaction documenté

C'était un brief académique avec un client fictif, et je l'assume. Mais la chaîne derrière, recherche, synthèse, une seule décision de focalisation, puis design, est celle que je mène sur de vrais produits, et le microapp de siège est le type de problème d'interaction, multi-états, multi-passagers, à enjeu commercial, qui distingue l'agencement d'écrans de la conception de systèmes. Si vous construisez un parcours dont la difficulté est de rendre honnête un moment compliqué qui touche à l'argent, c'est le travail que je fais.

Interroger les archives

Fondé sur les études de cas et le journal de ce site. Il dit quand il ne sait pas. Les questions sont enregistrées pour que Loïc voie ce que le site n’explique pas. Rien d’autre n’est conservé.

À propos de cet assistant ↗