Obtenir des connaissances centrées sur l'utilisateur : Comment les rétrospectives facilitent l'analyse des hypothèses

Une marque est une idée qui met en valeur le goût. Imagine une personne qui n’est pas un connaisseur en vin. Celle-ci goûte un vin moyen et quelqu’un lui dit qu’il s’agit de la bouteille la plus chère du marché. Est-ce que cela changerait le goût ? Eh bien, objectivement non, mais combien de choses sont vraiment objectives ? Surtout en ce qui concerne l’UX (expérience utilisateur) ?

Il est important de comprendre que les gens perçoivent ton produit à leur manière, indépendamment de ce que tu avais en tête lors de sa fabrication. Car personne n’a jamais essayé de créer un mauvais produit, c’est juste qu’il n’a généralement pas fait mouche auprès du groupe cible.

C’est pourquoi il est important d’utiliser la méthode de la rétrospective pour voir exactement pourquoi quelque chose a fonctionné ou n’a pas fonctionné. De cette façon, tu peux répéter les succès futurs et éviter de faire les mêmes erreurs (ou des erreurs similaires). Dans ce sens, tu apprendras ici comment utiliser les méthodes rétrospectives pour simplifier tes tests d’hypothèses à l’avenir.

Lorsque tu conçois un produit, tu dois penser à la CLV (Customer Lifetime Value) d’un client. En effet, à moins que tu ne sois dans un secteur comme la fabrication d’échiquiers, tu n’as pas affaire à un seul achat par client. Selon certains sondages, seuls 20 % de tes clients réguliers jusqu’à 80 % de tes gains.

Nous pouvons parler ici de retargeting et de fidélisation des clients, mais la vérité est qu’aucun de ces clients ne restera s’il n’a pas eu une expérience positive avec ta marque dans le passé.

D’autre part, les utilisateurs qui ont eu une expérience positive ont tendance à revenir et à faire des achats plus importants à chaque nouvelle interaction. Même si tu travailles dans le secteur SaaS, tes clients pourraient se sentir plus à l’aise s’ils passent à un tarif plus élevé ou s’ils optent pour un forfait avec une durée plus longue. Il est également important de mentionner que dans le cas de SaaS, un meilleur design UX signifie des taux d’attrition plus faibles.

L’une des principales raisons pour lesquelles les gens partagent du contenu sur les médias sociaux est de fournir un contenu précieux et amusant aux autres et d’obtenir ainsi une reconnaissance sociale. Ils sont plus susceptibles de le faire s’ils ont vécu une expérience positive, car dans ce cas, ils peuvent assumer leurs paroles.

Ils pourraient même faire plus que simplement partager. Tu pourrais même apporter ta contribution par le biais de l’UGC (User Generated Content).

Tu ne dois pas considérer l’UX comme allant de soi. Pour pouvoir vérifier si ton travail fonctionne, tu dois faire une rétrospective. Pour cela, tu peux demander :

• Qu’est-ce qui s’est mal passé (pour que nous puissions y remédier) ?
• Qu’est-ce qui s’est bien passé (pour que nous puissions le répéter la prochaine fois) ?

Pour poser les bonnes questions, il existe des méthodes/techniques rétrospectives.

La plupart des gens ont des difficultés à décrire précisément ce qu’ils vivent. Ils comprennent ce qu’ils ont vécu et peut-être même les conséquences de ce qui s’est passé, mais ils ont du mal à s’exprimer. C’est pourquoi il est important de leur donner un cadre, et tu peux le faire par exemple avec la Rétrospective 4L :

• Like Tout d’abord, tu dois demander aux participants (soit des participants à l’enquête, soit des membres de ton équipe agile) ce qui leur a plu dans le produit, le processus ou la situation. Ces aspects positifs peuvent finalement devenir tes arguments de vente les plus forts, peut-être même des USP.
• Laqué : Demandez ensuite aux utilisateurs ce qu’ils n’ont pas aimé. Cela peut être un peu plus difficile, surtout si vous ne voulez pas offenser quelqu’un. Une façon d’encourager la liberté d’expression est de poser cette question directement. Bien que les gens ne soient peut-être pas disposés à parler de ce qu’ils “détestent”, ils peuvent se sentir libres de partager leurs pensées si on le leur demande.
• Longed for : Ici, il faut demander aux participants ce qu’ils souhaiteraient s’ils ne pouvaient souhaiter qu’une seule caractéristique de manière magique. C’est une excellente façon d’obtenir un aperçu inestimable, car leur manque de compréhension du processus de développement ne limite pas leur créativité.
• Appris : Enfin, tu peux leur demander ce qu’ils ont appris en utilisant le produit. Cela est particulièrement utile s’ils ont déjà utilisé des produits similaires. Combien de temps leur a-t-il fallu pour s’habituer aux nouvelles fonctions ? Ont-ils trouvé l’interface utilisateur difficile à comprendre, etc.

Un attrait pour le public est le but ultime d’un produit, et c’est une façon de l’étudier.

