Une étude de concept Webtrix : comment un tableau de bord de paiements transfrontaliers doit guider une équipe financière qui règle des fournisseurs en plusieurs devises.
Type
Étude de concept (produit fictif)
Durée
6 semaines
Outils
Figma, Maze
Équipe
Studio de design Webtrix
Le brief
FlowPay est une plateforme B2B fictive de paiements transfrontaliers, imaginée pour une entreprise de taille moyenne qui règle des fournisseurs au Maroc et à l'étranger en dirhams, en euros et en dollars. Nous en faisons une étude : à quoi ressemble un tableau de bord de paiement quand le vrai travail de l'équipe financière est d'être sûre, pas d'aller vite ?
L'exercice couvre l'ensemble du tableau de bord, de la création d'un paiement au reporting, et pose une seule question à chaque écran : supprime-t-il une décision que l'utilisateur ne devrait pas avoir à prendre ?
Là où les parcours de paiement se brisent
Les outils de paiement s'enrichissent exigence après exigence. Le résultat habituel : une interface encombrée, une navigation qui suit l'organigramme de l'éditeur plutôt que la tâche de l'utilisateur, et un long formulaire pas à pas, encore pire sur mobile. Nous avons posé ces problèmes de départ, courants dans la catégorie, et conçu contre eux.
- Créer un paiement demande sept étapes, avec les mêmes informations ressaisies pour les fournisseurs récurrents
- La version mobile est un écran de bureau rétréci, pas un écran conçu pour le mobile
- Les nouveaux utilisateurs ne savent pas quelle option de paiement s'applique à quelle devise
- Les paiements groupés existent, mais se cachent derrière plusieurs menus
- Les rapports exigent des exports manuels car rien ne se met à jour en temps réel
Ce que nous avons examiné
Une étude documentaire de deux semaines : analyse de la façon dont les produits de paiement existants gèrent le multidevise, documentation publique des prestataires de paiement et notes de workflow sur la manière dont une équipe financière prépare, valide et rapproche un paiement fournisseur.
Ce que l'analyse a fait ressortir
- Les options de paiement sont présentées par prestataire plutôt que par objectif de l'utilisateur (payer maintenant, planifier, fractionner)
- Les paiements récurrents sont la tâche la plus fréquente, mais sont conçus comme des premiers paiements
- Les équipes financières cherchent d'abord le paiement groupé et le trouvent rarement
- Le reporting est un export, pas une vue en direct
Pistes explorées
Nous avons mené un sprint de design de deux jours pour explorer le fonctionnement du parcours de paiement : croquis rapides, cartes mentales et vote par points pour comparer les idées à la question posée plus haut.
Trois pistes en sont sorties. Nous avons retenu « StreamFlow » : un concept qui traite la création d'un paiement comme un parcours guidé et contextuel plutôt que comme un formulaire rigide pas à pas.
Le parcours de paiement en trois étapes
Nous avons cartographié le parcours de la connexion à la confirmation du paiement. L'objectif de conception est de ramener le parcours de sept étapes à trois, tout en conservant toutes les vérifications qu'exige une équipe financière.
- Détails du paiement — valeurs par défaut intelligentes et saisie automatique à partir de l'historique
- Vérifier et confirmer — toutes les informations sur un seul écran, avec modification en ligne
- Confirmation — statut en temps réel avec durée de traitement estimée
Wireframes
Objectif de conception : trois étapes au lieu de sept, avec toutes les vérifications conservées.
Système visuel
Une interface de paiement doit inspirer confiance sans paraître froide. Le système visuel associe une palette de couleurs sobre à une hiérarchie typographique claire, pour que les montants, les devises et les statuts se lisent d'un coup d'œil.
Plan de validation
Le prototype haute fidélité est réalisé dans Figma. Cette étude n'a pas été testée avec de vrais utilisateurs ; le plan ci-dessous décrit comment nous la validerions avant toute réalisation, avec Maze pour des sessions non modérées.
5
Participants prévus par session de test
3
Sessions de test prévues
90%
Objectif : taux de réussite des tâches
Itérations de conception
Itération 1 : Création d'un paiement simplifiée, de cinq champs à trois, avec des valeurs par défaut intelligentes pour les fournisseurs récurrents. Objectif de conception : terminer plus vite la tâche la plus courante.
Itération 2 : Version mobile repensée en une seule colonne, avec des zones tactiles plus grandes et des sections repliables. Objectif de conception : que le mobile et le bureau mènent au même résultat.
AvantAprèsLe design proposé
La proposition, « StreamFlow », est une expérience de paiement claire et rassurante sur tous les appareils. Ses principales fonctionnalités :
- Parcours de paiement guidé en 3 étapes avec aide contextuelle
- Suivi des transactions en temps réel avec notifications push
- Traitement des paiements groupés pour les clients grands comptes
- Tableau de bord de reporting personnalisable avec options d'export
- Mode sombre visant les contrastes WCAG AA
- Design responsive pensé d'abord pour le mobile, avec navigation par gestes
Objectifs de conception
7 → 3
Étapes du parcours de paiement (conception)
-30%
Objectif : temps nécessaire pour effectuer un paiement
-40%
Objectif : sollicitations du support par les nouveaux utilisateurs
Ce sont des objectifs de conception pour une étude de concept, et non des résultats mesurés : le design n'a été ni livré ni testé avec de vrais utilisateurs.
Chaque étape doit mériter sa place : si un champ peut être déduit, on ne le demande pas.
Ce que l'étude nous a appris
- Planifier les tests d'utilisabilité avant que l'interface soit finalisée ; modifier un wireframe coûte moins cher
- Les utilisateurs de la finance privilégient la confiance et la clarté plutôt que l'effet visuel
- Mobile first ne veut pas dire mobile only : les utilisateurs avancés ont besoin de toutes les fonctions sur ordinateur
- Impliquer tôt les ingénieurs garde le design réalisable
Si ce projet était réalisé
- Valider le parcours avec le plan de test ci-dessus avant toute réalisation
- Transformer le design system en bibliothèque de composants partagée
- Connecter le tableau de bord à de vraies données comptables et bancaires via des intégrations
- Ajouter la catégorisation des paiements par IA seulement une fois que des données propres existent
