Comment concevoir des dashboards utiles

La plupart des dashboards dans la plupart des organisations sont lus une fois au lancement, mentionnés en stand-up la semaine d’après, puis discrètement ignorés pour le reste de leur existence. L’investissement a été réel (quelqu’un les a construits, l’équipe data a validé les chiffres, l’annonce de lancement est sortie), mais le dashboard n’a jamais franchi la frontière entre « intéressant » et « essentiel » pour les personnes qu’il était censé servir.

La raison est rarement l’outil de BI. C’est la conception du dashboard lui-même : trop de métriques, pas de décision claire que le dashboard soutient, des chiffres absolus sans rien à quoi les comparer, aucun signal sur la fraîcheur de la donnée, et un public pour lequel le dashboard n’a pas vraiment été pensé. Cet article porte sur la discipline de conception qui transforme un dashboard de la décoration en un outil de travail.

Il s’associe à l’article sur la stratégie data, qui se situe un niveau au-dessus et pose le « les décisions d’abord, les dashboards ensuite » ; ici, l’angle est l’artefact lui-même, écrit pour qu’une équipe puisse reconnaître les patterns qui rendent un dashboard utilisable et ceux qui tuent silencieusement ses chances.

La contrainte la plus utile dans la conception de dashboard, c’est de limiter chaque dashboard à une seule décision. La décision est nommée, le public est nommé, et chaque élément de la page soit soutient cette décision soit est retiré.

Quand un dashboard essaie de soutenir toutes les décisions possibles que l’équipe pourrait avoir à prendre, il finit par n’en soutenir aucune correctement. L’utilisateur ouvre la page, voit trente graphiques, cherche celui dont il a réellement besoin, abandonne, et revient à poser la question par e-mail. Les dashboards utiles sont courts. Ils ont un titre qui nomme la décision (pas le sujet), un petit nombre de graphiques qui parlent directement à cette décision, et une lecture évidente du « et donc » que l’utilisateur peut emporter en réunion sans interprétation supplémentaire.

Si le même public a besoin de plusieurs décisions, la réponse est plusieurs dashboards, chacun nommé par la décision qu’il soutient, pas un grand dashboard qui essaie d’être tous à la fois. Le coût d’« un dashboard de plus » est bien plus petit que le coût d’un dashboard auquel personne ne fait confiance pour donner une réponse propre.

La tentation au moment de concevoir un dashboard, c’est d’y inclure toutes les métriques auxquelles l’équipe a accès, sur la théorie que « plus, c’est mieux, l’utilisateur peut ignorer ce dont il n’a pas besoin ». Le résultat est l’inverse : l’utilisateur ne trouve pas ce dont il a besoin parce que trop d’autres choses se disputent son attention.

Un dashboard qui fonctionne tient généralement entre trois et sept métriques. Celles du haut sont les réponses titre à la décision que le dashboard soutient. Celles en dessous sont le contexte de soutien : les composantes, les ventilations, les indicateurs avancés qui expliquent le chiffre titre. Tout ce qui ne contribue pas à interpréter le chiffre titre est soit déplacé vers un autre dashboard soit retiré.

La discipline est brutale mais le bénéfice est réel. Un dashboard avec trois métriques honnêtement pertinentes est utilisé. Un dashboard avec vingt-cinq métriques tout-ce-que-l’équipe-a-pu-trouver est mis en favori et plus jamais ouvert.

Un seul chiffre sur un dashboard, sans contexte, ne dit presque rien au lecteur. « Chiffre d’affaires : 4,2 M ». Est-ce bon ? Mauvais ? En hausse par rapport au mois dernier ? Sur la trajectoire du trimestre ? L’utilisateur doit déjà connaître la réponse pour pouvoir lire le chiffre, ce qui veut dire que le dashboard renforce ce qu’il savait déjà au lieu de l’informer.

Chaque métrique devrait apparaître avec une comparaison. La comparaison peut être : contre la même période l’an dernier, contre la période précédente, contre un objectif, contre une prévision, contre une baseline. Quelle comparaison est la bonne dépend de la décision que le dashboard soutient, mais l’absence de toute comparaison est presque toujours une erreur de conception.

L’encodage visuel compte autant que la comparaison elle-même. Une petite sparkline à côté du chiffre titre montre la tendance. Une flèche avec le pourcentage de variation rend la direction évidente. Une ligne d’objectif sur le graphique montre si la métrique est sur la trajectoire. Aucun de ces éléments n’est décoratif ; c’est ce qui transforme un chiffre en une information.

Un dashboard qui ne dit pas quand la donnée a été mise à jour pour la dernière fois est un dashboard auquel l’utilisateur ne peut pas faire confiance. La question la plus utile après « que dit le chiffre » est « à quelle date », et un dashboard qui cache la réponse est un dashboard que l’utilisateur doit aller demander à l’équipe data chaque fois qu’il doit agir sur le chiffre.

