Comment trouver et tirer le meilleur parti du parcours utilisateur non planifié

Les replis peuvent être définis comme un plan alternatif qui peut être utilisé, et dans le contexte des parcours des utilisateurs, ils constitueraient une voie alternative au comportement attendu ou prévu de l'utilisateur. Ainsi, lorsque nous pensons à nos sites et applications, nous les créons avec un plan particulier à l'esprit pour atteindre un objectif particulier en empruntant un itinéraire particulier et vivre une expérience particulière.

Si vous avez de l'expérience dans la création de produits, vous saurez que les utilisateurs ont tendance à faire des choses que vous n'aviez pas prévues, et ce n'est pas grave car nous ne pouvons pas comprendre tous leurs besoins et leurs intentions. C'est pourquoi les replis sont si précieux.

Au fil des ans, nous avons essayé et testé de nombreux outils chez Venture Harbor pour nous aider à obtenir de meilleures boucles de rétroaction. Nos produits ont des besoins qui nécessitent différents types d'outils pour révéler toutes sortes d'informations. Des cartes thermiques et des outils d'enregistrement des visiteurs (comme Hotjar et Fullstory) aux plateformes d'analyse comme Google Analytics et Amplitude.

Ces outils sont formidables et nous aident à accomplir beaucoup de choses, mais ils ne vont pas très loin. Nous devons maintenant obtenir des informations plus approfondies qui ne peuvent être obtenues qu'en mettant en œuvre des replis sur vos parcours utilisateur .

Pour commencer, nous devons réfléchir aux comportements ou itinéraires alternatifs que nos utilisateurs pourraient rencontrer et que nous n'avons pas vu venir. Voici trois solutions de repli courantes :

• Impasses
  Le parcours de l'utilisateur est arrivé à son terme et il n'y a pas d'étapes claires ou ultérieures. L'objectif serait d'offrir les prochaines étapes à l'utilisateur et de suivre ces choix.
• Zones grises
  L'utilisateur interagit avec votre site ou votre application, mais nous comprenons peu ou pas ce qui se passe, ou pourquoi il fait ce qu'il fait. L'objectif est de faire la lumière sur ces domaines pour savoir ce qui pourrait se passer.
• les erreurs
  L'utilisateur reçoit un message d'erreur qui ne donne pas suffisamment de contexte. Le but ici est d'offrir un contexte en interagissant avec l'utilisateur pour obtenir un retour de sa part.

Plongeons-nous dans quelques exemples de la nature dans lesquels les boucles de rétroaction sont absentes des solutions de repli populaires. Ensuite, je poursuivrai avec des idées sur la façon dont cette boucle de rétroaction pourrait ressembler et fonctionner dans ces replis.

Remarque : Pour information, il s'agit de maquettes basées sur des scénarios réels.

Transformer les impasses en mines d'or de rétroaction

Les impasses dans un flux d'utilisateurs sont courantes. Une façon de les découvrir consiste à analyser vos pages de sortie dans votre outil de suivi analytique, comme Google Analytics. Cela mettra en évidence les pages de sortie courantes sur votre site ou votre application et vous donnera un point de départ pour commencer à enquêter.

Maintenant, nous devons poser la question simple :

« Pourquoi les utilisateurs partent-ils à ces points ? »

Jetez un œil aux pages réelles sur lesquelles ces sorties se produisent et commencez à déterminer à quel moment du processus d'utilisation de votre application ou de votre site se trouve l'utilisateur lorsqu'il atteint cette impasse. Sont-ils juste au début, sont-ils à mi-parcours ou sont-ils sur le point d'atteindre un objectif particulier dans le voyage ? Ces considérations vous aideront à brosser un meilleur tableau de la situation de l'utilisateur et des raisons possibles.

Exemple : Impasses dans la recherche

Une impasse très courante est la recherche lorsque vous recherchez quelque chose et que la page "Aucun résultat" s'affiche. Les entreprises commencent à vraiment investir dans ces pages, et vous constaterez que vous verriez normalement une sorte de résultat, en particulier sur les sites de commerce électronique.

Lorsque nous recherchons quoi que ce soit, nous devrions au moins renvoyer une sorte de résultat. Lorsque nous n'avons pas de résultat réel à montrer, nous devons réfléchir de manière créative à la manière de capitaliser sur ces scénarios. Cela peut prendre la forme d' une question ou d'une action courante qui aurait pu être l'intention de la recherche de l'utilisateur en premier lieu.

