Comment et pourquoi utiliser les données d’usage dans son process de design
Julien Ravat est Product Designer chez FFYN. Il a fait ses armes au sein de différentes entreprises comme BePatient, AvailPro, Viadeo ou encore Publicis. Il aime se définir comme un “touche-à-tout” ou encore dire qu’il apprécie “mettre les mains dans le cambouis”, ce qui nous mène à cette interview où il explique comment utiliser les données d’usage pour décortiquer des problèmes.
Peux-tu te présenter brièvement et nous expliquer quel aspect de ton travail tu affectionnes le plus ?
Je suis Product Designer chez FFYN, une startup qui aide les professionnels du monde de la finance à communiquer de manière plus transparente. Avant ça, j’étais Head of Design and Product chez bepatient, une startup qui développe des solutions e-santé.
Ce que j’aime le plus dans mon travail, c’est de concevoir des systèmes et une expérience globale qui ne se résume pas à une succession d’écrans. Je passe beaucoup de temps à chercher où positionner une nouvelle feature, à quel moment de l’expérience fait-elle le plus sens, voire même à quelle étape de la vie du produit…
J’ai eu la chance dans mes dernières expériences professionnelles d’avoir un poste très large qui couvrait le design produit, mais aussi tout le management du produit et des KPI, voire le marketing. C’est ce côté multi-casquettes qui m’a permis d’envisager des features dans leur globalité.
Il y a quelque temps, tu me partageais le constat suivant - “les designers n’analysent pas assez les données d’usage”- peux-tu développer ton propos ?
Historiquement, les designers ont beaucoup travaillé sur les données quali recueillies lors de tests utilisateurs ou d’interviews. C’est une excellente démarche mais parfois je trouve qu’il est intéressant de comprendre ce qu’il se passe une fois que nous ne sommes plus là. C’est là que savoir interpréter des Analytics ou des résultats d’A/B test devient intéressant.
Les outils comme Matomo ou Google Analytics sont très configurables et permettent à n’importe qui de remonter des infos sur l’usage de son produit. Il est notamment intéressant de mesurer l’usage en configurant des « objectifs » liés à la visite d’une page, ou à la réalisation de plusieurs actions. Par exemple on va mesurer un objectif atteint si l’utilisateur a terminé un tunnel de paiement. Au delà du simple nombre d’objectifs atteint, on peut, grâce à ces outils, analyser le chemin de l’utilisateur et surtout savoir où ceux qui n’ont pas réalisé l’objectif se sont arrêtés. Cette précieuse information permet ensuite d’adapter les différentes étapes et d’optimiser la performance de son application.
En comparant ces parcours avec ceux imaginés dans une user journey, on peut valider ou améliorer la conception d’un écran ou d’un process : ajouter une étape manquante dans un tunnel de réservation ou, à l’inverse, supprimer un questionnaire superflu dans un onboarding.
Peux-tu nous donner un exemple concret ? Comment utilises-tu l’analyse de données d’usage dans ton process de design ?
Tout d’abord il faut distinguer 2 niveaux de données :
- La mesure de « masse » qui consiste à regarder l’usage au niveau des populations ou de segments d’utilisateurs (représentant certains personas par exemple)
- Le tracking individuel, plus controversé, qui consiste à identifier ce que fait chaque utilisateur individuellement
De mon expérience, le 1er est intéressant et le 2ème n’apporte souvent pas plus d’information, si ce n’est du bruit. Il est également important de respecter un certain fair-play avec vos utilisateurs.
La mesure de masse est utile à toutes les étapes de la conception d’une nouvelle fonctionnalité : lors de la phase initiale de recherche ou bien une fois la fonctionnalité lancée (dans la phase d’amélioration).
Sur l’un des produits sur lesquels j’ai travaillé, j’avais noté qu’une partie des sessions se terminaient en impasse après la visite d’une certaine page. La page en tant que telle n’était pas cruciale pour la « conversion », mais tout de même elle représentait une part importante des pages de sorties de l’application : les utilisateurs s’en allait après l’avoir visitée.
N’étant pas dans le chemin critique, il n’y avait pas de raison d’investir sur cette page. A partir de cette donnée nous avons, par acquis de conscience, fouillé ce que les utilisateurs y cherchaient. Au final il manquait un lien sur cette page pour rattraper le « tunnel de conversion », faisant immédiatement augmenter le volume.
Dans le cadre de l’amélioration continue, c’est un peu plus « simple ». Souvent, la conversion est mesurée et il suffit de regarder le tunnel pour comprendre où cela pêche. Reste que, parfois, c’est un peu caché. Il faut creuser plus profond, les données d’usages remontant des infos de « surface ». Au-delà des pages, il faut analyser les « actions » des utilisateurs pour comprendre ce qu’ils font réellement, quels boutons sont cliqués, quelles options sont sélectionnées.
La panacée étant de relier les objectifs et les actions des utilisateurs à leur persona. Il n’est pas rare d’être surpris de voir plusieurs personas utiliser la même fonctionnalité, parfois à des fins différentes.
La dernière utilisation des données d’usage, la plus puissante à mon sens c’est la mesure du “churn”, le ratio d’utilisateurs qui, semaine après semaine, arrête d’utiliser votre application.
Savoir mesurer cette donnée et l’interpréter permet d’avoir tout de suite plus de poids dans les discussions. C’est une donnée que j’ai souvent rencontrée au niveau « client », celui qui paye, mais rarement au niveau des utilisateurs (en B2B il est fréquent que ce ne soit pas la même personne). Si ce sont les utilisateurs qui apportent de la valeur à votre produit, savoir quand ils le quittent et ce qu’ils ont fait avant permet de mieux se préparer avant une série d’interviews sur le sujet.
Très clair. Comment couples-tu analyse des usages & recherche utilisateur ?
Savoir analyser les données d’usage, quantitatives par nature, est précieux au moment d’organiser des interviews. Savoir où se trouve le point de blocage va nous permettre de creuser avec l’utilisateur ce qui pose problème et mieux comprendre le contexte.
Ce sentiment d’avoir accès à une multitude de données, ça peut donner l’impression qu’on contrôle tout depuis sa tour d’ivoire. C’est faux ! Nombre de fois, ce que l’on observe dans les statistiques d’usage n’est pas le reflet de ce que l’on a imaginé.
Parfois, un simple wording un peu ambigu sur un tunnel de paiement mais que l’on a pas identifié comme problématique lors de test utilisateurs “pré-lancement” a un impact sur la conversion. Grâce aux données d’usage, on sait un peu plus où chercher et il est plus facile de trouver que ce wording en particulier pose problème.
J’essaie la plupart du temps de valider mes observations sur les données d’usage par des interviews utilisateur. L’erreur facile serait de se cantonner à l’Analytics et de ne pas aller voir ce qu’il se passe dans la vraie vie.
Ce sentiment d’avoir accès à une multitude de données, ça peut donner l’impression qu’on contrôle tout depuis sa tour d’ivoire. C’est faux ! Nombre de fois, ce que l’on observe dans les statistiques d’usage n’est pas le reflet de ce que l’on a imaginé. On peut donc partir des données d’usage pour confirmer ou infirmer une intuition, mais il faut ensuite aller sur le terrain pour interroger les vrais utilisateurs. Cependant, la tâche est simplifiée une fois que l’on a ces données en tête, on va pouvoir orienter l’interview sur un écran, une question de formulaire, pour mieux comprendre le contexte autour des données.
L’autre erreur à éviter, c’est de tirer trop tôt des conclusions à partir de données d’usage. Il n’est pas rare de devoir attendre 1 ou 2 mois pour avoir des mesures fiables. Bien entendu, cela dépend du trafic sur ton application, mais il est toujours préférable d’attendre un peu. Ma règle c’est de ne pas tirer de conclusion si l’on a moins de 30 occurrences (visites, tentative d’atteindre l’objectif, clic sur un bouton…). En dessous, j’estime que ce n’est pas encore représentatif et qu’il est un peu hâtif de prendre une décision en fonction. Ça évite aussi de passer sa journée après la mise en production le nez rivé sur son tableau de bord en attendant que quelque chose ne se passe !
Dernière petite « astuce » si l’on peut dire, c’est de ne pas hésiter à supprimer des « trackers » une fois que l’on en a plus besoin. Trop de données, c’est surtout de la pollution pour analyser réellement ce qu’il se passe et c’est plus respectueux de la vie privée des utilisateurs.
Aurais-tu quelques conseils pour commencer ?
La première étape est déjà d’installer un outil d’Analytics sur son produit.
Google Analytics est le plus connu, mais il en existe d’autres : Matomo (l’équivalent open-source) ou MixPanel (plus orienté sur l’étude du comportement et la communication).
Ensuite, ce que je recommande pour commencer c’est de regarder les parcours des utilisateurs, notamment l’enchaînement des pages entre elles. C’est souvent la première donnée à comprendre pour analyser ce que font les utilisateurs.
Ensuite, on peut aller plus loin pour mesurer des actions en particulier, clic sur un bouton, utilisation d’un moteur de recherche, etc. Il ne faut d’ailleurs pas hésiter à solliciter les développeurs pour enrichir les actions de “méta-donnée”, ils sont en général assez friands de ce genre de mesures qui leur permet de réaliser l’impact de ce qu’ils implémentent. Par exemple, sur FFYN, nous mesurons l’envoi de message avec pour ”meta-donnée” le nombre de destinataires du message. Cela nous permet de connaître facilement le nombre moyen de destinataires par message et si besoin, un jour, nous adapterons l’interface en fonction.
L’idéal pour avancer c’est d’y aller petit à petit, avec chaque nouvelle fonctionnalité et de se poser la question de ce que l’on veut mesurer pour pouvoir décréter que c’est un succès : est-ce que c’est le fait d’être arrivé au bout d’un tunnel d’achat ? De s’être reconnecté le lendemain ? Etc.
Pour bien déterminer un succès il faut anticiper ce que l’on veut mesurer.
Pour cela je vais par exemple essayer de découper la fonctionnalité en action et voir celles qui ont une signification pour déterminer que ça va dans la bonne direction.
Ce n’est pas toujours possible, mais c’est bien de mettre en place le tracking un peu avant d’avoir développé la fonctionnalité pour avoir une base de départ et mieux mesurer l’évolution.
Dans ce tableau, je note ce que j’appelle des “expériences” : sur chaque carte j’indique la feature, ce que je mesure, ce qui en ferait un succès et éventuellement ce qui me manque pour le mesurer.
Pour se fixer un objectif à atteindre, je ne suis pas trop fan de parler en valeur absolue (augmenter les visites de +X% par exemple). D’une part, je trouve que se donner un chiffre à atteindre est souvent arbitraire et d’autre part, on risque souvent de se surestimer. Je préfère plutôt fixer une tendance en tant qu’objectif. Si la feature emmène dans la bonne direction alors je considère que c’est un succès et qu’on peut accentuer l’effort.
Une fois l’objectif défini, je me sers d’un petit tableau Trello pour le suivi (qui peut s’avérer un peu compliqué, surtout si l’on mesure plusieurs chose en même temps). Dans ce tableau, je note ce que j’appelle des “expériences” : sur chaque carte j’indique la feature, ce que je mesure, ce qui en ferait un succès et éventuellement ce qui me manque pour le mesurer. Ensuite j’ajoute un commentaire régulièrement pour voir où l’on en est. Quand je suis à peu près sûr de la tendance, j’indique si la carte est ou non un succès (en la changeant de colonne ou via un label)
Dernier conseil pour démarrer : ne pas avoir peur d’Excel ! Ce n’est pas forcément l’outil préféré d’un designer, mais il reste très puissant pour calculer la performance d’une fonctionnalité ou d’un onboarding. Leur nom peut faire peur mais les tableaux croisés dynamiques ne sont pas si méchants !
A partir du nombre de visites par semaine depuis l’inscription et un tableau croisé dynamique, on est ainsi capable de tracer une courbe de rétention (la proportion d’utilisateur se connectant semaine après semaine). Cette courbe est par exemple très utile pour cibler les messages de relance pendant la période d’onboarding.
Super, merci pour tes tips ! Aurais-tu un dernier conseil pour la route ?
C’est probablement une formule éculée, mais le poste de designer est central dans une équipe Produit : c’est la voix de l’utilisateur. Tous les choix en terme de positionnement marketing, de business, de support client et de technologie auront un impact sur l’utilisateur. Il est donc important d’être curieux de tout, de ne pas rester cantonné au Design et de ne pas hésiter à challenger les choix d’autres départements.
