Des dashboards "actionables", sinon rien !

Toute première fois

Vous souvenez-vous de la toute première fois que vous avez conçu un tableau de bord ? Moi oui ! Je disposais d'un jeu de données et d'un outil permettant de créer toutes sortes de graphiques. Des possibilités immenses s'ouvraient à moi. Je créais donc mes premiers "bar charts" et "time charts" que je regroupais dans mon tout premier dashboard. Je ne peux pas montrer le résultat, mais pour vous donner une idée, ça ressemblait un peu à ça...

Mais qui a conçu un truc pareil ?

Le problème quand on conçoit son tout premier dashboard, c'est que l'on a tendance à focaliser sur les données disponibles et la manière dont on pourrait les combiner et les présenter. On en oublie donc le plus important : l'utilisateur final et ses besoins. Les conséquences ne se font pas attendre.

• Surcharge d'information : on ne sait plus où regarder !
• Manque de clarté : que signifie ce graphique exactement ?
• Manque de sens : que suis-je supposé faire de cette information ?

Conception participative

Pour tout travail de conception, le mieux est d'impliquer l'utilisateur final, d'organiser des ateliers pour bien comprendre les besoins, soumettre les premières ébauches, puis améliorer progressivement les propositions.

Cet exercice reste toutefois délicat car si les ateliers ne sont pas correctement menés, les participants risquent de tomber dans le même piège : focaliser sur les données disponibles au lieu de réfléchir à leurs besoins réels.

Dans un premier temps, mon conseil est donc d'oublier les données et d'essayer d'identifier les problèmes que l'on souhaite résoudre. Par exemple : "En tant que formateur à distance, j'ignore qui est réellement impliqué dans ses apprentissages et qui est en train de se désengager."

Dans un second temps, on pourra voir comment exploiter les données pour apporter des réponses concrètes aux questions posées.

De l'information à l'action

Proposer des dashboards qui présentent une information claire et utile est déjà une belle étape. Mais il ne faut pas s'arrêter là. Le but d'un dashboard n'est pas simplement d'informer. Il est d'agir pour remédier au problème que l'on a identifié. Tout dans la conception du dashboard devrait tendre vers ce but.

Dans l'exemple précédent, une solution pourrait être de présenter une page contenant les informations suivantes :

• Un titre explicite : "Elèves dont le niveau d'engagement est en baisse" ;
• Les données : liste des élèves concernés avec un taux d'engagement pour chacun ;
• Une explication des indicateurs : "Le taux d'engagement tient compte du temps passé sur la plateforme et de la participation aux exercices proposés." ;
• Des propositions d'action : "Vous devriez prendre contact avec ces élèves pour faire le point et essayer de les remotiver."

Du dashboard à l'assistant

A ce stade, notre dashboard est relativement clair et il incite bien à passer à l'action. Mais nous pourrions aller encore plus loin. Et si nous imaginions une application Web qui en plus de présenter les informations précédentes, se comporterait comme un véritable assistant face aux problèmes identifiés. Une telle application pourrait notamment :

• Envoyer une notification au formateur lorsqu'une baisse significative du niveau d'engagement est détectée chez certains apprenants ;
• Proposer des fonctions pour agir : envoi automatique d'un message d'encouragement dans un premier temps, envoi d'une demande de RDV avec le formateur dans un 2nd temps ;
• Proposer des fonctions pour suivre les actions engagées : par exemple la saisie d'un compte-rendu d'entretien avec les résolutions prises par l'élève.