Voici un exemple de recherche sans issue :

Dans ce cas, que pouvons-nous découvrir de l'utilisateur que nous ne connaissons pas déjà pour nous aider à améliorer son expérience et nous aider à apprendre ? Quelles questions pourrions-nous leur poser ? Que pourrions-nous fournir à l'utilisateur à ce stade, maintenant qu'il n'a pas trouvé ce qu'il recherche ?

Ce scénario particulier est intéressant, et j'ai pensé à quelques idées sur la façon d'obtenir des informations de l'utilisateur pour nous aider à améliorer notre application et leur fournir la prochaine étape.

Comme indiqué ci-dessous, nous commençons par dire à l'utilisateur que ce qu'il recherche n'est pas disponible maintenant, mais pourrait l'être à l'avenir. En retour, nous pouvons obtenir des retours sur ce qu'ils avaient espéré faire ou trouver à la place :

Nous pourrions ensuite fournir à l'utilisateur une étape suivante en lui proposant un filtre qui l'aidera à trouver une alternative et nous informera ensuite de la catégorie d'extension qu'il recherchait, que nous pourrions ensuite examiner et déterminer quelles catégories nous devrions investir Avec ces informations rassemblées par l'utilisateur, nous pouvons commencer à constituer une base de connaissances sur ce à quoi les utilisateurs peuvent s'attendre dans ces scénarios et commencer à suggérer des catégories et des suggestions plus intelligentes à l'utilisateur final à l'avenir. De cette façon, nous pouvons leur offrir une bien meilleure expérience utilisateur.

Exemple : impasses naturelles

Les impasses peuvent également se produire comme un ordre naturel de votre site ou de votre application. Il peut y avoir des scénarios dans lesquels les utilisateurs rencontrent une page qui manque de contenu et aucune étape supplémentaire car le système n'a pas eu le temps de traiter les données. Ou peut-être que les données n'ont pas encore été créées, comme illustré ci-dessous :

Alors maintenant, ce que nous voulons faire, c'est nous assurer de deux choses :

1. L'utilisateur doit comprendre pourquoi et ce qui se passe ;
2. Engagez l'utilisateur pendant qu'il attend les données.

Vous trouverez ci-dessous une alternative conviviale, précieuse et utile à la fois pour l'utilisateur et pour nous-mêmes. L'utilisateur se voit proposer des notifications à envoyer à son adresse e-mail — ainsi qu'un mois d'abonnement gratuit ! En retour, nous informons les utilisateurs quand revenir sur l'application : des utilisateurs satisfaits avec un mois gratuit et des données supplémentaires sur les utilisateurs eux-mêmes. C'est toujours mieux quand tout le monde gagne !

Au fil du temps, nous pouvons commencer à comprendre si la majorité des utilisateurs souhaitent ou non disposer de certaines fonctionnalités, et s'ils préfèrent commencer à les activer par défaut ou à les supprimer complètement. En outre, les informations issues des enquêtes peuvent nous aider à mieux comprendre les attentes des utilisateurs vis-à-vis de l'application et nous aider à la façonner pour répondre aux besoins des utilisateurs.

Lecture recommandée : Comment améliorer votre processus de conception avec des personas basés sur des données

Convertir les zones grises en informations

Ce que j'entends par "zones grises", ce sont des zones qui manquent de perspicacité et de clarté sur ce que les utilisateurs pourraient faire ou pourquoi les utilisateurs prennent des décisions particulières. Ce sont normalement des domaines qui ne sont pas hautement prioritaires pour le site/l'application, mais qui font partie du parcours de l'utilisateur clé. Plus nous disposons de données tout au long du parcours utilisateur, mieux nous pouvons comprendre le quoi, le pourquoi et le comment des actions des utilisateurs.

Exemple : Comprendre votre « autre »

Il est assez courant d'étiqueter quelque chose comme "autre" lorsqu'il n'y a pas de correspondance claire. Vous trouverez ci-dessous un exemple de ce type d'interface utilisateur, et au fur et à mesure que nous analysons ce scénario, il est clair que la seule idée que nous avons est que nous savons que l'utilisateur l'étiquette comme un "autre" type, et cela nous laisse peu de compréhension de ce qu'il est ou de ce qu'ils voulaient qu'il soit.

Bien sûr, nous pourrions enquêter un peu plus sur ce qui est étiqueté comme "autre" et trouver des lignes communes, mais nous ne saurions pas ce que l'utilisateur aurait pu vouloir en l'étiquetant ainsi.