Lorsque tu réalises une enquête, une recherche, un test ou une expérience, tu as généralement une idée du résultat en tête. Ce résultat attendu est appelé hypothèse. Une hypothèse peut être vraie ou fausse, mais tu ne peux le savoir qu’après l’avoir testée.

La formulation d’une hypothèse est importante parce qu’elle peut t’aider à déterminer si l’expérience a réussi ou non. Dans la pratique, cela ressemblerait à ceci : Notre chiffre d’affaires augmenterait de X si nous :

• changer le prix
• changer l’UX
• ajouter une valeur/fonction supplémentaire au produit

Ce que les Hypothèse UX Cependant, il se peut que tu doives suivre une autre structure. Il existe différentes formes que peut prendre une hypothèse UX :

• Témoignage
• Supposition
• Variables
• Résultat attendu
• Méthodologie
• Critères de réussite

Un autre point important est que tu dois avoir des critères de réussite qui sont généralement quantifiables.

Imaginons par exemple qu’un changement de police de caractères sur ta plateforme fasse baisser le taux d’attrition moyen. Ensuite, nous faisons le changement et nous avons un taux d’attrition plus bas, mais seulement deux abonnés de moins (sur plusieurs milliers). Bien sûr, la théorie est vraie, mais la différence est-elle suffisamment pertinente pour être prise en compte ?

Le plus important est que tu ne poses pas cette question après l’examen. Cette question doit être résolue à l’avance. Tu as toujours le droit de considérer la perte d’un seul participant comme une grande différence, mais cela doit être déterminé avant le test.

Tu dois aussi établir une méthodologie claire et juste. Tu serais surpris de voir à quel point il est facile de faire des changements pour soutenir ta théorie.

Le plus important, c’est que la prise de conscience de ce qui ne va pas n’a aucune valeur dans le vide. Ces prises de conscience que tu as un problème exigent toujours que tu y travailles aussi.

La première étape consiste à appliquer correctement vos méthodes rétrospectives. Vous devez poser les bonnes questions. Des questions comme - Avez-vous aimé notre produit ? Cette question est acceptable comme question d’introduction. Cependant, elle n’a presque aucune valeur pratique. S’ils ne l’ont pas aimé, vos plaintes concernant les ventes, le service clientèle et le support technique le feront ressortir plus clairement que n’importe quelle enquête. S’ils ne l’ont pas aimé, vous le saurez.

Il en va de même pour l’inverse.

Tu veux savoir ce qu’ils n’ont pas aimé ou pourquoi ils n’ont pas aimé. Ce sont des particularités qu’il faut aller chercher au fond. Tu dois poser des questions à partir desquelles tu peux tirer des informations exploitables. C’est aussi simple que ça.

Il est également important que les données historiques soient importantes, même longtemps après que le problème ait été résolu. Tu veux voir si certains problèmes se répètent au moins sous différentes formes et formats. Si c’est le cas, soit tu as une mauvaise approche du développement, soit ta méthodologie est défectueuse.

L’une des choses les plus importantes est que tu entretiennes une communication ouverte. Tu poses une question au client (méthodologie rétrospective), tu obtiens la réponse et tu travailles dessus. Ensuite, tu corriges le problème et l’annonce dans une grande annonce ou dans les notes de patch. Ensuite, tu demandes un nouveau feedback. Ce processus sera Continue de manière continueAu moins aussi longtemps que tu soutiens le produit.

Pour finir, nous aimerions donner quelques conseils qui pourraient t’être utiles pour obtenir des connaissances axées sur l’utilisateur.

Tout d’abord, tu dois comprendre ton public cible. Le plus gros problème que rencontrent beaucoup de managers, de propriétaires d’entreprise ou même de développeurs, c’est de penser qu’ils sont leur public cible. Mais ce n’est pas forcément le cas. Une fois que tu as accepté cela, tu as fait le premier pas pour comprendre à qui tu as affaire.

Deuxièmement, il faut trouver le bon groupe cible. L’échantillon doit être représentatif si les utilisateurs appartiennent à des groupes démographiques différents et si le nombre de participants à l’enquête est limité. Un mauvais échantillon est l’une des pires erreurs que l’on puisse commettre dans les études statistiques.

Le plus important, c’est que toutes tes recherches doivent être contextuelles. Tu veux voir comment cela fonctionne dans un environnement réel, pas dans le vide ou sur le papier.

La rétrospective de son propre travail est une expérience édifiante et une occasion d’apprendre.

Une fois que ton produit est sur le marché, il a sa propre vie et tu n’as plus rien à y faire jusqu’à la prochaine phase d’amélioration. C’est pourquoi il faut collecter toutes les informations et demander de manière proactive ce que le groupe cible en pense. Construire une hypothèse, comprendre les techniques rétrospectives et affiner les connaissances sont quelques-unes des façons d’aborder ce sujet.

Srdjan Gombar (auteur bio) :
Auteur de contenu expérimenté, auteur publié et boxeur amateur. Srdjan est titulaire d’un Bachelor of Arts en langue et littérature anglaises et se passionne pour la technologie, la culture pop et l’amélioration de soi. Pendant son temps libre, il lit, regarde des films et joue à Super Mario Bros. avec son fils.