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

Les répondants ont désigné le choix du siège comme le pire moment de la réservation. Je l'ai reconçu.

Un processus UX complet pour une compagnie aérienne fictive, de la recherche au transfert annoté. La recherche a montré où la réservation fait le plus mal, et le choix du siège y répond.

Client
Skyjetz (UX Design Institute brief)
Rôle
UX Researcher / Product Designer
Année
2023
Disciplines
UX researchSynthesisInteraction designPrototypingDeveloper handoff
Survey respondents called seat selection the worst part of booking. I redesigned it.

Les parcours de réservation aérienne perdent les gens en plein milieu.

Trop d'étapes, des coûts obligatoires cachés, et 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 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.

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. La micro-app de sélection de siège, à la fin, répond au point de friction précis que la carte de parcours a identifié.

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. La couche de design visuel était hors périmètre.

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 irritants. Les résultats qui ont façonné le projet, sur 22 répondants : une nette majorité réservait sur ordinateur plutôt que sur mobile, ce qui a fait du desktop ma priorité ; 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é une priorité claire. L'effort de conception se concentrerait là où les frictions étaient les plus denses, 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 à une priorité

Le problème
Trois méthodes ont produit une montagne de constats. 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 friction à 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.
Le résultat
Une priorité unique et défendable, recherche, sélection de vol et upsell, identifiée comme la zone la plus pénible, et de loin.
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 détecte 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é à la sortie du champ 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 règle de validation, message d'erreur, contrainte de saisie, et le moment où le retour apparaît. 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 réaffiche le formulaire pour une nouvelle tentative. Aucun vol disponible : un sélecteur de dates adjacentes pour relancer la recherche. Des écrans de traitement couvrent les temps d'attente pendant le traitement de la recherche et du paiement.
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 désigné l'upsell comme le coupable. 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 a été une micro-app de sélection de siège autonome, lancée depuis l'étape des options, 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.

La micro-app devait gérer deux passagers, deux tronçons d'un aller-retour, soit 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 à l'état par 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 cumulé 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.

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é.

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 donné

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 son combat

Le diagramme d'affinité et la carte de parcours ont désigné la recherche, la sélection et l'upsell comme la zone la plus pénible, et nommer cette priorité est la décision sur laquelle reposent toutes les suivantes.

L'upsell, rendu honnête

La micro-app 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 approximation

Chaque page, composant, état d'écran, message d'erreur et interaction documentés pour les développeurs.

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 la micro-app 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 ↗