J'ai travaillé en fintech et banque pendant environ un tiers de ma carrière de plus de dix ans : en commençant chez GFT au Brésil sur des tableaux de bord en temps réel pour des sociétés d'investissement, puis chez BNP Paribas Cardif comme développeur Angular, puis chez Wonderlabs comme développeur Angular et lead UX sur une PWA de carte de crédit au Canada, puis chez BMO comme développeur front-end sur une plateforme de demande de prêt. En dehors de la finance, j'ai travaillé sur une plateforme d'emploi, une plateforme de voyage de groupe, une plateforme de bilans de santé, mon propre produit SaaS et une plateforme de santé mentale. Le contraste est assez marqué pour que je veuille en écrire directement : designer pour la finance est réellement différent de designer pour d'autres secteurs, et les différences vont plus loin que les conventions esthétiques ou une palette de couleurs conservatrice.
Ce n'est pas un article sur comment rendre les applications bancaires modernes. C'est sur les contraintes de design fondamentales qui font du UX financier une discipline distincte, et comment travailler efficacement à l'intérieur de celles-ci.
La confiance est le produit
Dans la plupart des catégories logicielles, le produit est un ensemble de fonctionnalités. Les utilisateurs choisissent Slack pour son système de canaux et sa recherche, ou Notion pour son éditeur de blocs flexible. Dans les produits financiers, l'ensemble de fonctionnalités est le minimum. Le vrai produit est la confiance. Un utilisateur qui ne fait pas confiance à la sécurité de son argent, ou à l'exactitude des informations affichées, ne l'utilisera pas quel que soit l'élégance de l'interface.
Ça signifie que chaque décision de design dans un produit financier doit passer un filtre de confiance. Est-ce que ce pattern d'interface communique fiabilité et stabilité ? Est-ce que ce message d'erreur explique ce qui s'est passé clairement et honnêtement ? Est-ce que cet état de chargement rassure l'utilisateur que sa transaction est en cours de traitement, ou est-ce qu'il crée de l'anxiété ? Ce sont des questions qui ne se posent pas aussi intensément dans, disons, une application de réservation de voyage.
Signaux visuels de confiance
La confiance est partiellement communiquée visuellement. Le langage de design conservateur de la plupart des applications bancaires, couleurs atténuées, typographie claire, utilisation limitée d'éléments ludiques, n'est pas un échec de créativité. C'est un signal délibéré : ceci est une institution sérieuse et stable. Les utilisateurs ont été conditionnés à associer le calme visuel à la fiabilité financière, et s'écarter de cette convention nécessite un calibrage attentif.
Les design systems bancaires poussent vers un design visuel moderne et accessible tout en conservant les signaux de confiance que les utilisateurs attendent. La couleur primaire se tient dans une palette dominée par le bleu associée à la sécurité financière. La typographie est claire et lisible, jamais décorative. Les micro-interactions sont intentionnelles et informatives plutôt que délicieusement distractives. Chez BMO, je construisais des fonctionnalités avec le design system de la banque, qui appartenait à une autre équipe, et vu du siège du développeur, la leçon est le peu de place qu'un système comme celui-là devrait laisser à la variation ludique. Un bouton qui semble tonalement incohérent avec le contexte de déplacement d'argent coûte de la confiance, pas seulement des clics.
La conformité comme contrainte de design
Chaque décision de design dans un produit financier réglementé a une dimension légale. Dans la plupart des institutions financières, la conformité a son mot à dire avant le début du développement. Ce n'est pas un inconvénient bureaucratique : c'est une partie fondamentale du processus de design, et j'intègre les contraintes de conformité dès le premier wireframe plutôt que de les traiter comme une étape de revue finale.
Les contraintes de conformité dans le UX financier incluent : les divulgations obligatoires qui doivent apparaître à des emplacements spécifiques et à des tailles de police minimales, les étapes de confirmation requises avant les transactions irréversibles, le langage spécifique pour la divulgation des frais, l'expiration de session basée sur le temps avec notification appropriée de l'utilisateur, et les exigences de piste d'audit qui affectent comment les interactions sont journalisées et affichées.
En design fintech, la contrainte de conformité n'est pas l'ennemie du bon UX. C'est un brief de design du régulateur. Le défi est de la satisfaire d'une manière qui est aussi claire et utilisable.
Le problème de placement de divulgation est un bon exemple. Les exigences réglementaires mandatent souvent que les divulgations de frais apparaissent avant qu'un utilisateur confirme une transaction. Une implémentation naïve met ça comme un paragraphe de texte légal que les utilisateurs défilent immédiatement. Un meilleur design intègre la divulgation de manière significative : résumer l'information clé (Vous serez facturé 4,50 $ pour ce transfert) en langage clair, avec un lien vers le texte légal complet pour les utilisateurs qui le veulent. Ça satisfait l'exigence de conformité et sert l'utilisateur.
Gestion d'erreurs dans les flux financiers
Les états d'erreur dans les applications financières sont réellement à enjeux élevés. Un message d'erreur vague pendant un transfert de fonds ne crée pas juste de la frustration : il crée de la panique. L'argent a-t-il quitté mon compte ? Est-il perdu ? Dois-je réessayer ? Si l'utilisateur réessaie et que la première transaction est passée, il peut avoir envoyé l'argent deux fois. Ce n'est pas un cas limite théorique ; c'est un scénario que les équipes UX bancaires prennent très au sérieux.
Les principes que j'applique à la gestion d'erreurs dans les flux financiers, le déplacement d'argent étant le cas le plus difficile :
- Toujours dire à l'utilisateur l'état actuel de sa transaction. Si le transfert a échoué avant d'atteindre le réseau, dites-le. S'il a été soumis mais que la réponse a expiré, dites-le aussi et expliquez ce que ça signifie pour son solde.
- Ne jamais laisser l'utilisateur dans l'ambiguïté sur le fait que l'argent a bougé ou non. Même si vous ne connaissez pas le résultat, dites 'Nous confirmons votre transfert. Nous vous notifierons une fois que nous aurons la confirmation.' C'est mieux que le silence.
- Distinguer entre les erreurs utilisateur (mauvais format de numéro de compte) et les erreurs système (timeout réseau) dans le message, parce que l'action appropriée est différente dans chaque cas.
- Fournir un chemin de récupération clair. 'Veuillez réessayer' est insuffisant. 'Veuillez réessayer dans quelques minutes. Si le problème persiste, contactez-nous au 1-800-XXX-XXXX' est actionnable.
- Pour les erreurs irréversibles, fournir les coordonnées de contact immédiatement. Ne faites pas chercher un numéro de téléphone à un utilisateur paniqué.
Divulgation progressive pour les produits complexes
Les produits financiers sont intrinsèquement complexes. Une demande de prêt hypothécaire implique des dizaines de points de données, des questions conditionnelles, des accords légaux et une vérification multi-étapes. Une vue de portefeuille d'investissement implique des hiérarchies de données, des calculs de performance, des indicateurs de risque et des benchmarks comparatifs. Tout présenter d'un coup est cognitivement écrasant. Ne pas en présenter assez viole le besoin d'information de l'utilisateur quand il prend des décisions conséquentes.
La divulgation progressive, révéler l'information progressivement à mesure que l'utilisateur démontre son besoin ou sa disposition, est l'une des techniques les plus importantes en UX fintech. Dans un long formulaire de demande, cela veut dire révéler les questions en fonction des réponses précédentes (pas besoin de demander le revenu du conjoint si le demandeur a indiqué être célibataire) et fractionner le formulaire en ce qui ressemble à une conversation. C'est sur l'onboarding que le design de flux a le plus clairement payé pour moi : chez Wonderlabs, j'ai redesigné le flux d'onboarding de la plateforme de cartes de crédit à travers des cycles de prototypage et de tests, et l'engagement utilisateur a augmenté de 15 %.
Architecture de l'information en couches
La divulgation progressive s'applique pas seulement aux formulaires mais à l'affichage d'information. Le pattern se généralise bien à une vue de portefeuille : les métriques essentielles en un coup d'oeil, valeur totale, changement du jour, rendement global, et tout le reste à une expansion de distance. Par classe d'actifs, par titre individuel, par période de temps. Cette mise en couches respecte à la fois l'utilisateur qui veut une vérification rapide et celui qui veut une analyse approfondie, sans submerger l'un ou l'autre.
La sécurité comme pilier UX
Les exigences de sécurité dans les applications financières créent une vraie friction UX, et le défi de design est de minimiser cette friction sans compromettre le modèle de sécurité. Les timeouts de session, l'authentification à deux facteurs, les étapes de confirmation de transaction, la ré-authentification biométrique pour les actions sensibles. Tous existent pour des raisons légitimes, et tous ajoutent de la friction à l'expérience utilisateur.
L'insight clé que j'ai développé, c'est que la friction de sécurité est acceptable pour les utilisateurs quand elle est proportionnelle au niveau de risque de l'action et clairement expliquée. Ressaisir son mot de passe pour consulter son solde de compte semble absurde et intrusif. Ressaisir son mot de passe pour changer son compte bancaire lié semble raisonnable. Les utilisateurs comprennent pourquoi cette action mérite une vérification supplémentaire.
Le modèle vers lequel les banques convergent est l'authentification par niveaux de risque, où le niveau de friction s'adapte au montant et au type de transaction. Les transferts de routine et de faible valeur (payer une facture régulière sous un montant seuil) utilisent uniquement la biométrie. Les transferts de haute valeur ou inhabituels nécessitent biométrie plus code de confirmation. Les nouveaux bénéficiaires nécessitent un défi 2FA complet. Je n'ai pas conçu un de ces modèles moi-même, mais la discipline consistant à faire correspondre la friction au risque est la partie qui vaut la peine d'être copiée dans tout produit avec des actions conséquentes.
Accessibilité dans les industries réglementées
L'accessibilité dans les services financiers n'est pas juste une obligation éthique : dans beaucoup de juridictions c'est une obligation légale. Les banques canadiennes sont de réglementation fédérale, donc elles relèvent de la Loi canadienne sur l'accessibilité et de la Loi canadienne sur les droits de la personne plutôt que de la LAPHO ontarienne (Loi sur l'accessibilité pour les personnes handicapées de l'Ontario). La LAPHO couvre les organisations de réglementation provinciale en Ontario, dont les caisses populaires, et son Règlement sur les normes d'accessibilité intégrées (RNAI) utilise la WCAG 2.0 AA comme référence technique (avec des exceptions pour les critères 1.2.4 sous-titres en direct et 1.2.5 audiodescription). Chez BMO, les fonctionnalités que je construisais devaient être conformes en accessibilité, et je traite ça comme une partie du « terminé », pas comme une réflexion après coup.
Le UX financier a des défis d'accessibilité spécifiques que d'autres secteurs rencontrent moins fréquemment :
- Les tableaux de données complexes (historiques de transactions, vues de portefeuille) nécessitent un markup de tableau approprié avec des en-têtes de colonnes et de lignes pour les utilisateurs de lecteurs d'écran. Un tableau visuellement élégant qui se replie sur mobile et perd son contexte d'en-tête échoue en accessibilité.
- Les graphiques sont standards dans les applications financières mais intrinsèquement inaccessibles sans alternatives textuelles. Chaque graphique a besoin d'un résumé textuel et d'un tableau de données accessible alternatif.
- Les sessions limitées dans le temps créent un véritable défi d'accessibilité. Les utilisateurs avec des handicaps cognitifs ou moteurs peuvent avoir besoin de plus de temps pour compléter les transactions. Le critère WCAG 2.2.1 (Réglage du délai) est généralement satisfait par un avertissement avant l'expiration et un moyen simple de prolonger la session, et dans une application bancaire cet avertissement doit être annoncé aux utilisateurs de lecteur d'écran, pas seulement affiché comme un toast qui disparaît.
- Les messages d'erreur dans les formulaires financiers doivent être programmatiquement associés à leurs champs d'entrée pour que les lecteurs d'écran les annoncent correctement. C'est une exigence de développement qui commence à l'étape de spécification du design.
Ce qui se transfère depuis d'autres secteurs
Tout n'est pas différent en UX fintech. Les fondamentaux de la recherche utilisateur, des tests d'utilisabilité, de l'architecture de l'information et du design d'interaction s'appliquent partout. Le travail sur la plateforme de santé mentale m'a beaucoup appris sur le design pour les utilisateurs dans des états émotionnellement vulnérables, des leçons qui se transfèrent directement au UX financier, où les utilisateurs sont souvent stressés (compte à découvert), anxieux (volatilité du marché) ou submergés (demande de prêt hypothécaire).
Le changement en entrant dans le design fintech depuis d'autres secteurs est moins d'apprendre de nouvelles techniques et plus d'intérioriser un modèle de risque différent. En fintech, les conséquences d'une mauvaise expérience utilisateur ne sont pas juste des utilisateurs insatisfaits : ce sont des préjudices financiers, de la non-conformité réglementaire et l'érosion de la confiance qui est le fondement de tout le produit. Ce poids change comment on design, pour le mieux.
Références
- Financial Consumer Agency of Canada, Financial Consumer Protection Framework. https://www.canada.ca/en/financial-consumer-agency/services/banking/rights-new-protections/consumer-protection-framework.html
- WCAG 2.1 Understanding. https://www.w3.org/WAI/WCAG21/Understanding/
- Accessibility for Ontarians with Disabilities Act. https://www.ontario.ca/laws/statute/05a11
- Accessible Canada Act, résumé. https://www.canada.ca/en/employment-social-development/programs/accessible-people-disabilities/act-summary.html