Interfaces d’applications financières : rendre les opérations claires et sereines

Rendre les soldes compréhensibles en contexte

Un grand nombre ne s’explique pas tout seul. Indiquez le compte auquel il correspond et affichez la devise avec un symbole ou un code familier. Si le produit distingue les montants actuels, disponibles, en attente ou investis, nommez directement ces notions et expliquez-les si nécessaire. Évitez d’afficher deux types de soldes différents avec un style presque identique et sans définition.

Le contexte peut aussi préciser la date de dernière mise à jour du montant ou les opérations encore en attente. Choisissez les détails qui aident à interpréter l’écran plutôt que d’ajouter des chiffres décoratifs. Utilisez un format numérique cohérent et un espacement suffisant pour distinguer les chiffres, les séparateurs décimaux et les signes moins. Pour les noms de compte longs, conservez assez de texte pour les différencier sans dépendre uniquement d’une couleur ou d’une icône.

• Placez un libellé de compte et une devise explicites près du montant.
• Expliquez en termes simples les notions spécialisées telles que « disponible » ou « en attente ».
• Veillez à ce que le montant et son état restent compréhensibles avec un texte agrandi et les technologies d’assistance.

Montrer l’état d’une transaction au fil de son évolution

Une transaction est un processus, pas seulement une ligne dans un historique. Pour chaque opération, indiquez selon le cas un état concis, une date, un montant et une contrepartie ou une destination. Gardez l’état visible sous forme de texte ; une couleur ou une icône peut le renforcer, mais ne doit pas en porter seule le sens. Distinguez les opérations en attente, terminées, refusées ou nécessitant une intervention, selon les états réels du produit.

Par exemple, un virement hypothétique de 45,00 EUR à Alex pourrait d’abord indiquer « Prévu pour le 4 novembre », puis « En cours de traitement » et enfin « Terminé ». Si la connexion expire après l’envoi, n’annoncez pas avec certitude une réussite ou un échec sans preuve. Dites que l’état n’est pas encore disponible, expliquez comment le vérifier à nouveau et précisez si une nouvelle tentative risque de créer une autre demande. La formulation exacte et les actions disponibles dépendent du comportement réel des transactions du produit.

Concevoir des formulaires financiers qui évitent les confusions prévisibles

Demandez les informations lorsqu’elles sont nécessaires à la tâche et regroupez les champs liés dans un ordre logique. Utilisez des libellés permanents comme « Destinataire » ou « Montant » ; un texte indicatif donne un exemple, il ne remplace pas un libellé. Si un champ attend un format particulier, précisez-le avant la saisie : par exemple, si le montant accepte les centimes ou quel identifiant doit y figurer. Les recommandations d’Apple sur la saisie de données conseillent de clarifier les informations demandées, de limiter les saisies inutiles et de valider les valeurs au fur et à mesure.

Choisissez des contrôles adaptés aux informations et permettez de corriger les saisies. Indiquez clairement quels champs sont facultatifs ou obligatoires. Si un choix a des conséquences, décrivez les options en termes simples plutôt que de faire deviner le sens de codes courts. Les indications d’un champ doivent rester assez proches du contrôle pour être compréhensibles lorsque l’écran se réorganise ou s’agrandit.

Prévoir une vérification et une confirmation utiles

Avant une action lourde de conséquences, récapitulez les informations qui vont être envoyées : provenance, destination, montant, date, ainsi que les frais affichés ou les délais pertinents. Rassemblez les détails décisifs et rendez les possibilités de modification faciles à trouver. L’action principale doit décrire ce qu’elle fait, par exemple « Programmer le virement » au lieu d’un « Continuer » ambigu.

Un écran de confirmation doit répondre à « Que s’est-il passé ? » et « Que puis-je faire maintenant ? ». Une référence ou un reçu peut aider à retrouver l’opération plus tard. Ne considérez pas l’appui sur un bouton comme une preuve de réussite de l’opération sous-jacente : l’interface doit refléter le résultat réel renvoyé par le produit.

• Assurez-vous que le récapitulatif correspond aux valeurs saisies et aux options choisies.
• Dans la mesure du possible, les actions de retour et de modification doivent préserver le travail de l’utilisateur.
• Après l’envoi, indiquez si la demande a été reçue, est en cours de traitement ou a abouti à un résultat confirmé.
• En cas de réponse incertaine, expliquez comment vérifier l’état actuel avant de proposer un nouvel envoi.

Rendre les erreurs et les mises à jour accessibles

Lorsqu’une erreur de saisie est détectée, identifiez le champ et décrivez le problème en texte. « Montant invalide » est moins utile qu’un message indiquant le format accepté ou la valeur manquante. Conservez les saisies valides afin qu’un seul problème puisse être corrigé sans recommencer. Les recommandations WCAG 2.2 du W3C demandent d’identifier et de décrire les erreurs de saisie détectées, et de fournir des libellés ou des instructions lorsque la saisie est obligatoire.

Les changements d’état comptent aussi. Si une page passe de « En cours de traitement » à « Terminé » sans déplacer le focus, exposez la mise à jour d’une façon perceptible par les technologies d’assistance. Les WCAG 2.2 décrivent les messages d’état comme des changements communiquant un résultat, une attente, une progression ou une erreur sans imposer de changement de contexte. Gardez des alertes proportionnées : annoncez les changements significatifs sans interrompre sans cesse la personne à chaque rafraîchissement visuel.

Vérifiez dans l’interface réalisée le contraste, l’agrandissement du texte, l’accès au clavier ou par contacteur et les noms lus par les lecteurs d’écran. Utilisez des titres et des libellés de contrôle clairs, et ne signalez pas la réussite, l’erreur ou le sens d’une transaction par la seule couleur. Les principes de conception d’Apple insistent sur un retour clair et une aide à la correction des erreurs ; ces objectifs sont utiles, mais l’accessibilité réelle exige l’évaluation du produit complet.

Liste de contrôle d’une interface financière

Parcourez une tâche typique depuis le solde initial jusqu’à l’état final. Examinez le parcours habituel, une correction et une interruption, telle qu’une connexion lente. Comparez des écrans mobiles apparentés dans la bibliothèque pour voir comment différentes interfaces organisent les informations et les actions, puis évaluez votre parcours selon le comportement réel de votre produit.

• Peut-on comprendre à quel compte et à quelle devise correspond un solde ?
• Les états en attente et terminés sont-ils nommés clairement et affichés en texte ?
• Chaque champ possède-t-il un libellé visible et, si nécessaire, une indication de format ?
• Peut-on vérifier la destination, le montant et le délai avant l’envoi ?
• Les erreurs identifient-elles le problème et proposent-elles une correction pratique ?
• Une mise à jour reste-t-elle perceptible sans dépendre de la couleur, d’une vision précise ou d’un déplacement du focus ?
• Lorsque le résultat est incertain, l’interface explique-t-elle comment le vérifier avant de réessayer ?