Dans le processus design, la data peut être utilisée à plusieurs moments : en phase de recherche, pour comprendre les problèmes utilisateurs, ou en phase de mesure, pour évaluer les performances de la solution mise en ligne.
Les designers ont à leur disposition plein d’outils pour aller creuser la data de leur produit : Google Analytics, Amplitude, MixPanel, Segment, Hotjar etc. côté analytics, mais également des outils de mesure ou recherche quantitative comme les questionnaires, le NPS etc.
La data est un outil puissant et indispensable, mais il est important de garder en tête qu’elle ne peut pas être le seul outil utilisé pour mesurer et comprendre les problèmes : elle est d’autant plus efficace qu’elle est utilisée en complément d’autres outils, notamment ceux donnant des informations qualitatives.
Un rappel sur l’importance de la data
Comme dit en introduction, la data est un outil puissant et indispensable, que n’importe quel·le designer doit ajouter à son arsenal.
Elle est indispensable pour comprendre ce qu’il se passe en globalité et détecter des problèmes
Bien calibrée, la data nous pointe efficacement ce qu’il se passe, par exemple :
- Le comportement des utilisateurs en temps réel : comment les utilisateurs interagissent réellement avec le produit
- Les points de friction : là où les utilisateurs rencontrent des difficultés.
- Les parcours multi-canaux : comment les parcours via différents canaux se croisent et influencent mutuellement l'expérience utilisateur.
Elle est indispensable pour mesurer le succès d’une solution
Même lorsque des tests utilisateurs ont été effectués dans le process design, le vrai succès d’une solution ne peut être mesuré qu’une fois la solution mise en ligne. Elle traduit la vérité de ce qui se passe en production, sans aucun biais. (Les tests utilisateurs, eux, restent par essence biaisés, l’utilisateur étant dans des conditions non naturelles pour lui).
Elle nous permet donc -entre autre- de :
- Mesurer l’impact des décisions de conception (changements, nouvelles fonctionnalités) en suivant certaines data sur une période prolongée
- Valider des hypothèses de conception : en s’assurant que les choix de conception répondent bien aux besoins réels des utilisateurs.
- Suivre les tendances et évolutions de marché : à plus large échelle, on peut observer les tendances émergentes dans le comportement des utilisateurs ou les attentes du marché.
Mais utiliser la data seule présente des limites
Elle ne nous donne pas toutes les informations.
La data est là pour nous dire “quoi” et non “pourquoi”.
Par exemple : les utilisateurs quittent le parcours à cette étape-là, mais pourquoi ? On a l’information que telle étape est la plus problèmatique, mais on ne connaît pas les raisons.
La data nous donne l’information quantitative et non qualitative. Pour découvrir ce fameux “pourquoi”, il faudra utiliser d’autres méthodes de recherche, qualitatives cette fois.
De plus, la data peut difficilement traduire ce qui manque aux utilisateurs : ce n’est pas toujours à travers les actions réelles des utilisateurs qu’on pourra comprendre leur comportement idéal, ce dont ils ont besoin en réalité.
Elle est plus difficile à maîtriser pour obtenir des informations fines et fiables
Avec la data, on peut segmenter les utilisateurs (cohortes, âges, historique, devices, sessions etc..), croiser les données, filtrer… Et ainsi obtenir des résultats très précis.
Mais cela nécessite d’avoir :
- d’une part une base de données bien qualifiée, qui a été créée et maintenue de manière robuste
- d’autre part des membres de l’équipe qui ont une bonne maturité sur la data.
Cette configuration n’est pas accessible à toutes les équipes.
Elle présente des limites méthodologiques :
Contrairement à une recherche utilisateur qualitative, qui peut être complètement exploratoire (on peut se lancer dedans sans vraiment savoir ce qu’on va y trouver), la data nous oblige à d’abord définir ce que l'on cherche avant de démarrer.
👉 Il faut savoir quelle(s) donnée(s) on recherche, sous quel angle et avec quelles autres données on va éventuellement les croiser. On peut y aller à tâtons, mais on peut moins tomber "par hasard" sur des informations.
Surtout, comme on l’a vu plus haut, on ne pourra jamais tomber sur des informations qui ne sont pas “prises en compte” par le produit tel qu’il existe (fonctionnalité manquante par exemple)
Enfin, il ne faut pas oublier que la data est, elle aussi, sujette à interprétation : en fonction de la manière dont on aborde les chiffres, et comment on les croise on peut en tirer des conclusions différentes.
Comment la compléter ?
Le designer a à sa disposition plein d’autres outils qualitatifs de recherche et de mesure pour compléter la data : tests modérés, entretiens utilisateurs, shadowings etc…
Idéalement, le quanti et le quali doivent être menés en parallèle, et en “aller-retours”. On peut par exemple commencer par une phase exploratoire de recherche, puis aller préciser avec la data ce qui ressort vraiment en nombre, puis refaire du qualitatif pour expliquer pourquoi.
👉 Il n'y a pas forcément un ordre consacré dans lequel faire les choses, mais il faut que les 2 se répondent, naviguer entre le “quoi” et le “pourquoi”.
Conclusion
👉 La data ne doit pas tout guider aveuglément (”data-driven”), mais fait partie de l’arsenal d’outils qu’a un product designer à sa disposition pour faire des choix informés. (”data-informed”)
👉 Dans tous les cas, maîtriser la data (analyse, recherche quantitative, mesure de succès…) fera partie des “super pouvoirs” des designers : plus les choix sont justifiés, plus ils sont judicieux. Et définir des metrics (quantitatifs donc) de succès reste la manière incontournable de valider le succès d’une fonctionnalité, ou son besoin d’itération.
