← Retour aux travaux

OUIGO

' 26
Client
OUIGO
Rôle
Founding Designer
Utilisateurs
2,2M+ / mois
Statut
En cours
Contexte
DS Lead solo chez OUIGO : trois bibliothèques Figma se présentaient chacune comme la référence officielle — un même composant existait en trois variantes, aucune source de vérité.
Objectif
Repartir d'un audit pour construire une architecture token à 3 niveaux, puis refondre le tunnel de vente — de la recherche à la confirmation — pour réduire les frictions, rassurer l'acheteur et améliorer la conversion : un levier business, pas une simple démonstration du Design System.
Résultat
Un Design System noté 82/100 (contre 31 et 28 pour les deux bibliothèques abandonnées), et un tunnel de vente refondu validé par des tests utilisateurs très positifs — 7,5/10 de satisfaction, 0 rage click — croisés à 2 257 events PostHog.
Une famille embarque à bord d'un TGV OUIGO, Gare de Lyon
Un TGV OUIGO traverse la campagne française

Verbatim —

« En 2 mois on a plus avancé sur nos sujets qu'en 6 mois »

Illustration isométrique : deux tours de blocs fissurées marquées 31 et 28, symbolisant les deux bibliothèques Figma abandonnées
01

Auditer trois sources concurrentes, trancher

Score d'audit 31/100 et 28/100 pour les deux bibliothèques existantes — décision de repartir de zéro plutôt que de les réconcilier.

Objectif
Évaluer les trois bibliothèques Figma qui se présentaient chacune comme la référence officielle, sur 9 critères, pour trancher une fois pour toutes.
Contexte
Un même composant existait en trois variantes, un rebrand impliquait de modifier chaque frame à la main, le handoff développeur reposait sur des annotations manuelles. Coût d'une incohérence détectée en production : ×5 à ×10 (IBM Design).
Méthodes
Audit sur 9 critères, scoring comparatif des 3 sources, décision de construction d'une architecture à 3 niveaux.
Illustration isométrique : structure en 3 couches empilées, tokens qui se propagent vers des composants d'interface
02

Construire une architecture token à 3 niveaux

1 token modifié dans System = propagation instantanée sur tous les composants. Le même switch active le dark mode, un rebrand marque, ou la brand Ouiswap — sans retoucher un seul composant.

Objectif
Un seul point de changement, propagation sur tout le système — la convention Material 3 sert de référence structurelle, jamais de source de couleurs.
Contexte
Primitifs (147 valeurs brutes, aucun mode) → Brand (2, alias marque) → System (98 tokens sémantiques, Light/Dark) → Responsive (64, 5 modes Mobile → XWide). 309 variables au total, 4 collections.
Méthodes
Extraction du UI Kit existant, tri sémantique dans FigJam par famille (Rose, Bleu foncé, Bleu clair, Neutral, Status), tokens sémantiques donnant un rôle aux primitifs, composants qui ne contiennent jamais un hex.
Illustration isométrique : icônes de balance et d'arbitrage au centre d'une composition de blocs
03

Unifier le contenu, 593 liaisons appliquées

Chaque texte bindé se met à jour en un seul endroit — 399 bindings sur la page de confirmation du parcours de vente, 194 sur les pages Après-Vente.

Objectif
Résoudre les 7 incohérences de wording documentées entre écrans (durée d'embarquement GV « 30mn » vs « 40mn », âge Toupti « - 4 ans » vs « De 0 à 3 ans »…).
Contexte
333 variables Figma de type String construites à partir d'un scan du tunnel réel en conditions de production et des CSV marketing, couvrant recherche, packs, options, siège, paiement et après-vente.
Méthodes
Scan du tunnel en production, collection de variables String injectables directement dans les composants, 593 bindings appliqués par script MCP, voice & tone documenté.
Illustration isométrique : icônes de recherche, paiement et sécurité représentant les étapes du tunnel de vente
04

Refondre le tunnel de vente, de la recherche à la confirmation

Un objectif business explicite, pas une simple démonstration du Design System : réduire la friction, rassurer l'acheteur avant paiement, et améliorer la conversion sur l'ensemble du parcours d'achat.

Objectif
Refondre entièrement le tunnel — recherche, comparaison, packs, options, coordonnées, siège, paiement, confirmation — comme un vrai levier business plutôt qu'un simple prototype de composants.
Contexte
Implémentation complète en Next.js, mobile-first strict à 430px, 5 scénarios de données (nominal, sold-out, correspondance, Toupti, animaux), 22+ composants DS atoms, 0 hex hardcodé, ~98% de fidélité iso-Figma, v81 versions auto-déployées sur Vercel à chaque push.
Méthodes
Spécification vivante : chaque décision de refonte se prouve dans un vrai navigateur, sur l'intégralité du tunnel, avant d'être soumise au terrain.
Illustration isométrique : icônes de portefeuille et de paiement représentant les signaux business positifs
05

Des résultats très positifs qui confirment la refonte

Satisfaction 7,5/10, effort perçu quasi nul (2,3/7), réassurance à 1,62/5 — le meilleur score de toute la grille de test. Les objectifs business de la refonte sont validés par l'usage.

Objectif
Vérifier par l'usage réel que la refonte atteint ses objectifs business — réduire les frictions, rassurer, convertir — avant tout arbitrage éditorial supplémentaire.
Contexte
Session de tests utilisateurs (n=16, grille d'observation 27 items, 21–24 juillet 2026) croisée à 4 jours de données PostHog (2 257 events, 55 session recordings, heatmaps click).
Méthodes
Étapes clés validées à ≥85% (recherche 88%, comparaison trajets 93–100%, page packs non perçue comme un frein 94%, promo repérée et paiement finalisé 93–100%). Signaux business confirmés : 62% des participants choisissent Pack Plus (positionnement « best deal » validé), 44% paient via wallets Apple Pay/Google Pay (la réduction de friction PSP convertit), 0 rage click sur 55 sessions enregistrées. 3 frictions mineures identifiées, déjà transformées en 3 corrections livrées au backlog produit.

Verbatim, tests utilisateurs —

« Épuré, bien fait, dans l'air du temps. »

En chiffres —

Une architecture à 3 niveaux, un tunnel de vente refondu autour d'un objectif business clair — réduire la friction, rassurer, convertir — validé par l'usage, pas seulement par le fichier.

82/100score DS Core, contre 31 et 28 pour les sources abandonnées
7,5/10satisfaction globale, tests utilisateurs (n=16)
309variables Figma, 4 collections
593bindings de contenu appliqués
1,62/5rassurant ↔ inquiétant — meilleur score de toute la grille
0rage click détecté sur 55 sessions enregistrées

Étude de cas complète —

Télécharger le PDF

8 pages · audit, architecture token, contenu, refonte du tunnel de vente, résultats.

Télécharger

Aujourd'hui —

Le tunnel de vente n'est plus un tunnel parmi d'autres — c'est devenu le levier business qu'OUIGO attendait, porté par un Design System qui tient tout l'écosystème.

Projet suivant

FDJ — Améliorer la prise de jeu tirage