5 astuces pour améliorer vos dashboards

Que l’on parle de Business Intelligence ou de Big data, la gestion et la compréhension de la donnée représentent le quotidien des entreprises. Si la maturité et l’usage des données ne sont pas les mêmes selon les secteurs, la data représente un support inévitable pour presque tous les sujets d’entreprises. A l’heure du digital, les possibilités et les champs d’études se multiplient, et le nombre d’indicateurs clés de performance possibles peut paraitre vertigineux. C’est d’autant plus vrai qu’un grand nombre d’outils de datavisualisation sont désormais disponibles. C’est ici que la dataviz prend tout sens avec entre autres, l’accessibilité et la lisibilité de la donnée. Cette accessibilité peut se comprendre de deux façons différentes, non seulement comment l’organiser en amont, mais également comment la rendre compréhensible pour le lecteur. Nous nous centrerons ici sur cette dernière partie en tentant de voir comment optimiser nos dashboards en 5 points fondamentaux.

I) Le suivi d’une méthodologie rigoureuse

A/ Utilité du tableau

La première étape consiste bien à ne pas tomber dans le piège de faire un dashboard pour faire un dashboard. Le tableau de bord est d’abord l’aboutissement d’un processus d’analyse, et n’est pas une fin en soi. Il répond à des problématiques déjà été abordées en amont. Elles peuvent concerner différents sujets :

• de production (suivi d’une activité commerciale…)
• de rétention
• de gestion de projet (suivi des délais, ressources ou du budget).

Ces points concernent notamment la mise à disposition de l’information. Ce que l’on veut observer, ce que l’on veut montrer, et ce que l’on veut représenter. Par conséquent, il convient de cadrer notre champ d’étude et notre périmètre avant de se lancer.

B/ Organisation préalable

Nous allons donc établir plusieurs étapes préalables à la construction du dashboard, l’objectif étant d’avoir une bonne base de travail et de dégager des axes de réflexion. Cette méthodologie est à prendre en compte, avant même de considérer les outils de datavisualisation. Nous devons d’abord qualifier le besoin (formuler les problématiques et les questions…) et la donnée ( définir les variables …). Nous pourrons en déduire les mesures à créer, faire un nettoyage, et faire une maquette écrite représentant notre tableau. Cette méthodologie, va poser les bases de notre travail et devrait laisser peu de place au doute.

C/ Un développement logique

Ensuite, il convient d’évoquer l’organisation et la composition de notre application. En premier lieu, rappelons que dans l’application que nous développons, chaque dashboard répond à un thème précis. Par conséquent, l’enchainement de nos tableaux doit bien être réfléchi. Ce suivi doit correspondre à une certaine logique, et à une pertinence. Si nous parlons bien ici de l’enchainement des problématiques et des thèmes, cette problématique s’opère sur un champ moins macroscopique.

En effet, la composition même du dashboard demande qu’on se penche sur la disposition. Une image a un sens de lecture, et certains détails attirent plus facilement l’œil que d’autres. Le développeur qui souhaite mettre en avant certaines données ou certains KPI a tout intérêt à prendre en compte le sens de la lecture de sa production visuelle.

II) La composition et l’esthétique

A/ Epurer le dashboard pour plus de lisibilité

« Il semblerait que la perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer » disait Antoine de Saint Exupéry. Cette phrase est extrêmement pertinente dans le domaine de la dataviz. La composition des visuels et des KPI est liée aux problématiques d’accessibilité de l’information, en particulier la lisibilité. Pour pallier ces problèmes, il convient de veiller à ne pas surcharger les dashboards et les productions. Il faut éviter de mettre trop de représentations graphiques dans notre dashboard et chercher à synthétiser. L’utilisation de « cartes », un calcul dont on affiche le résultat chiffré, est un excellent moyen d’apporter une vision claire et brève de la donnée.

B/ La synthèse avant tout

Toutefois, même pour nos représentations chiffrées de KPI, la parcimonie reste de mise. La data est au service de l’idée, pas l’inverse. L’étalage de chiffres et de graphiques risque de perdre l’utilisateur et de rendre la production illisibles. De plus, vous maitriserez probablement mieux la donnée que l’utilisateur futur, aussi un travail d’analyse préalable est indispensable. Le but étant de pouvoir identifier les variables les plus pertinentes à présenter. Nous rejoignons les étapes précédentes finalement, et préservons la cohérence et la pertinence des données.