Alors, comment pouvons-nous changer ce scénario pour qu'il ne soit qu'une autre réponse "autre" en quelque chose d'informatif et d'utile à la fois pour l'utilisateur et pour nous ? Une approche que je suggérerais est un peu plus complexe mais rendra l'expérience beaucoup plus engageante.

Nous voulons permettre aux utilisateurs de choisir leur option en cliquant sur l'option qu'ils savent vouloir ou en recherchant ce qu'ils pensent rechercher. Pourquoi est-ce utile ? Eh bien, en ce qui concerne les options de nommage, nous pouvons les nommer d'une manière assez différente par rapport à la façon dont l'utilisateur pourrait avoir à l'esprit . Mais si nous ne pouvons toujours pas offrir à l'utilisateur une réponse qu'il recherche, alors nous devrions commencer une conversation avec lui en lui montrant une question et une zone de texte, et lui demander ce qu'il recherche et pourquoi. (Peut-être ajouter également une ligne que nous ferons un suivi avec eux et trouverons une solution à leurs besoins.)

Au fur et à mesure que nous commençons à trouver des fils conducteurs dans les recherches et les réponses que nous obtenons, nous pouvons commencer à ajuster la recherche pour proposer à l'utilisateur l'option dont il a le plus probablement besoin, et nous pouvons également créer de nouvelles fonctionnalités à mesure que la demande augmente.

Exemple : Comprendre votre recherche instantanée

Une autre zone grise ci-dessous est un exemple de moi-même utilisant une recherche instantanée tout en recherchant des mots clés qui ne sont associés à rien de ce que j'ai dans mon compte.

Suite à cette expérience, je me suis posé les questions suivantes :

• Quelle est la conclusion de ce scénario ?
• Puis-je savoir à quel point ce scénario est courant ?
• Qu'est-ce que l'utilisateur essaie d'atteindre ?
• Comment pouvons-nous les aider à arriver là où ils veulent?

Ci-dessous se trouve la fenêtre de résultats "Aucun résultat" avec une boucle de rétroaction pour nous aider à connaître les besoins des utilisateurs. Les résultats de la recherche sont renseignés de manière à mieux comprendre les besoins des utilisateurs et à nous fournir au moins une certaine clarté sur ce qu'ils recherchent exactement avec l'option "rechercher dans".

Voici quelques façons d'engager vos utilisateurs :

• Proposez des actions communes sur votre site ou votre application pour que l'utilisateur crée le contenu qu'il recherche ;
• Offrez-leur la possibilité de recevoir une notification une fois que la chose qu'ils cherchaient devient disponible (c'est une bonne façon de ramener l'utilisateur à un stade ultérieur) ;
• Permettez-leur de donner des commentaires directs, car parfois parler à quelqu'un résoudra tout (et une conversation est la meilleure source de commentaires).

Nous pouvons apprendre et devenir plus intelligents avec les résultats que nous obtenons de cette boucle de rétroaction, tant que nous commençons à fournir des suggestions de catégories plus intelligentes à nos utilisateurs . Au fil du temps, des habitudes personnalisées peuvent être apprises pour les utilisateurs individuels et nous pouvons commencer à suggérer des options qui sont plus susceptibles de trouver un écho auprès de cet utilisateur en raison de leurs actions et recherches passées.

Faites de vos messages d'erreurs une force

Que nous choisissions de l'accepter ou non, des erreurs se produisent. Lorsqu'elles se produisent, nous devons en être informées, mais parfois nous pouvons traiter les erreurs de manière générique, ce qui ne nous aide pas, ni l'utilisateur.

Un exemple de ceci est lorsque l'utilisateur peut interagir avec votre site ou votre application où il enregistre une sorte de données sur votre système, mais pour une raison quelconque, la connexion est perdue et le processus échoue. Il y a peu de choses pour diagnostiquer ce qui se passe ou ce qui s'est passé, mais nous savons qu'il y a eu une erreur. La procédure standard consiste à informer l'utilisateur qu'une erreur s'est produite et éventuellement à réessayer.

Lorsque nous en savons peu sur le problème de notre côté, ou qu'il pourrait avoir été causé par une poignée de choses, c'est une excellente occasion d'obtenir des commentaires de l'utilisateur sur ce qui se passe. Je pense que c'est la solution de repli la plus simple à mettre en œuvre, mais celle que je vois le moins.

