Le mot 'tableau de bord' est surchargé au point de perdre tout sens dans le design logiciel. J'ai vu tout, d'un seul indicateur KPI à un affichage analytique de 40 panneaux, être appelé tableau de bord. Dans les logiciels financiers spécifiquement, les tableaux de bord existent pour un seul objectif : aider quelqu'un à prendre une décision ou à effectuer une action. Si un utilisateur regarde un tableau de bord et s'en va sans décider ou agir, le tableau de bord a échoué. Peu importe la quantité de données affichées ou la qualité visuelle.
Au cours de ma carrière, des tableaux de bord de trading en temps réel pour des sociétés d'investissement que j'ai construits chez GFT aux tableaux de bord de reporting que j'ai construits dans Data Studio comme stagiaire chez iRestify, j'ai conçu et itéré sur un bon nombre de tableaux de bord de données financières et opérationnelles. Cet article distille les principes et patterns qui ont tenu la route dans tous ces cas.
Commencez par la décision, pas par les données
L'erreur la plus courante que je vois dans le design de tableaux de bord financiers est le design piloté par les données. Une partie prenante demande un tableau de bord, liste toutes les données qu'elle veut voir, et le designer arrange ces données dans des panneaux. Le résultat est un tableau de bord exhaustif mais pas utile. Il répond à beaucoup de questions que personne ne posait et est muet sur les questions que les utilisateurs ont réellement.
Mon point de départ est toujours un inventaire de décisions. Quelles décisions cet utilisateur prend-il ? À quelle fréquence ? Avec quel niveau d'urgence ? Un directeur d'agence consultant un tableau de bord opérationnel matinal prend des décisions différentes, et a besoin d'informations différentes, qu'un analyste de crédit examinant un portefeuille de prêts. Le fait que les deux regardent des données financières est presque sans rapport avec le design.
Prenez un tableau de bord de portefeuille de prêts pour un analyste de crédit. Les décisions quotidiennes principales : quels comptes dérivent vers le défaut de paiement, quelles demandes traînent en révision au-delà de la cible de service, et où se situe le portefeuille par rapport à ses limites de risque et de volume. Trois décisions. Tout sur le tableau de bord est évalué par rapport à sa contribution à l'une de ces trois. Si un point de données ne se connecte à aucune d'elles, il n'a pas sa place sur le tableau de bord principal. Il va dans une vue de drill-down accessible à la demande.
Hiérarchie de l'information : le pattern en F ne suffit pas
La plupart des guides UX recommandent de concevoir pour le comportement de lecture en pattern F. Les utilisateurs scannent le haut de la page, puis le long du côté gauche. C'est exact pour le contenu éditorial. Pour les tableaux de bord d'aide à la décision, le pattern de lecture est différent : les utilisateurs scannent les anomalies, pas l'information dans l'ordre de lecture. Ils cherchent quelque chose qui ne va pas, qui est inattendu, ou qui nécessite une action.
Cela change fondamentalement la hiérarchie de l'information. L'information la plus importante sur un tableau de bord financier n'est pas le chiffre le plus proéminent. C'est le chiffre qui est hors de sa plage normale. Concevez pour la mise en évidence des exceptions plutôt que pour l'exhaustivité. Les indicateurs de statut, les changements de couleur basés sur des seuils et les flèches de tendance sont plus précieux que les chiffres précis quand le cas d'usage principal est la détection d'exceptions.
En pratique, je conçois les tableaux de bord financiers avec trois zones de poids visuel. La zone un est la zone d'exception. Les éléments qui nécessitent une action ou une attention, toujours en haut ou en position gauche proéminente. La zone deux est la zone de statut. L'état actuel des métriques clés, confirmant que les opérations normales se poursuivent. La zone trois est la zone de contexte. Tendances historiques et données comparatives qui aident à interpréter les deux premières zones.
Design de cartes KPI : ce qui compte vraiment
Les cartes KPI sont l'élément le plus courant dans les tableaux de bord financiers, et aussi le plus couramment mal conçu. Une carte KPI qui ne montre qu'un chiffre ne dit à l'utilisateur presque rien. Une carte KPI qui montre un chiffre en contexte dit à l'utilisateur s'il doit s'inquiéter.
Les éléments que j'inclus dans une carte KPI bien conçue : la valeur actuelle (primaire), la référence de comparaison (vs période précédente, vs objectif, ou vs budget), l'indicateur directionnel (flèche haut/bas/neutre), l'amplitude du changement (pourcentage ou absolu), et la période couverte par la valeur. C'est cinq informations dans une carte compacte. Le défi de design est de les arranger pour que l'information la plus pertinente pour la décision, généralement la comparaison et la direction, soit la plus visuellement proéminente, pas le chiffre absolu.
Les conventions de couleur sur les cartes KPI doivent être utilisées avec précaution dans les applications financières. Le rouge ne signifie pas universellement mauvais en finance. Un indicateur rouge sur les réserves pour pertes sur prêts pourrait signifier que la réserve est en dessous des niveaux requis. Clairement mauvais. Un indicateur rouge sur un centre de coûts pourrait signifier que les coûts sont supérieurs au budget. Généralement mauvais. Un indicateur rouge sur une métrique de revenus pourrait signifier que les revenus sont au-dessus de l'objectif, ce qui est bon. La couleur doit être systématiquement alignée sur la direction de la déviation par rapport au résultat souhaité, et la direction souhaitée doit être contextuellement appropriée pour la métrique.
Choisir le bon type de graphique
La sélection du type de graphique est l'une des décisions les plus conséquentes dans le design de tableaux de bord, et elle est fréquemment prise sur la base de l'esthétique plutôt que de la structure des données. Voici les choix de graphiques que j'utilise dans les contextes de tableaux de bord financiers et pourquoi :
- Graphiques en ligne : Pour les données de séries temporelles continues où la tendance et le taux de changement comptent. Solde de portefeuille de prêts dans le temps, volume de transactions quotidien, mouvements des taux d'intérêt. N'utilisez pas de graphiques en barres pour les séries temporelles quand la ligne de tendance est le message.
- Graphiques en barres (groupées ou empilées) : Pour comparer des catégories discrètes ou des périodes. Comparer les revenus par ligne de produits, ou montrer ce mois vs le mois dernier vs le budget sur plusieurs métriques. Les barres empilées fonctionnent quand la relation partie-au-tout est significative ; les barres groupées quand la comparaison directe entre catégories est la priorité.
- Sparklines : Pour l'indication de statut plutôt que l'analyse. Un petit graphique en ligne à l'intérieur d'une carte KPI vous dit la tendance récente sans nécessiter un graphique complet. Pour les tableaux de bord avec beaucoup de cartes KPI, les sparklines ajoutent un contexte significatif pour un coût visuel minimal.
- Tableaux avec visualisation en ligne : Pour les données qui nécessitent de la précision. Quand les utilisateurs ont besoin de connaître les valeurs exactes et de comparer sur de nombreuses lignes, un tableau avec des graphiques en barres en ligne ou des cellules colorées est plus utile qu'un graphique. Les professionnels financiers ont souvent besoin des chiffres réels, pas juste de la forme des données.
- Nuages de points : À utiliser avec parcimonie et uniquement quand la corrélation entre deux variables est la véritable question posée. Pour l'analyse de risque de crédit ou l'analyse de portefeuille, les nuages de points sont puissants. Pour les tableaux de bord opérationnels, c'est généralement le mauvais choix.
Patterns d'affichage de données en temps réel
Les tableaux de bord financiers ont de plus en plus besoin d'afficher des données en temps réel ou quasi temps réel. Données de marché, volumes de traitement de paiements, comptages de sessions actives. Ces valeurs changent continuellement. Concevoir pour les données en temps réel introduit des défis UX spécifiques que les tableaux de bord statiques n'ont pas.
Le principe le plus important : n'animez pas chaque mise à jour de données. Si un nombre change chaque seconde, animer chaque changement crée du bruit visuel qui rend le tableau de bord épuisant à surveiller pendant de longues périodes. Ma règle est de n'animer un changement de valeur que quand son amplitude dépasse un seuil que vous définissez par métrique. Fixez ce seuil à partir de ce qu'est un mouvement normal pour cette métrique : un prix qui bouge chaque seconde a besoin d'une bande beaucoup plus large qu'un décompte d'approbations quotidiennes. Les petites fluctuations se mettent à jour silencieusement, les mouvements significatifs attirent l'attention par l'animation.
Les indicateurs de fraîcheur des données sont essentiels sur les tableaux de bord en temps réel. Les utilisateurs ont besoin de savoir si les données qu'ils regardent sont actuelles ou périmées. C'est particulièrement critique dans les contextes financiers où agir sur des données périmées peut avoir des conséquences monétaires. J'affiche un horodatage de dernière mise à jour en termes relatifs ('Mis à jour il y a 3 secondes') avec un horodatage absolu disponible au survol. Si le flux de données est retardé ou interrompu, j'affiche un avertissement de péremption visible plutôt que d'afficher silencieusement d'anciennes données.
// Staleness detection service
@Injectable({ providedIn: 'root' })
export class DataFreshnessService {
private readonly STALE_THRESHOLD_MS = 30_000; // 30 seconds
isStale(lastUpdated: Date | null): boolean {
if (!lastUpdated) return true;
return Date.now() - lastUpdated.getTime() > this.STALE_THRESHOLD_MS;
}
freshnessLabel(lastUpdated: Date | null): string {
if (!lastUpdated) return 'Data unavailable';
const secondsAgo = Math.floor((Date.now() - lastUpdated.getTime()) / 1000);
if (secondsAgo < 5) return 'Just now';
if (secondsAgo < 60) return `${secondsAgo} seconds ago`;
return `${Math.floor(secondsAgo / 60)} minutes ago`;
}
}Divulgation progressive pour les jeux de données complexes
La divulgation progressive est la pratique de montrer d'abord les informations résumées et de révéler les détails à la demande. Pour les tableaux de bord financiers, ce n'est pas juste une préférence de design. C'est une nécessité pour gérer la charge cognitive sur des écrans denses en données.
Ma hiérarchie de divulgation progressive pour les tableaux de bord financiers : le niveau un est le tableau de bord résumé montrant les KPI et les exceptions, le niveau deux est la vue détaillée de la métrique montrant la série temporelle complète, la décomposition par sous-catégorie et les données comparatives contextuelles, le niveau trois est le détail au niveau transaction ou enregistrement, accessible uniquement quand l'utilisateur a un besoin d'investigation spécifique.
La navigation entre ces niveaux doit être efficace. Cliquer sur une carte KPI devrait aller directement à la vue niveau deux pertinente pour cette métrique, pas à une page analytique générique. Cliquer sur un point de données anomal dans un graphique devrait faire remonter les enregistrements sous-jacents qui expliquent l'anomalie. Ces chemins de drill-down contextuels réduisent le temps d'investigation nécessaire à un utilisateur pour comprendre ce qui se passe, ce qui est la proposition de valeur centrale du tableau de bord.
L'expérience GFT : tableaux de bord en temps réel pour sociétés d'investissement
Chez GFT, j'ai construit des tableaux de bord de trading en temps réel pour des sociétés d'investissement avec Angular, D3.js et WebSockets, en gardant la latence des données sous une seconde. C'était un contexte particulièrement instructif parce que les traders et les analystes sont des utilisateurs sophistiqués avec des besoins d'information très spécifiques et très peu de patience pour la latence. Un tableau de bord conçu pour un utilisateur bancaire grand public est inadapté pour eux. La densité d'information doit être plus élevée, le temps d'accès à l'information clé doit être plus court, et les données doivent être visiblement à jour.
La leçon la plus précieuse dans ce contexte concernait la fraîcheur. Quand les données bougent chaque seconde, l'affichage doit rendre les données périmées impossibles à manquer : un flux qui s'arrête silencieusement de se mettre à jour est pire qu'un flux qui affiche une erreur, parce que quelqu'un agira sur le chiffre périmé. L'autre leçon était la retenue dans l'animation. Avec D3.js il est facile d'animer chaque tick, et le faire rend un écran impossible à regarder en quelques minutes.
Un tableau de bord qui montre tout n'est optimisé pour personne. Concevez pour la décision, pas pour les données.
Accessibilité dans la visualisation de données
Les tableaux de bord financiers ont un problème d'accessibilité spécifique à la visualisation de données : les graphiques sont intrinsèquement visuels, et leur signification est inaccessible aux utilisateurs de lecteurs d'écran qui ne reçoivent que le texte alternatif du graphique. C'est un vrai manque que la plupart des designers et développeurs de tableaux de bord n'adressent pas adéquatement.
Ma pratique actuelle : chaque graphique inclut une vue tabulaire des données accessible via un toggle, pour que les utilisateurs de lecteurs d'écran puissent accéder aux chiffres sous-jacents. Le texte alternatif du graphique n'est pas 'Graphique en barres montrant les données de revenus'. C'est un résumé concis de l'insight clé : 'Les revenus ont augmenté de 12 % d'un mois à l'autre, atteignant 4,2 M$ en juin, la valeur la plus élevée des 12 derniers mois.' Le texte alternatif raconte l'histoire que le graphique raconte, pas juste quel type de graphique c'est.
La couleur n'est jamais le seul indicateur de signification dans mes tableaux de bord financiers. Chaque statut qui utilise la couleur utilise aussi une icône ou un label texte. C'est à la fois une exigence d'accessibilité et une amélioration pratique d'utilisabilité. Les tableaux de bord sont fréquemment consultés sur des moniteurs mal calibrés, dans des environnements de bureau lumineux, ou par des utilisateurs ayant un déficit de vision des couleurs. Concevoir pour ces conditions bénéficie à tous les utilisateurs.
Références
- WCAG 2.1 non-text contrast. https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast
- Apache ECharts. https://echarts.apache.org/en/index.html
- Chart.js. https://www.chartjs.org/