III) La contextualisation

A/ Contextualisation

Notons que le concepteur ne sera pas le principal utilisateur du dashboard. Il doit penser aux parties prenantes du projet, mais également aux personnes qui peuvent arriver en cours de route. Dans un cas comme dans l’autre, l’utilisateur peut avoir besoin d’un rappel du cadre. C’est pour cette raison que nous nous retrouvons confronté à la nécessité de contextualisation.

B/ « signature graphique »

Il apparait essentiel d’apporter du contexte par le biais d’indices textuels voir graphiques. Là encore, la modération est de mise, et des titres explicites peuvent très bien suffire. Notons également que la création d’une documentation est indispensable. Elle permet à la fois d’offrir un soutien pour la maintenance, mais aide au développement de l’application. Par ailleurs, elle permet aux nouvelles parties prenantes de prendre plus rapidement connaissance du contexte et du développement. L’absence de documentation de référence peut également faire perdre du temps, dans la conception même du dashboard. En effet, les multiples aller-retours vers votre commanditaire peuvent coûter du temps et induire des incompréhension.

IV) La pertinence de la représentation

A/ L’intérêt et le respect des normes locales

Un point important pour renforcer cette notion de contexte est la pertinence de la représentation. Chaque graphique a un sens précis, et il convient d’éviter le plus possible les contresens. Le soin apporté à ce qui peut sembler être du détail est pourtant fondamental dans l’accessibilité de notre dashboard. Même le simple choix des couleurs revêt une certaine importance. Naturellement, l’utilisation des conventions sociales est préférable, mais il faut parfois pouvoir pousser plus loin. Prenons un exemple, dans la culture occidentale la couleur verte est associée à un résultat positif, quand la rouge est négative. La première observation que nous pouvons faire est que pour ne pas induire le lecteur en erreur, il convient de respecter ces « normes ». Cependant, nous pouvons observer un autre point, le fort contraste des deux couleurs. Les couleurs contrastées permettent de marquer une forte différence et permettent d’être accessibles à tous, dont les personnes malvoyantes.

B/ Le dashboard est un message

Finalement, nous en arrivons sur le point fondamental du dashboard. Il s’agit avant tout d’un exercice de communication. A ce titre, il nécessite qu’on identifie notre public, et qu’on sache s’adresser à lui. La conception d’un POC, mettra l’accent sur le savoir-faire, et sera une démonstration technique. A contrario, un dashboard dédié à des directeurs cherchera à avoir accès très rapidement à quelques KPI et graphiques précis. Il faut donc pouvoir adapter ses visuels, son contexte et le contenu de son message à son interlocuteur.

V) L’expérience client

A/ Le sens client

Ce souci de l’utilisateur final doit être le cœur de la phase de conception. Quand le périmètre et les thématiques ont été définis, l’enjeu est de se mettre à la place de l’autre. La question à se poser n’est pas tant comment représenter la donnée, mais comment elle va être perçue. Le premier écueil à esquiver est la notion du « bon sens ». Ce qui peut sembler évident ne l’est pas forcément, et il faut pouvoir accompagner l’utilisateur.

B/ Ergonomie

Notons que dans le cas de la dataviz, la notion de design implique deux problématiques. Le dashboard doit être aisé à manipuler pour son lecteur, et par conséquent que la donnée soit facilement compréhensible. Il faut que le lecteur puisse comprendre en un clin d’œil le tableau, et impliquant une certaine prévisibilité de l’information.

C/ Ne concevez pas seul

Enfin, le dernier conseil portera sur la relation avec les parties prenantes. Veillez à impliquer au maximum les parties prenantes pour communiquer avec elles. Il sera plus aisé de déterminer les impératifs, et le développeur aura une meilleure compréhension de la façon dont sera utilisée l’application. La détection des nuances sera plus aisée, et il pourra plus facilement se figurer les us et les coutumes de son environnement de travail. Il sera à même de prévoir les potentiels points qui risquent de porter à confusion, et traiter le problème avant qu’il ne soit présent.

Découvrez nos article :  « Responsables informatiques libérez vos tableaux de bord ! »