Le signalement de la fraîcheur est petit mais impossible à manquer. Un horodatage en haut du dashboard, ou à côté de chaque métrique si les cadences de rafraîchissement diffèrent, avec un indicateur visuel (un point coloré, un badge « périmé ») quand la donnée n’a pas été rafraîchie dans la fenêtre attendue. Un dashboard qui devrait se rafraîchir toutes les heures mais qui ne s’est pas rafraîchi depuis huit heures est cassé ; un utilisateur qui ne peut pas dire s’il est cassé est invité à faire confiance à des chiffres qui peuvent être faux.

La même discipline s’applique aux mises en garde. Si la métrique exclut certains segments, si la définition sous-jacente a changé le mois dernier, si la donnée est provisoire jusqu’en fin de journée, cela doit être sur le dashboard, pas sur une page de wiki que personne ne lit.

L’erreur de conception la plus courante au niveau de l’artefact, c’est d’utiliser le même pattern de dashboard pour des publics direction et des publics opérationnels. Ils ont des métiers différents et ont besoin de formes différentes.

Les dashboards de direction répondent à la question « est-on sur la trajectoire » en un coup d’œil. Le public les lit en réunion ou sur un téléphone, entre deux autres réunions. La bonne forme est un petit nombre de métriques titre, chacune avec une comparaison et une tendance claires, et un « et donc » qui tient en une phrase. Le détail est disponible en clic, mais la page d’accueil est la réponse. La fréquence est quotidienne ou hebdomadaire, parfois mensuelle.

Les dashboards opérationnels répondent à la question « que dois-je faire aujourd’hui » pour un rôle précis. Le public les lit plusieurs fois par jour, souvent dans le cadre de son workflow. La bonne forme est moins de métriques titre et plus de filtres interactifs, de files d’attente, de drill-downs qui amènent l’utilisateur à l’action qu’il doit prendre. Le rafraîchissement temps réel ou quasi temps réel compte ici d’une manière qui ne compte pas pour les dashboards de direction.

Demander à un seul dashboard de faire les deux métiers produit quelque chose que la direction trouve trop détaillé et que l’opérationnel trouve trop haut niveau, et les deux cessent de l’utiliser. Deux dashboards, conçus pour deux publics avec deux métiers, est presque toujours la bonne réponse.

Quand un dashboard auparavant bien utilisé commence à être ignoré, quatre causes reviennent, et chacune a une correction précise.

La décision que le dashboard soutenait n’est plus la décision que l’équipe prend. La correction, c’est de retirer le dashboard, ou de le redessiner autour de la nouvelle décision. Un dashboard que personne n’utilise coûte de la maintenance et érode la confiance dans la couche de données ; le retirer délibérément est plus sain que de le laisser périmer.

La donnée a cessé d’être de confiance. Deux métriques avec le même nom affichent des chiffres différents ailleurs, ou un changement récent de définition n’a pas été communiqué. La correction est en amont du dashboard, du côté gouvernance et définitions du travail data.

Le dashboard a lentement accumulé des métriques jusqu’à devenir trop long. La correction est éditoriale : une revue périodique où chaque métrique doit se justifier, et celles qui ne le peuvent pas sont retirées. Les dashboards vieillissent mal sans élagage actif.

Le propriétaire a quitté l’organisation. Sans propriétaire nommé, le dashboard n’a pas d’avocat, personne pour enquêter quand une métrique semble fausse, personne pour le retirer proprement. La correction, c’est de nommer un nouveau propriétaire, ou de retirer le dashboard. Les dashboards orphelins deviennent lentement cassés sans que personne ne le remarque.

Un dashboard utile, ce n’est pas celui avec le plus de métriques ; c’est celui qui est conçu autour d’une seule décision, avec les bonnes métriques dans la bonne comparaison, avec la fraîcheur sur la page et un propriétaire attaché. Les dashboards qui survivent à leur premier trimestre sont ceux dont la conception a respecté le temps de l’utilisateur au point de filtrer ce qui comptait à partir de ce qui était disponible.

Le contexte plus large, dont la manière dont la conception de dashboard se relie à la stratégie data, à la propriété des sources et à la couche d’ingénierie en dessous, est rassemblé dans le cluster systèmes de données et performance. Et lorsque la question passe de « nous avons des dashboards que personne n’utilise » à « nous reconnaissons le pattern et il nous faut maintenant quelqu’un pour les redessiner autour des vraies décisions, avec les bonnes comparaisons et la bonne propriété », c’est exactement ce sur quoi mon accompagnement analyse de données et aide à la décision est centré.