Retour à l'accueilPatterns & Comportements
Peter Morville et Jeffrey Callender ont introduit la notion de “patterns” de recherche, qui sont des usages courants d’un moteur de recherche par certains types d’utilisateurs.
Certaines applications sont plus sujettes à certains types de patterns, principalement selon leur type de contenu, mais aussi par l’importance du moteur de recherche dans leur arborescence.
Identifier des comportements récurrents de nos utilisateurs nous permettront d’abord de mieux cerner leurs usages, mais aussi de définir l’importance de certains composants de recherche par rapport à d’autres.
En réalité, il est parfois compliqué de définir un pattern récurrent sur un échantillon restreint d’utilisateurs. Plus notre contenu est grand, plus les patterns seront hétérogènes et notre travail sera délicat. Mais le jeu en vaut la chandelle ! Et puis, il suffira de cinq entretiens pour définir des patterns récurrents. Et même si nous n’arrivions pas à dégager des tendances de patterns sur notre moteur de recherche, il est quand même intéressant de définir des comportements sous formes de patterns, afin d’avoir une vue globale de ce à quoi nos interfaces seront probablement soumises lors de la mise en production.
Quitter
L’utilisateur recherche, obtient ses résultats et quitte l’application.
Pourquoi l’utilisateur quitte-t’il la recherche ? A-t’il trouvé ce qu’il cherchait ou a-t’il abandonné ? Malheureusement, nous ne pouvons pas le savoir avec des outils d’analyses.
Nous pouvons cependant savoir si sa requête comportait des résultats. Si elle n’en a aucun, alors demandons-nous si nous pouvons résoudre ce problème la, comme Uber Eats le fait d’une manière.
Application Uber Eats (Android)
L’application UberEats permet d’éviter la requête sans résultats via l’autocomplete et la reconnaissance des fautes d’orthographe. L’application ne prend pas en compte les mots non-reconnus pour ne garder que les résultats des mots valides. Point d’amélioration cependant, Uber Eats ne permet pas à l’utilisateur de se rendre compte de sa faute. Un message “Vouliez-vous dire ‘Pitaya’ ?” aurait permit de justifier cette méthode.
Filtrer
L’utilisateur recherche, obtient ses résultats et les filtre.
Ce pattern est souvent visible lorsque la requête fait ressortir un nombre trop grand de résultats. L’utilisateur fait un pas en arrière.
Lorsqu’un dataset est trop large ou que des mots-clés ne seront pas assez précis pour filtrer les bons résultats, mettre les facettes le plus en amont possible de la requête peut s’avérer décisif pour l’utilisabilité de l’interface. Leboncoin en est l’exemple parfait.
À l’heure où je rédige ce livre blanc, Leboncoin contient plus de 26 millions d’annonces en ligne. Une simple requête serait trop large et renverrait trop de résultats possibles, qui ne seraient potentiellement pas dans ma catégorie de recherche.
Application Leboncoin (Android)
Que voyons-nous en premier ? La barre de recherche ? Il y a de fortes chances que ce soit plutôt le champ de choix de catégories.
Non seulement c’est l’élément le plus important dans la recherche sur LeBonCoin mais il permet un feedback rapide avec le nombre d’annonces qui se met à jour en fonction des facettes choisies. Se faisant, LeBonCoin évite le pattern “filtre” qui serait nuisible à l’expérience globale de la recherche sur son application.
Étendre
L’utilisateur recherche, obtient ses résultats et est invité par l’interface à faire un pas en arrière, par une catégorie globale, ou par l’utilisation de moins de mots-clés.
Ce pattern est le plus souvent visible lorsque les résultats sont rares ou trop précis, ou si l’on navigue par arborescence de facette. Ce pattern est plutôt visible sur desktop, sur des sites de références ou de recherche documentaire.
C’est pour cette raison que nous le voyons assez peu sur mobile.
Recommandations
L’utilisateur recherche, obtient ses résultats et ouvre un des premiers résultats
Ce pattern apparaît lorsqu’une interface met en valeur des résultats ou la pertinence par ordre croissant de pertinence.
Application Google Play Store (Android)
Le play store autocomplete directement des résultats d’application selon si le résultat est assez pertinent. En croisant des données telles que le match syntaxique et le nombre de téléchargements, de commentaires ou de notes, Google permet ici de raccourcir le parcours de recherche tout en proposant les bons résultats. Pour réussir ce pattern, il faut cependant des données suffisamment nombreuses et qualifiées, au risque de proposer des résultats non pertinents.
Pogosticking
L’utilisateur recherche, clique sur le premier résultat, revient aux résultats, ouvre le second résultat, revient à la liste de résultats, etc.
Le pogosticking, ou l’équivalent du baton sauteur en anglais, est le comportement le plus souvent remarqué dans les e-shops, ou les utilisateurs parcourent et ouvrent les résultats les uns après les autres pour obtenir plus d’informations sur les produits. Une des nombreuses raisons qui expliquent pourquoi nos utilisateurs ont ce comportement peut s’expliquer par le manque de datas visualisables directement depuis la liste, l’utilisateur doit donc ouvrir un résultat pour en savoir plus.
Ce comportement est plus problématique sur desktop que sur mobile, l’utilisateur étant plus enclin à parcourir différents résultats sur mobile. Mais aussi face au manque de place disponible et l’obligation de prioriser certains contenus par rapport à d’autres, là où le desktop peut se permettre de, par exemple, rendre les résultats de recherches actionnables ou customisables par l’utilisateur directement depuis la liste de résultats. Pour preuve, je n’ai pas trouvé d’exemples de résultats actionnables sur mobile !
Pearl Growing
L’utilisateur recherche, ouvre un résultat et clique sur un lien dans le résultat ou fait une nouvelle recherche avec un mot-clé présent dans le résultat.
Ce pattern appelle à l’exploration. L’utilisateur trouve un bon contenu, fouille dans celui-ci et dans ses metadatas pour affiner sa recherche principale ou simplement pour en connaître plus.
Les hashtags d’Instagram ou de Twitter se basent sur ce type de comportement.
Application Twitter (Android)
Ici l’utilisateur effectue une recherche sur un thème assez large, comme l’UX Design, sélectionne un tweet, et est redirigé via le hashtag #designthinking sur une recherche contenant ce mot-clé.
Le génie des hashtags est de permettre de catégoriser la publication au sein même de celle-ci. Les catégories ne sont plus des données rattachées au contenu, elles sont le contenu. Même si dans ce cadre précis, leur utilisation est motivée par le besoin de visibilité des utilisateurs.
Cueillette
L’utilisateur recherche, ouvre un résultat, étudie le contenu, revient à la recherche, reformule sa requête avec de la nouvelle information, ouvre un nouveau résultat, etc.
Ce style d’accès à l’information fait passer la requête d’un simple mot-clé à une information à part entière et de multiples résultats sont trouvés sur le temps de recherche.
Ce pattern n’est pas une conséquence de l’interface mais plutôt un modèle cognitique de recherche d’information.
Dans un article scientifique de 1989, Marcia Bates démontre l’incapacité de satisfaction du mode classique de recherche caractérisé par une requête.
Elle proposa un modèle dit de “berrypicking”, ou cueillette, qui reconnait la nature itérative et interactive du processus de recherche d’information.
Pour résumer, Bates décrit le mode classique de recherche qui est d’actualité en 1989. Aujourd’hui, le web a beaucoup changé et s’est adapté à cette nature itérative et interactive de la recherche. Le fait de pouvoir naviguer entre les hashtags sur Instagram ou de pouvoir contextualiser un article sur Wikipédia, d’être suggéré de nouvelles vidéos sur Youtube, tout cela se base sur le berrypicking. Ce modèle est encore plus d’actualité aujourd’hui.
Aujourd’hui nous parlons même d’Information Foregaging, “Butinage d’information”. Si vous pensez que ce ne sont que des termes fumeux de bibliothèques démontrant juste le principe de la paresse humaine…vous n’avez pas tord
Pour une application mobile, c’est un peu différent. En effet, l’utilisateur a déjà pris la peine d’installer notre application.
Soit il a un but précis derrière la tête, soit il est déjà moins enclin à la désinstaller au bout d’une demi-seconde. L’utilisateur a aussi moins de possibilité de s’en aller ou de faire une recherche ailleurs, il est cognitivement disponible. À nous de satisfaire son besoin de recherche d’information en :
- Donnant des feedback précis sur ce qu’ils trouveront, où ils se trouvent. L’autocomplete est le nombre de résultats pré-recherches sont deux moyens d’y parvenir.
- En les encourageant à revenir, via des alertes customisées ou des notifications.
N’oublions pas, les utilisateurs sont paresseux.
Autres
Voici quelques exemples de comportements plus observables sur desktop que sur mobile, mais qu’il est intéressant de connaitre :
Onglets
L’utilisateur recherche, ouvre un résultat dans un nouvel onglet, et répète cette action parfois plusieurs fois de suite. Il ferme ensuite les onglets où la recherche s’est avérée infructueuse.
On retrouve souvent ce pattern dans des typologies d’utilisateurs assez à l’aise avec le numérique. C’est une alternative au pattern de pogosticking, mais à la place de revenir à chaque fois sur la page recherche, l’utilisateur préfère ouvrir des onglets à la chaîne. Ce pattern est très peu visible sur mobile, où la notion d’onglets est relativement exclusive aux navigateurs.
Orientation
L’utilisateur émet une requête imprécise, ouvre un résultat et choisit un niveau d’arborescence plus en amont de la navigation.
Exemple de pattern d’orientation, si dans mon ordinateur je recherche un dossier que je ne trouve pas mais que je connais son contenu, je peux chercher un contenu précis et, grâce à l’arborescence spécifique, je peux retrouver son dossier parent. Ce pattern peut donc remplacer la navigation pour les utilisateurs.