Un scénario typique serait lorsque quelque chose est automatiquement enregistré pendant que vous utilisez le site ou l'application. Il s'agit d'un scénario croissant, en particulier avec les connexions mobiles ; comprendre que votre site est utilisé par des utilisateurs en déplacement ou sur une connexion mobile est un excellent aperçu, et nous devrions essayer de rassembler ces informations autant que possible.

Ou vous pouvez le rendre encore plus simple pour l'utilisateur. Si vous avez déjà une idée de ce que peut être le problème et que vous souhaitez avoir une meilleure idée de la fréquence à laquelle cela est arrivé à l'utilisateur, proposez-lui des options tout en lui permettant de vous dire ce qu'il a vécu. Une fois que vous avez ces informations, vous pouvez alors commencer à investir votre temps dans d'éventuelles nouvelles fonctionnalités pour aider à résoudre ces problèmes et, espérons-le, ne pas avoir à afficher de message d'erreur du tout.

Il est important de se rappeler qu'une solution de secours ne doit pas nécessairement être une fonctionnalité permanente, mais elle peut être temporaire pour vous aider à déterminer ce qu'il faut demander ou ce qu'il faut construire ensuite. La collecte de données nécessite un peu d'investissement et de temps, mais celles-ci peuvent être considérées comme des tests exécutés dans des domaines de votre parcours utilisateur que vous n'avez jamais examinés auparavant, et ne feront qu'ajouter à la compréhension de vos utilisateurs et de leurs besoins.

Cela dit, les replis dans un monde idéal n'existeraient jamais. Si vous travaillez sur un tout nouveau projet ou retravaillez votre flux d'utilisateurs, lancez-vous le défi de créer un flux où un utilisateur ne rencontrerait jamais de tels scénarios. Considérez comment empêcher un utilisateur de rechercher quelque chose qui n'existe pas. Suivez et analysez tous les domaines de votre parcours utilisateur pour comprendre chacune de leurs étapes et formuler des façons où un message d'erreur ne s'afficherait jamais.

Lecture recommandée : A/B Testing For Mobile-First Experiences

Où les replis vous coûtent-ils ?

Les solutions de repli seront différentes selon votre produit, car vous poserez différentes questions et offrirez différentes options, mais elles joueront toutes un rôle précieux en vous exposant, ainsi que les utilisateurs, à de meilleures options et à une meilleure compréhension.

Et ensuite ?

Pourquoi ne pas prendre quelques heures pour examiner vos parcours utilisateur et documenter où se trouvent les zones grises, ainsi que rechercher les impasses et les messages d'erreur qui existent (encore) dans votre produit.

Voici quelques guides pour vous aider à démarrer :

• Impasses
  Commencez à explorer vos analyses et, si vous ne l'êtes pas déjà, installez-vous confortablement. Les pages de sortie sont normalement suivies par défaut et vous fourniront d'excellentes informations sur l'étape à laquelle vos utilisateurs quittent le site. Pensez à l'endroit où vos utilisateurs se trouveront dans leur parcours et considérez le type de besoins qu'ils pourraient avoir à ces moments-là.
• Zones grises
  Si vous ne l'avez pas déjà fait, tracez votre parcours utilisateur et commencez à mettre en évidence les domaines sur lesquels vous pourriez avoir des questions. Considérez les points sur lesquels vos utilisateurs prennent des décisions et réfléchissez aux options que vous leur offrez. Rappelez-vous l'option "Autre" et réfléchissez aux endroits où il pourrait y en avoir qui sont assez génériques. Commencez à suivre ces options pour voir à quelle fréquence elles sont choisies, puis commencez à explorer les moyens d'obtenir des commentaires des utilisateurs sur ce qu'ils veulent.
• les erreurs
  Vous pouvez rapidement déterminer où une erreur peut s'afficher sur votre application. Avec un site/une application qui enregistre, met à jour et fonctionne en temps réel, les erreurs sont peut-être un élément clé de votre système. Commencez par déterminer quelle zone est la plus utilisée, ce qui pourrait entraîner l'endroit où les erreurs sont les plus fréquentes. Investissez dans les messages d'erreur et commencez à recueillir des commentaires sur la raison pour laquelle ceux-ci sont affichés - à la fois de votre système mais aussi de l'utilisateur. Je recommanderais également de créer un message d'erreur par défaut avec une boucle de rétroaction qui serait utilisée sur le site pour toute nouvelle fonctionnalité afin que vous commenciez à apprendre de ces erreurs dès le premier jour.

Bonne construction de repli !