Les quatre signaux de frustration et ce que chacun signifie

Que sont les signaux de frustration en UX ?

Le terme signaux de frustration couvre les comportements détectés automatiquement qui montrent qu'un utilisateur a rencontré une friction, et l'ensemble standard se compose des rage clicks (plusieurs clics rapides au même endroit), des dead clicks (un clic qui ne produit aucune réponse), des error clicks (un clic suivi d'une erreur JavaScript) et des thrashed cursors (un pointeur qui va et vient sans clic), chacun défini par un seuil et non par une supposition. Un détecteur lit le flux d'événements qui sort de la page, applique une règle contenant des chiffres et marque la session quand la règle correspond. Personne ne pose ces étiquettes à la main. C'est tout l'intérêt. Une règle peut parcourir cent mille sessions en une nuit, un chercheur non.

Le mot signal fait un vrai travail ici. Un signal n'est pas un diagnostic. Il marque une ou deux secondes pendant lesquelles l'utilisateur et l'interface n'étaient pas d'accord sur ce qui devait se passer ensuite, et il vous donne un horodatage. Comprendre ce qui a réellement cassé reste votre travail.

Quels sont les quatre signaux standard ?

Quatre comportements forment l'ensemble livré par la plupart des outils de replay, et ils couvrent des modes de défaillance différents. Les rage clicks attrapent un contrôle qui ne répond pas. Les dead clicks attrapent un élément qui a l'air cliquable et ne l'est pas. Les error clicks attrapent une action qui a levé une exception JavaScript. Les thrashed cursors attrapent un utilisateur qui ne trouve pas ce pour quoi il est venu.

Signal	Ce que l'utilisateur a fait	Ce que cela indique	Quoi vérifier en premier
Rage click	A cliqué plusieurs fois de suite, vite, au même endroit	Un contrôle qui a répondu trop lentement ou pas du tout	Le temps entre le clic et le premier changement visible sur cet élément
Dead click	A cliqué une seule fois sur un élément qui n'a produit aucune réponse	Du texte non interactif, une icône sans handler, un état désactivé sans explication	Si l'élément a un handler de clic et s'il ressemble à un bouton
Error click	A cliqué, et une erreur JavaScript s'est déclenchée juste après	Un handler cassé, une requête échouée, une référence nulle dans le chemin du clic	La stack trace et l'appel réseau attachés à ce clic
Thrashed cursor	A déplacé le pointeur d'avant en arrière rapidement sans cliquer	Une recherche de contrôle absent, mal libellé ou sous la ligne de flottaison	Si la cible de cette section de page est visible à cette largeur de viewport

Lisez la troisième colonne de haut en bas et vous voyez pourquoi les quatre existent en tant qu'ensemble. Ce sont quatre types distincts de friction utilisateur, et les fondre dans un seul chiffre de "frustration" jette la partie qui vous dit où chercher.

Comment un détecteur décide-t-il que quelque chose est un rage click ?

Toute règle de rage click est construite à partir de trois chiffres : combien de clics, dans quel rayon, dans quelle fenêtre de temps. Une série de clics qui franchit les trois d'un coup est marquée. Disons que votre outil est configuré pour trois clics dans un rayon de vingt pixels en une seconde. Quatre clics sur le même bouton en 700 millisecondes correspondent. Quatre clics étalés sur cinq secondes non, parce que la fenêtre s'est refermée. Deux clics où que ce soit non, parce que le compte n'a jamais été atteint.

Les trois autres signaux utilisent le même type de règle avec des entrées différentes. Un détecteur de dead click guette un clic suivi d'aucun changement du DOM, d'aucune navigation et d'aucune requête réseau avant l'expiration d'une fenêtre d'attente. Un détecteur d'error click relie un clic à toute erreur JavaScript levée dans une courte fenêtre après lui. Un détecteur de thrashed cursor mesure la distance parcourue par le pointeur et les changements de direction sur une fenêtre sans clic.

Ces seuils sont-ils les mêmes dans tous les outils ?

Non. Il n'existe aucun organisme de normalisation pour cela, et chaque éditeur choisit son propre compte, son propre rayon et sa propre fenêtre, puis les livre comme valeurs par défaut que vous pouvez parfois modifier. Les trois clics en une seconde d'un outil sont les quatre clics en deux secondes d'un autre.

Deux conséquences en découlent. Les comptes de rage clicks ne se transfèrent pas d'un outil à l'autre, donc une migration peut faire bouger le chiffre sans qu'une seule chose change dans votre interface. Et un benchmark lu dans le billet de blog de quelqu'un d'autre mesure ses seuils, pas les vôtres. Ouvrez les réglages de votre outil, notez les valeurs réelles et placez-les à côté de chaque chiffre que vous rapportez.

Pourquoi deux rage clicks identiques demandent-ils des correctifs différents ?

Parce que le détecteur ne voit pas l'intention, seulement les clics. Un utilisateur qui martèle un bouton Enregistrer qui met quatre secondes à répondre et un utilisateur qui martèle un div jamais relié à quoi que ce soit produisent le même motif d'événements. Même compte, même rayon, même fenêtre, même étiquette sur la session.

Les correctifs n'ont rien en commun. Le bouton lent a besoin d'un état optimiste, d'un spinner ou d'un endpoint plus rapide, et le handler de clic fonctionne déjà. L'élément mort a besoin d'un handler, ou il doit cesser de ressembler à un bouton. Livrez le spinner de chargement dans le second cas et vous avez rendu un contrôle cassé occupé en apparence.

C'est la limite honnête de tout signal de frustration, et c'est pourquoi le compte seul est presque inutile. Un taux passé de 2 pour cent à 5 pour cent vous dit que quelque chose a changé. Il ne vous dit pas quoi, et il ne le dira pas tant que personne n'aura regardé une des sessions.

Comment classer les signaux par impact ?

Classez par la part des sessions touchées, pas par le compte brut de signaux, parce qu'un seul utilisateur furieux qui clique quarante fois peut peser plus lourd qu'un problème qui touche discrètement mille personnes.

taux de frustration = sessions avec au moins un signal / sessions totales

Prenez une semaine avec 8,300 sessions dont 412 contenaient au moins un signal. Cela fait 412 / 8,300 = 0.0496, un taux de frustration de 4.96 pour cent. Puis découpez le même calcul par élément. Si 280 de ces 412 sessions se sont toutes déclenchées sur un seul bouton de checkout, cet unique élément représente à lui seul 3.37 pour cent de toutes les sessions, et les 132 sessions restantes sont dispersées sur le reste du site. Vous savez maintenant quel correctif planifier en premier.

Groupez avant de compter. Quarante rage clicks d'une seule personne sur un seul bouton font un bug, pas quarante, et un classement qui les traite comme quarante vous enverra chasser l'utilisateur le plus bruyant au lieu du problème le plus large.

Une semaine, 8 300 sessions

Sessions totales 8 300

Sessions avec un signal 412

Bouton de paiement 280

Reste du site 132

Qu'est-ce qui rend un signal de frustration vraiment utile ?

Un signal est utile quand vous pouvez cliquer dessus et atterrir à la seconde exacte où il s'est déclenché. C'est toute la boucle. La règle trouve le moment, l'enregistrement montre la cause, et la cause vous dit quoi changer.

Sans ce saut, vous avez un graphique qui dit que les utilisateurs sont mécontents quelque part. Avec lui, vous regardez le bouton de checkout mettre quatre secondes, vous voyez le troisième clic arriver avant la première réponse, et vous savez que le correctif est un état désactivé pendant la requête. Flowsery détecte les rage clicks, les dead clicks, les erreurs JavaScript et les abandons automatiquement, regroupe les sessions correspondantes en un seul problème et classe les problèmes selon le nombre d'utilisateurs touchés, si bien que le signal arrive déjà attaché à l'enregistrement que vous devez regarder.

Questions fréquentes

Existe-t-il une liste officielle des signaux de frustration ?

Aucun organisme de normalisation ne définit l'ensemble. Les rage clicks, dead clicks, error clicks et thrashed cursors sont les quatre sur lesquels la plupart des produits de session replay ont convergé, traitez-les donc comme une convention plutôt que comme une spécification. Certains outils ajoutent les leurs, comme les soumissions répétées de formulaire ou les allers-retours entre deux pages.

Quelle est la différence entre un rage click et un dead click ?

Un rage click, ce sont plusieurs clics rapides dans la même petite zone, ce qui veut dire que l'utilisateur a réessayé parce que rien ne s'est passé. Un dead click est un clic unique qui n'a produit aucune réponse. Le même élément cassé peut générer les deux, selon que l'utilisateur a abandonné après un essai ou a continué.

Un signal de frustration peut-il être un faux positif ?

Oui, et c'est la principale chose à anticiper. Un rage click sur un bouton lent mais fonctionnel est identique à un rage click sur un élément vraiment mort, et un double-clic par habitude dans une application de bureau qui se comporte comme un site web déclenche la même règle. L'étiquette vous dit où chercher, pas ce qui ne va pas.

Les signaux de frustration fonctionnent-ils sur mobile ?

Les rage clicks, dead clicks et error clicks se traduisent directement en taps, puisque la règle sous-jacente porte sur le compte, la distance et le timing. Les thrashed cursors non, parce que les appareils tactiles n'ont pas de pointeur en survol à suivre. Sur mobile, les outils leur substituent d'autres signaux de mouvement, comme les inversions rapides de scroll.

Dois-je mettre une alerte sur mon taux de frustration ?

Alertez sur un changement soudain plutôt que sur un nombre absolu, puisque le nombre absolu dépend de seuils que vous n'avez pas standardisés. Un bond juste après un déploiement vaut la peine de réveiller quelqu'un. Un taux resté à 4 pour cent pendant six mois est un élément de backlog, pas un incident.

Combien de sessions me faut-il pour que les chiffres veuillent dire quelque chose ?

Assez pour qu'un seul utilisateur ne puisse pas faire bouger le taux, ce qui veut dire grouper d'abord par utilisateur puis par élément. Si un élément représente la majorité de vos sessions marquées chez de nombreux utilisateurs différents, cela tient à petit volume. Un taux calculé sur une poignée de sessions bouge de plusieurs points chaque fois qu'une personne martèle un bouton.

Comment calcule-t-on un taux de frustration ?

Divisez le nombre de sessions avec au moins un signal par le total des sessions de la période. Une semaine avec 8 300 sessions et 412 sessions signalées donne 412 / 8 300, soit un taux de frustration de 4,96 %. Répétez le même calcul par élément pour savoir quelles pages ou quels boutons font monter le chiffre.

Pourquoi un bouton lent déclenche-t-il un rage click ?

Le détecteur ne voit que les clics, pas la raison derrière eux. Un bouton Enregistrer qui met quatre secondes à répondre reçoit plusieurs clics avant l'arrivée de la première réponse, et ce schéma correspond au même nombre, au même rayon et à la même fenêtre qu'un bouton sans aucun gestionnaire. La solution est un état optimiste, un spinner ou un endpoint plus rapide, pas un nouveau gestionnaire de clic.

Qu'est-ce qui cause généralement un dead click ?

Un dead click se déclenche sur du texte non interactif, une icône sans gestionnaire ou un état désactivé sans explication, tout ce qui ressemble à un bouton mais ne produit aucun changement du DOM, aucune navigation ni requête réseau avant l'expiration de la fenêtre d'attente. Vérifiez si l'élément a un gestionnaire de clic et s'il ressemble à un bouton.

Pourquoi regrouper les signaux de frustration par utilisateur avant de les classer ?

Une personne qui martèle un bouton quarante fois génère quarante événements de rage click pour un seul bug, et un classement qui compte les signaux bruts poursuit ce bruit au lieu du problème qui touche le plus de monde. Regroupez d'abord par utilisateur, puis par élément, pour qu'un utilisateur furieux ne pèse pas plus lourd qu'un correctif qui touche discrètement mille sessions.