Étude de cas
Messagerie financière interbancaire
Swift
Design de service pour la résolution des litiges de paiement internationaux, sur un réseau qui relie des milliers de banques.
Résultat clé
Les litiges qui se réglaient par e-mails interposés passent davantage par un dossier commun, plus lisible pour chaque partie et plus rapide à faire avancer.
01 Case Management
Ouvrir et suivre un litige interbancaire.
Contexte
Quand un paiement interbancaire n'arrive pas, la réclamation engage plusieurs institutions à la fois, chacune avec ses délais et ses obligations. Le traitement reposait sur un modèle de support fragmenté : un chemin par type de litige, et des types entiers encore traités hors outil. L'enjeu dépassait donc les écrans : passer d'un support fragmenté à un service, avec un seul cycle de réclamation, de l'ouverture à la clôture, lisible par toutes les parties.
Objectifs
- Réduire le temps de résolution — reprendre tout le cycle de réclamation et étendre la couverture aux types d'investigation encore traités hors outil.
- Rendre l'état d'un dossier lisible — les utilisateurs suivent des écarts financiers et des suspicions de fraude : ils doivent savoir à tout moment qui a la main, ce qui est attendu d'eux et sous quel délai.
- Tenir les contraintes du réseau — concilier ce que le réseau Swift impose techniquement avec des façons de travailler qui varient d'une institution à l'autre, des États-Unis à l'Asie.
- Rester extensible — livrer une base qui absorbe les types d'investigation suivants sans re-conception, dans la stratégie de qualité de service de Swift.
Approche & solutions
- Design Critique métier et IT — ateliers avec le Product Owner, les juristes et les architectes techniques. Les arbitrages d'interface se prenaient là, avec ceux qui portent la contrainte.
- Recherche utilisateur — entretiens avec des banques et des organismes financiers, pour confronter le parcours cible au travail réel des équipes qui traitent les réclamations.
- Prototype comme support de décision — un prototype haute fidélité utilisé pour trancher en atelier, puis pour présenter le service à la communauté bancaire au SIBOS, la conférence organisée par Swift.
- Équipe répartie sur trois zones — rituels projet en équipe pluridisciplinaire entre les États-Unis, l'Europe et l'Asie. Avec le décalage horaire, les décisions doivent être écrites : on ne peut pas toujours les expliquer en direct.
Résultats
- Un dossier commun — ce qui se négociait par e-mails entre les parties avance sur un dossier partagé : ouverture, suivi et clôture se font dans le même outil.
- Une seule interface — on ouvre et on suit un litige de la même façon, quel que soit son type ; auparavant, chaque type avait son propre chemin.
- Une référence partagée — le prototype a servi de référence commune aux trois zones, ce qui a rendu le travail asynchrone praticable.
Le parcours d'ouverture
Cinq écrans, du paiement à l'envoi. Le parcours existant annonçait quatorze champs à remplir sur quatre écrans, dont plusieurs que le réseau connaissait déjà. Voici ce qu'il en reste une fois le paiement placé en premier.
02 Design System
Les fondations du système, et leur gouvernance.
Contexte
Plusieurs équipes construisent en parallèle des plateformes internes denses en données, chacune avec son autonomie de design et de technique. Cette autonomie leur permet d'avancer vite. Elle coûte cher quand la fondation ne tranche pas : les patterns divergent et le travail se refait. La palette en était l'exemple le plus net : dix gris teintés dont deux rigoureusement identiques, cinq valeurs pour la couleur principale, une seule pour le succès, aucune pour l'information. Chaque équipe complétait donc la sienne. Mon rôle : rendre la fondation assez précise pour que personne n'ait plus à la compléter.
Objectifs
- Une fondation sans ambiguïté — qu'un designer ou un développeur trouve la bonne valeur sans arbitrer lui-même : une échelle complète par famille, et une règle d'usage écrite pour chaque palier.
- Mesurer le contraste — évaluer chaque valeur en contraste APCA sur texte clair et sur texte sombre, pour que l'accessibilité soit réglée dans le token et non vérifiée en fin de projet.
- Tenir l'adoption dans la durée — faire en sorte que les équipes reprennent la bibliothèque : rituels d'alignement au sein de la UX Community of Excellence, et documentation tenue dans Figma et Zeroheight.
- Absorber les cas suivants — le mode sombre, la data visualisation et les modules à venir devaient entrer dans le même système sans avoir à le rouvrir.
Approche & solutions
- Reprendre les neutres avant les couleurs — les gris portaient une teinte et un doublon exact. Onze paliers neutres sont posés d'abord, parce que tout le reste se compare à eux : fonds, filets, textes secondaires.
- Étendre chaque famille de 0 à 900 — Peppermint passe de cinq valeurs à dix, Lavender de trois à dix, et une famille manquait entièrement : Pelorus, créée pour l'information.
- Écrire les seuils dans le système — Lc 60 comme limite du texte courant, en dessous grands corps, filets ou décor ; et entre 400 et 500, la zone où le texte passe du sombre au clair. Cet arbitrage se faisait à l'œil ; il est maintenant documenté palier par palier.
- Séparer la data visualisation — quatre séries hiérarchisées et deux contextes neutres, pour qu'un graphique cesse d'emprunter à la couleur de l'interface et de dire par accident ce qui est important.
- Restructurer les composants — composants Figma repris en auto-layout, grille typographique et règles d'espacement alignées, variantes claires et sombres traitées en même temps.
Résultats
- Moins d'arbitrages en revue — les écarts de couleur et d'espacement se règlent en appliquant le système, sans débat en revue de design entre le développeur, le PO et le designer.
- Un contraste vérifiable — chaque palier porte sa mesure : on peut dire ce qui est utilisable pour du texte, et sur quelle base, sans rouvrir un outil de contrôle à chaque écran.
- Une base que les équipes reprennent — le système sert de référence commune aux modules existants et aux projets suivants, y compris pour le mode sombre et la data visualisation, qui n'avaient pas de réponse avant.
Les planches de fondation
Six planches de la documentation du système, sur la couche couleur : les neutres repris, les familles de marque étendues, le contraste mesuré palier par palier, les couleurs de statut, les séries de data visualisation, et la matrice qui les rassemble.
Poursuivre la lecture
Deux autres écosystèmes B2B.
Énergie
Elia
Pilotage du projet EPIC, plateforme B2B unifiée pour les acteurs connectés au réseau électrique belge. De la recherche utilisateur au prototype haute-fidélité.
Télécom
Proximus
Vingt-cinq entretiens avec des indépendants pour refondre la page Bizz Online (+38 % de conversion), puis une recherche sur la perception des prix.