Retour à l'accueilMéthodologies de recherche
Veille concurrentielle
La veille concurrentielle est quelque chose de facilement réalisable et de (quasiment) naturel en matière d’études préalables, mais il est important d’en définir les grandes lignes, car il peut s’avérer que c’est l’une des seules manières de dégager des lignes directrices dans certains projets où la cible et/ou l’existant ne sont pas définis.
Une première approche de la veille peut être sous forme d’un benchmark, il faut donc identifier les principales applications concurrentes et analyser comment leur moteur de recherche est réalisé. Les rassembler sous forme de “user flows” est une bonne pratique pour analyser l’ensemble d’un parcours de recherche (le site mobbin.design en recense un grand nombre.) L’analyse peut se faire selon quelques critères qu’on peut lister ici :
- Sa position dans l’arborescence
- Sa position dans l’interface
- Le type de contenu indexé
- Les facettes (filtres, catégories…)
Il s’agit donc de repérer quel est l’objectif de conversion, et comment celui-ci se traduit dans la recherche… (e-commerce, social…)
Avec ces différentes applications sélectionnées, nous pouvons ensuite réaliser des boards visuels à des fins purement créatives. Ceux-ci permettent de dégager des conventions ou des habitudes de design qui seront autant de points de repère tant pour les utilisateurs que pour nous.
Je conseille personnellement Milanote, un bel outil pour réaliser des boards visuels en ligne. Un bon complément à un board physique, et qui surtout permet d’agréger un maximum de ressources en ligne.
Observations
Pour pouvoir comprendre le schéma mental de nos utilisateurs, il faut d’abord les observer. Plusieurs manières s’offrent à nous. Mais dans le meilleur des mondes, nous devrions les observer d’une manière discrète, sans que notre présence les biaise dans leur utilisation (ghosting). Mais une telle façon de faire n’est possible que peu souvent, surtout pour une observation aussi précise que des résultats qualitatifs requièrent.
Le type d’observation va aussi dépendre de l’état d’avancement de notre projet. Si c’est une création, alors peut-être qu’une observation sur des plateformes semblables pourrait être un bon levier pour dégager des problématiques et des directions à prendre sur notre propre projet.
Si c’est une refonte de l’existant, alors celui-ci est idéal pour l’observation.
Deux manières d’observer, plus ou moins intrusive et efficace, s’offrent à nous :
l’observation via des outils digitaux, qui permettent des données visuelles et statistiques quantifiables rapidement.
Et l’observation in situ, qui permet des retours qualitatifs et des données plus poussées sur le parcours de recherche.
Observation digitale
- Appsee, UxCam
AppSee est un outil assez complet quand on recherche des analyses spécifiques aux applications mobiles. Une de leurs fonctionnalités s’appelle “User Recordings” et permet d’enregistrer des parcours utilisateurs en enregistrant également leurs taps. La fenêtre permet également de chronométrer leurs parcours, et à quels moments les actions sont effectuées.
AppSee permet une utilisation gratuite pour les petites équipes. Il propose également de nombreuses autres fonctionnalités comme du A/B Testing, que nous pourrions mettre en place pour le processus de recherche afin de tester plusieurs mises en forme.
- Heatmap
Si nous possédons déjà un existant, ou des maquettes haute-fidélité, alors réaliser une heatmap peut-être un bon moyen d’identifier les points clés de notre interface, et analyser le succès de certains composants.
Inapptics, Uxcam et beaucoup d’autres proposent un outil de heatmapping sur application mobile. Ces services produisent donc des analyses de taps de nos utilisateurs pour produire ensuite des cartes de chaleur identifiant les zones les plus touchées.
Ci-contre Inapptics.
Cette carte peut nous aider à prioriser certaines facettes/filtres, ou repositionner certains éléments en fonction de leur niveau de clic en identifiant lesquels sont privilégiés ou au contraire, délaissés.
Observation in situ
L’observation in situ ne sera possible que si nous disposons d’assez de matière existante pour observer l’utilisateur “dans la nature”. Si c’est le cas, tant mieux pour nous, si non, ce n’est pas si grave :
L’avantage d’un moteur de recherche est sa similitude entre différentes applications (surtout sur mobile), nous pouvons alors espérer pouvoir obtenir des résultats qualitatifs venant d’applications similaires à la nôtre.
Le but est donc de trouver ces applications, même objectif de conversion, contenus ou facettes similaires… Différents niveaux de proximité sont possibles, tout dépend de ce que nous espérons dégager comme résultats, ou ce qui pourrait nous différencier de l’application concurrente.
Existant ou pas, l’observation in situ possède des avantages indéniables, mais aussi des inconvénients :
- Des résultats plus sûrs. Des utilisateurs recherchant dans la vraie vie seront plus sujets à rencontrer des frustrations ( ou des avantages ) que dans un entretien dans un bureau.
- La quantité de résultats possibles nous serviront dans le processus d’idéation.
- Chronophage, surtout dans le cas d’une observation concentrée sur un module de recherche. Il est difficile de trouver des utilisateurs potentiels, selon la popularité de l’existant ou de l’application concurrente.
- Des variables extérieures peuvent interférer. Nous ne pouvons pas contrôler la météo.
Quelques points à retenir pour une bonne observation, selon l’Interaction Design Group :
- Comment utilisent-ils réellement notre moteur de recherche ? À l’inverse de nos suppositions de ce qu’ils devraient faire..
- Quelles routines ont-ils ? Observons-nous des utilisateurs experts ? Analysons si certains peuvent utiliser des “raccourcis” d’interfaces.
- Nous devons enregistrer même les petits détails et spécificités, car ils rendront l’analyse plus sensée.
- Soyons sûrs d’examiner le processus de recherche dans son ensemble, dans quel contexte est-il utilisé ?
- N’ayons pas peur d’être quantitatifs. Notons même les comportements que nous soupçonnons être répétés à l’avenir.
Entretiens
Guerilla
Si notre besoin est d’obtenir le plus de remontées possible dans un temps très court, alors rien ne nous empêche d’utiliser la méthode guerilla, où le but est d’aller le plus vite possible à la rencontre de l’utilisateur pour confronter nos idées à la réalité du terrain.
Prenez une demi-journée, un endroit prisé par notre typologie d’utilisateur, où il a du temps à perdre, par exemple un café… Enfin, posons-lui la bonne question pour savoir s’il répond au besoin de notre application. Si vous pensez faire une application de vente de sneakers alors un exemple de question serait “Pensez-vous acheter une nouvelle paire de sneakers dans un futur proche ?”
Vous l’aurez compris, en disant “la bonne question à poser”, il est sous-entendu d’aller droit au but, car le temps et le lieu ne nous permet d’obtenir des résultats détaillés.
N’hésitez pas à préparer les questions au préalable, surtout si c’est votre tout premier test utilisateur.
Lors du test, demandez à l’utilisateur de réfléchir à voix haute, c’est un bon moyen d’obtenir de la data qui n’est pas biaisée par notre intervention ou notre analyse.
Afin d’en savoir plus sur comment réaliser un bon guérilla test, je recommande l’article d’ux republic à ce sujet.
Entretiens utilisateurs
Assurément la méthodologie de recherche qui permet d’avoir la matière la plus fine sur l’expérience utilisateur.
Cette méthodologie sera sans doute celle dont les résultats seront les plus qualitatifs, car nous serons au plus près de l’utilisateur, ce qui permet de dégager les attentes, les craintes et les représentations. Mais elle demande une préparation précise en amont : définition des objectifs de recherche, rédaction du guide d’interview, dosage entre les questions ouvertes et semi-directives… Et une analyse également poussée ensuite : traiter les données des questions ouvertes peut s’avérer chronophage.
Avant le recrutement de nos cobayes, il est primordial de se poser ces questions :
- Représentent-ils notre utilisateur final ? Notre cible ? (Sociologiquement, économiquement, géographiquement, en terme de tranche d’âge…)
- Sont-ils neutres par rapport à notre marque, ou déjà engagés dans un rapport de fidélité ou au contraire d’hostilité ?
- Ont-ils une motivation à faire l’entretien ? (Rémunération, récompense, curiosité, expertise…)
- Sont-ils familiers au domaine d’expertise de notre application ? Dans le cas du moteur de recherche, ce sera sûrement le cas.
- Le panel est-il assez large ou étendu pour permettre l’inférence ? (extrapolation à un ensemble de population plus global)
Pour un entretien spécifique au moteur de recherche, nous pouvons imaginer des scénarios d’usages, par exemple :
- Des scénarios basés sur des User Stories réalisées aux préalables;
Le but sera ici d’analyser la pertinence de ces users stories et ensuite d’identifier les points clés sous forme d’une expérience map basée sur nos KPI, qu’ils soient purement mercantiles ou non.
- Ou encore selon des patterns de recherche propices à notre application, que nous verrons dans une prochaine section.
Le plus gros travail reste à venir; suivant que l’entretien sera semi-directif ou libre, suivant notre méthodologie de dialogue avec l’utilisateur, la donnée à traiter nécessitera un travail de retraitement plus ou moins difficile et conséquent.
Tri de cartes
Comment savoir quelles facettes prioriser par rapport à d’autres ? Quelles données des produits intéressent le plus nos utilisateurs ? Tant de questions qui peuvent rester sans réponses si on ne dispose pas de données quantitatives lors de la conception.
Un tri de cartes peut nous permettre de dégager des tendances, et surtout très rapidement.
Il est important dans un premier temps de faire l’inventaire de notre contenu à tester. C’est la partie clé de l’atelier car le résultat découlera de ce choix. Faisons l’inventaire de nos facettes, de nos types de contenus et de tout ce que nous souhaitons confronter à l’utilisateur pour qu’il fasse un choix.
Ensuite ils seront imprimés ou écrits sur de petits bouts de feuilles (post-its dans l’idéal) pour l’atelier.
L’atelier peut ensuite être mené de deux manières :
-
Nous proposons déjà les facettes, et les participant(e)s vont déplacer les cartes dans chaque catégorie, voire faire émerger la nécessité de sous-catégories, en échangeant au besoin entre eux en cas de doute ou de choix différents.
-
Nous ne proposons pas de facettes, et nous laissons les participants regrouper eux-mêmes les contenus entre eux, ce qui va faire émerger des facettes que nous devrons ensuite nommer.
Cet atelier peut se faire avec les utilisateurs “cibles”, mais aussi en interne dans l’équipe de conception, attention cependant aux biais potentiels à avoir l’expérience et la connaissance du produit.
Statistiques
Dans le cas d’une refonte ou d’une adaptation de la recherche d’une application, obtenir des statistiques poussées sur le moteur de recherche existant peut s’avérer être décisif dans les choix de conceptions.
Implémenter
- Google Analytics
On ne présente plus Google Analytics qui est devenu la référence en terme d’analyse marketing et d’audience de site internet. Nous n’allons pas faire un détail de toutes ses fonctionnalités, il faudrait plusieurs livres blancs pour cela. Nous allons plutôt nous concentrer sur ce qu’il peut détailler en terme d’analyses sur la recherche.
Analytics permet de retourner des données extrêmement précises de celle-ci, mais également des actions post-recherche (taux de transformation, chiffre d’affaires par mot clé, taux de rebond, nombre de pages vues après recherche… etc.).
Google a mis en place une version mobile d’Analytics sous la forme d’une SDK
- Content square
Content square est une solution UX qui permet de traquer tous les parcours utilisateurs, de gérer les zones de chaleur, les zones de toucher. Il est assez facile à prendre en main. Concernant les statistiques de recherche, il permet un retour de données beaucoup plus large et précise. Il permet, entre autres, de savoir quelles catégories sont cliquées, à quelle étape de la recherche, quels tris/filtres sont appliqués. Mais aussi s’il refait une recherche et le contenu de celle-ci.
Content Square permet aussi de retourner des données extrêmement précises sur la recherche mais également des actions post-recherche (taux de transformation, chiffre d’affaires par mot clé, taux de rebond, nombre de pages vues après recherche…etc)
Content Square est une solution assez chère, elle s’adressera donc plutôt à des grandes entreprises ou celles qui ont un besoin très élevé en remontée UX.
Interpréter
Aucun logiciel ne permet d’analyser les facteurs qui font qu’un utilisateur quitte une application.
Mais voici quelques exemples d’interprétations possibles des résultats que l’on trouve sur Analytics ou Content Square :
-
Nous pouvons donc dans un premier temps analyser les requêtes sans résultats, voir si cela est normal (faute d’orthographe, erreur relative à l’utilisateur). Sinon, cela permet d’adresser rapidement le problème.
-
Analyser la position moyenne du résultat choisi, plus la position est élevée, plus l’utilisateur a fait d’efforts pour trouver son résultat.
Mettre en place et recueillir des statistiques peut être assez complexe si le niveau de précision est exigeant. Mais la vraie complexité repose sur l’utilisation des chiffres. Il faut faire attention aux raccourcis et ne pas catégoriser trop vite certains comportements (même si, en bon ux designers que nous sommes, nous ne le faisons jamais !)
Quelques exemples choisis ;
-
Un taux de rebond élevé ne signifie pas forcément que le moteur de recherche ne marche pas correctement, cela peut juste montrer que notre prix est trop élevé par rapport à la concurrence.
-
Même chose pour la position moyenne du clic, des grandes gammes de produits impliquent une plus grande recherche de la part de l’utilisateur, ce qui n’est pas forcément une mauvaise chose.
Il ne faut pas sous-estimer la volonté des utilisateurs à fouiller sur plusieurs pages pour trouver un contenu spécifique, notamment en cas de recherche précise.
«J’ai déjà vu des personnes aller jusqu’à la page 100 pour trouver un livre spécifique!»
Patrice Albouy, Cultura
