Quelle est la stratégie pour déterminer comment demander un examen ou des commentaires?
Il semble qu'il y ait un certain nombre de facteurs différents qui doivent être pris en compte lors de la demande d'entrée/interaction utilisateur qui ne présentent aucun avantage immédiat pour eux, ou s'ils sont considérés comme interrompant leur flux de travail.
Je peux penser à certains de ces facteurs, mais je suis curieux de savoir quelle combinaison fonctionne le mieux et si elle varie en fonction du type d'application ou du périphérique qu'ils utilisent:
- Interaction: qu'elle soit révélée sur une page ou sous forme de pop-up
- Calendrier: au début, au milieu ou à la fin d'une tâche
- Message: formulation en tant que demande ou suggestion
- Ton: poli, amusant ou neutre
- Design: simple et basique avec le contrôle des notes intégré, juste un texte de lien
Un autre contexte auquel je peux penser est le type d'application qu'ils utilisent (jeux ou travail), que ce soit une application Android ou iOS), qu'elle soit liée à une incitation (telle qu'une fonctionnalité déverrouiller), mais je ne sais pas s'il existe des directives standard sur la façon de combiner ces facteurs pour les différents contextes d'utilisation.
Lorsque nos vendeurs ont demandé un mécanisme de rétroaction dans notre application TV pour déterminer notre score net du promoteur, nous avons également suivi ce processus de réflexion. Nous avons identifié quelques objectifs:
- N'interrompez pas ce que l'utilisateur peut faire en ce moment.
- Rendre trivial de cliquer/ignorer pour les utilisateurs qui sont ennuyés.
- Soyez concis, court et poli.
- Ne produisez pas de "claquement de porte" en vous présentant trop tôt (nous avons décidé de le montrer au hasard, mais au plus une fois tous les 6 mois, et pas dans les 6 premiers mois d'utilisation, donc l'utilisateur a eu le temps de former un avis de notre application)
- Fournissez une valeur (indirecte, minimale) à l'utilisateur. Dans notre cas, c'était un champ de commentaire qui permettait des commentaires de forme libre, qui sont allés au support.
À titre d'exemples, nous ne montrons jamais cette fenêtre en plein écran (car il est probable que l'utilisateur regarde la télévision depuis le canapé), je pense que nous ne la montrons même pas si une fenêtre de télévision est ouverte et en cours de lecture. Il s'agit d'une fenêtre non modale, qui permet à toutes les autres fonctions de l'application de continuer sans interruption (par exemple, les enregistrements programmés). Et nous vérifions l'activité de l'utilisateur de la souris/du clavier, etc. et ne montrons cette fenêtre d'enquête que lorsque l'utilisateur est inactif depuis un certain temps, avec notre application au premier plan.
La fenêtre a à la fois des boutons OK/Annuler et une boîte de fermeture, de sorte que les gens peuvent simplement fermer ou appuyer sur le raccourci clavier pour se débarrasser de la fenêtre sans tracas, en gardant la gêne au minimum pour les personnes qu'elle agace encore.
L'avantage du champ de forme libre est que nous avons obtenu des réponses honnêtes des utilisateurs, par exemple où certaines affectations de canaux avaient changé ou des problèmes de réception se produisaient dans certains pays, ce que nous avons découvert plus tôt de cette façon, et avons réussi à résoudre pour la plupart des gens des semaines avant que nous ayons généralement pris connaissance de ces problèmes via les canaux habituels.
Sachez donc que l'effet par défaut de toutes les fenêtres d'enquête est de déranger l'utilisateur et de s'ingénier activement à cela. Si vous êtes sur le Web, vous ne pouvez pas nécessairement mesurer l'activité des utilisateurs, mais vous pouvez par exemple faites quelque chose de similaire en plaçant votre enquête à la fin de une opération plutôt qu'avant, et rendez-la facile à ignorer (par exemple en gardant la navigation et quelques informations utiles autour d'elle, afin que les utilisateurs puissent continuer leur travail sans interruption).
Une grande partie de votre puce dépend de la conception et de l'intention du site Web ou de l'application. Comme par exemple "interaction: révélée sur une page ou en pop-up". Cela dépend de la conception. Y a-t-il de la place pour un formulaire de commentaires ou une étiquette qui amènera les gens vers un formulaire de commentaires. Il en va de même pour le design.
Le message et le ton de la demande de commentaires dépendent de l'intention de votre site Web ou application. Peut-être qu'un ton nonchalant ou aéré pourrait fonctionner pour vos utilisateurs. Je pourrais voir ce travail dans un jeu ou dans une application de calendrier où les gens sont plus intimement impliqués dans l'application. En face de cela se trouvent par exemple des applications liées au gouvernement. Dans ces types d'applications, il est important de rester formel.
Le plus gros point est cependant le timing.
ici est un excellent article, datant de quelques jours seulement, sur le bon moment pour demander des commentaires.
L'indice de l'article n'est pas de demander des commentaires lorsque les gens ouvrent simplement l'application ou le site Web. Les gens ne doivent pas le savoir et ne peuvent pas encore juger. Cela pourrait entraîner une mauvaise critique ou des utilisateurs frustrés.
Ne demandez pas de commentaires lorsque l'utilisateur est au milieu de quelque chose, comme lorsqu'il compose un Tweet ou qu'il est en train de commander un produit sur votre boutique en ligne. Cela pourrait également entraîner une mauvaise critique.
Demander la rétroaction lorsque la tâche est terminée semble être la seule option qui reste, mais il y a plus à considérer. Lorsque les tâches sont petites, comme la rédaction de tweets, ne demandez pas de commentaires après le premier Tweet. Cela ne donnera guère aux gens le temps de se familiariser avec l'application. Demandez-leur après un nombre X de tweets. Lorsque la tâche est plus importante, comme commander quelque chose dans votre boutique en ligne, les gens ont déjà visité une bonne partie de votre site Web. Il est assez sûr de demander leur expérience.
Alors demandez des commentaires après qu'un certain jalon est atteint et demandez-le d'une manière qui convient à votre site Web ou à votre application.