Toutes les équipes produit ont déjà vu passer ce ticket. Un client écrit qu'il a cliqué sur Enregistrer et que rien ne s'est passé. Un développeur vérifie les logs. C'est enregistré. L'enregistrement est là, correct, horodaté, exactement comme prévu. Rien n'est cassé, et le ticket reste parfaitement légitime.
La même semaine arrive un autre ticket. Un client demande s'il existe un moyen de modifier plusieurs enregistrements à la fois. Il existe. La commande est dans la barre d'outils depuis deux ans, à quelques centimètres de l'endroit où cette personne travaille tous les jours.
Ce sont deux échecs d'adoption, et ils remontent dans vos rapports sous la même forme : une fonctionnalité dont l'utilisation déçoit. Ce sont pourtant des opposés. Le second utilisateur n'a pas trouvé la porte. Le premier l'a franchie et n'a pas pu savoir s'il était arrivé. Si vous les traitez de la même façon, l'un des deux reçoit une solution qui dégrade son expérience.
Le chercheur en sciences cognitives et designer Donald Norman a donné à ces deux échecs des noms qui valent la peine d'être empruntés, car avoir deux mots au lieu d'un change ce que l'on construit. Il les a appelés le gouffre de l'exécution et le gouffre de l'évaluation (en anglais, gulf of execution et gulf of evaluation, les termes que vous croiserez le plus souvent dans la littérature UX). L'un se situe avant l'action, l'autre après, et seule l'interface peut franchir l'un comme l'autre.
Ce guide explique ce que signifient les deux gouffres, comment les sept étapes de l'action se traduisent en questions que vos utilisateurs se posent réellement, pourquoi le moment de l'action est une ligne de partage que votre funnel ne voit pas, cinq signes de chaque gouffre dans des données que vous avez déjà, six solutions pour chaque côté, ce qu'il faut mesurer, et quelle moitié du travail relève du guidage in-app et quelle moitié relève du produit lui-même.
À retenir
- Le gouffre de l'exécution est la distance entre ce qu'un utilisateur veut accomplir et les actions que votre interface rend visibles et compréhensibles. C'est l'écart avant le clic.
- Le gouffre de l'évaluation est la distance entre ce que votre produit a réellement fait et ce que l'utilisateur peut en déduire à l'écran. C'est l'écart après le clic.
- Ils laissent des traces opposées. Un gouffre de l'exécution laisse un événement manquant. Un gouffre de l'évaluation laisse des événements en trop : répétitions, annulations, rechargements, un ticket qui commence par « est-ce que ça a marché ».
- Votre funnel compte l'action, il enregistre donc un gouffre de l'évaluation comme un succès. C'est pourquoi ce second type d'écart reste sans correctif pendant des années, pendant que les équipes continuent d'ajouter du guidage au premier.
- Le guidage comble le gouffre de l'exécution : une infobulle sur la commande, un hotspot sur ce que personne n'ouvre, une visite déclenchée sur la page où commence la tâche, une checklist qui reste accessible. Le feedback comble le gouffre de l'évaluation : un changement d'état visible, un message de succès qui nomme ce qui a changé, une étape suivante claire.
- Ajouter du guidage à un gouffre de l'évaluation l'aggrave. L'utilisateur n'a jamais été perdu. Lui répéter ce qu'il doit faire, alors que sa question est de savoir ce qui s'est passé, ajoute du bruit à un moment déjà incertain.
Que sont le gouffre de l'exécution et le gouffre de l'évaluation ? (Sens et définition)
Gouffre de l'exécution : définition
Le gouffre de l'exécution est l'écart entre le but qu'un utilisateur a en tête et les actions que l'interface lui propose pour l'atteindre. Il est large lorsque l'utilisateur ne sait pas ce qui est possible, ne sait pas quelle commande fait ce qu'il veut, ou ne parvient pas à utiliser correctement cette commande une fois qu'il l'a trouvée. Tout ce qui le compose se situe avant que l'action ne soit réalisée.
Gouffre de l'évaluation : définition
Le gouffre de l'évaluation est l'écart entre le nouvel état du système et ce que l'utilisateur peut percevoir, interpréter et comparer à son but de départ. Il est large lorsque le produit a changé quelque chose et que l'écran ne le dit pas, le dit d'une manière que l'utilisateur ne comprend pas, ou le dit à un endroit où l'utilisateur ne regarde pas. Tout ce qui le compose se situe après que l'action a été réalisée.
Les deux termes viennent de Donald Norman, dont le propos plus général était que l'essentiel de ce que l'on appelle une erreur de l'utilisateur relève en réalité du design : l'interface comble ces deux écarts ou ne les comble pas, et blâmer la personne restée du mauvais côté d'un gouffre n'explique rien. Ces notions ont été forgées autant pour les objets physiques que pour les logiciels, ce qui explique qu'elles s'appliquent si bien à un produit SaaS, où rien n'est physique et où chaque indice que reçoit l'utilisateur doit avoir été placé là délibérément par quelqu'un.
La façon la plus utile de retenir l'idée est la suivante : votre interface doit parler deux fois de chacune de ses fonctionnalités. Avant l'action, elle doit dire : ceci existe, cela vous concerne, voici où cela se trouve, voici ce que cela va faire. Après l'action, elle doit dire : ça a marché, voici ce qui a changé, voici où est parti le résultat, voici ce que vous pouvez faire ensuite. La plupart des produits s'en sortent plutôt bien avec la première phrase et étonnamment mal avec la seconde, parce que la première est l'objet des revues de design et des projets d'onboarding, alors que la seconde paraît évidente à la personne qui a construit la fonctionnalité.
Ces deux phrases ont leur propre nom dans la littérature du design. Le feedforward est l'information qui aide l'utilisateur à prévoir ce que fera une action avant qu'il ne s'engage. Le feedback est l'information qui lui dit ce qui s'est réellement passé. Une boîte de confirmation qui explique ce qui va être supprimé, c'est du feedforward. Un toast qui nomme l'élément supprimé et propose d'annuler, c'est du feedback. Un produit peut avoir beaucoup de l'un et presque rien de l'autre, et les symptômes n'auront rien à voir.
La phrase à écrire sur un tableau blanc : un utilisateur qui n'agit pas a un problème d'exécution, et un utilisateur qui agit puis agit à nouveau a un problème d'évaluation. Le premier est un manque dans ce que votre produit lui dit. Le second est un manque dans ce que votre produit lui répond.
Il vaut la peine d'être précis sur ce que ces gouffres ne sont pas. Ils ne se confondent pas avec la difficulté. Une tâche réellement complexe peut avoir un gouffre de l'exécution étroit, parce que l'interface est honnête et lisible à chaque étape, et une tâche triviale peut en avoir un très large, parce que la seule commande qui la réalise se cache derrière une icône que personne ne reconnaît. Ils ne se confondent pas non plus avec la friction, qui concerne l'effort que coûte un chemin une fois qu'on y est engagé. Les gouffres portent sur la question de savoir si le chemin est visible, et si l'on peut savoir qu'on en a atteint le bout.
Les sept étapes de l'action, traduites pour les équipes produit
Les deux gouffres s'inscrivent dans un modèle plus large de la manière dont une personne fait quoi que ce soit. Norman a décrit sept étapes, et elles sont plus utiles à une équipe produit qu'il n'y paraît, car chaque étape échoue d'une manière différente et chaque échec appelle une solution différente. Lisez-les comme les sept questions qu'un utilisateur se pose lors d'une tentative de réaliser une tâche.
Le but se forme dans la tête de l’utilisateur. Tout ce qui sépare le but de l’action constitue le gouffre de l’exécution, et tout ce qui sépare l’action du verdict constitue le gouffre de l’évaluation.
| Étape | Ce que se demande l'utilisateur | À quoi ressemble l'échec | Gouffre |
|---|---|---|---|
| 1. But | Qu'est-ce que je veux vraiment faire ici ? | L'utilisateur n'a pas encore de but. Il explore, ou quelqu'un d'autre lui a demandé de se connecter. | Aucun |
| 2. Planifier | Est-ce seulement possible dans ce produit ? | Il suppose que non, donc il ne cherche jamais. Il bricole plutôt une solution de contournement dans un tableur. | Exécution |
| 3. Spécifier | Quelle commande fait ça ? | Il sait que ça existe, il fouille trois menus, puis cherche dans votre centre d'aide. | Exécution |
| 4. Exécuter | Est-ce que je sais m'en servir correctement ? | Il remplit mal le formulaire, choisit la mauvaise option, abandonne au troisième champ. | Exécution |
| 5. Percevoir | Quelque chose a-t-il changé ? | L'écran semble identique. Il y a eu un spinner, peut-être. Il appuie de nouveau sur le bouton. | Évaluation |
| 6. Interpréter | Qu'est-ce que ça veut dire ? | Quelque chose a changé et il ne sait pas le décoder. Un statut est passé à En attente, et personne n'a dit pour combien de temps. | Évaluation |
| 7. Comparer | Est-ce ce que je voulais ? | Il ne parvient pas à relier le résultat au but, et ne sait donc pas s'il doit passer à la suite ou recommencer. | Évaluation |
Deux choses sautent aux yeux une fois ce tableau sous les yeux. La première, c'est que six des sept étapes peuvent échouer à cause de ce que votre interface a dit ou n'a pas dit, et que seule la première échappe réellement à votre contrôle. La seconde, c'est que presque tous les dispositifs d'analytics produit existants instrumentent l'étape quatre et rien d'autre. Vous savez combien de personnes ont cliqué sur le bouton. Vous n'avez aucune idée du nombre d'entre elles qui ont compris ce que le bouton a fait.
Les étapes expliquent aussi un phénomène que les équipes support reconnaissent immédiatement : une même fonctionnalité qui génère deux types de tickets complètement différents. « Comment j'exporte ça ? » est un échec de l'étape trois. « Mon export a-t-il fonctionné ? » est un échec de l'étape cinq. Ils portent sur la même fonctionnalité, arrivent dans la même file et appellent des réponses opposées. Si votre équipe traite les deux en rédigeant un meilleur article d'aide, un seul des deux s'améliore.
L'action est la ligne de partage, et votre funnel ne la voit pas
Voici ce qui change votre façon de travailler. Les deux gouffres entraînent une faible utilisation des fonctionnalités, une faible activation et du volume au support, mais ils laissent des empreintes complètement différentes dans vos données d'événements, et une seule de ces empreintes est du genre qu'un rapport de funnel est conçu pour repérer.
Un gouffre de l’exécution produit un événement manquant, que tout rapport de funnel est conçu pour faire ressortir. Un gouffre de l’évaluation produit des événements en double et un rechargement, que votre funnel interprète comme une étape terminée.
Un gouffre de l'exécution soustrait. L'événement qui vous intéresse ne se déclenche jamais, l'étape n'est jamais atteinte, le funnel d'onboarding affiche une chute nette à un endroit précis, et quelqu'un ouvre un ticket dans votre équipe produit pour demander pourquoi personne n'utilise l'éditeur en masse. C'est un problème visible, bien compris et bien outillé. Il existe toute une industrie de tableaux de bord pour lui.
Un gouffre de l'évaluation additionne. L'événement se déclenche, puis se déclenche de nouveau, et parfois une troisième fois. Il y a un rechargement de page au milieu. Il peut y avoir une annulation, la suppression du doublon créé par la répétition, ou une visite dans votre centre d'aide trente secondes après une action réussie. Puis l'utilisateur demande à un collègue ou écrit au support pour savoir si c'est bien passé. Dans votre funnel, cet utilisateur a converti. Dans la revue hebdomadaire, cette fonctionnalité se porte bien.
Le piège : comme les gouffres de l'évaluation sont enregistrés comme des succès, ils ne ressortent que dans le volume du support et dans les retours qualitatifs, c'est-à-dire précisément les deux signaux que les équipes produit écartent comme anecdotiques. Une fonctionnalité peut afficher un taux de complétion de quatre-vingt-dix pour cent et générer pourtant, chaque semaine, un flot régulier de messages « est-ce que ça a vraiment marché », sans que rien dans vos rapports ne relie jamais les deux.
Il reste un embranchement à nommer pour que vous posiez le diagnostic à l'intérieur du bon gouffre plutôt qu'à cheval sur les deux. Un gouffre de l'exécution a lui-même deux variantes : l'utilisateur n'a jamais ouvert la commande, ce qui est un problème de découvrabilité, ou il l'a ouverte et en est ressorti aussitôt, ce qui signifie généralement que le mot sur la commande voulait dire autre chose pour lui que pour vous. Notre guide sur les modèles mentaux en UX traite ce second cas en détail, y compris la raison pour laquelle rendre plus visible une commande mal comprise augmente les rebonds plutôt que l'utilisation. Servez-vous de ce guide-ci pour déterminer de quel côté de l'action se situe votre problème, et de celui-là pour comprendre pourquoi le côté d'avant l'action échoue.
Cinq signes d'un gouffre de l'exécution
Aucun d'eux ne nécessite un programme de recherche. Ils sont tous visibles dans des données que vous collectez déjà, ou dans les phrases que vos clients vous envoient déjà.
Une fonctionnalité livrée il y a un an et utilisée par une infime partie des comptes, sans tendance selon l'offre ou le rôle. Si elle était mal conçue, ceux qui en ont besoin l'utiliseraient et s'en plaindraient. Le silence associé à une faible portée signifie généralement que personne ne sait qu'elle existe. Consultez notre guide sur la découverte des fonctionnalités.
Les utilisateurs atteignent le résultat, mais en cinq étapes alors qu'il en existe deux. Exporter vers un tableur pour faire ce que vos filtres font déjà. Créer des enregistrements un par un juste à côté d'un import en masse. Le but est à portée de main, le chemin le plus court ne l'est pas.
Un écran avec beaucoup d'entrées et une session médiane de quatre secondes. Ils ont trouvé la porte, l'ont ouverte, et n'ont pas compris quoi faire à l'intérieur. Les états vides sont le coupable habituel, comme l'explique notre guide sur les états vides.
Comptez-les à part du reste de votre file pendant un mois. Une file dominée par les « comment faire » vous dit que votre interface ne répond pas aux étapes deux et trois, ce que le support in-app a justement vocation à corriger.
Le rapport sur le gouffre de l'exécution le moins coûteux que vous puissiez construire. Chaque recherche sans résultat est un utilisateur qui vous dit, avec ses propres mots, ce qu'il voulait et n'a pas trouvé, et les mots qu'il a employés sont ceux que votre interface devrait employer.
Cinq signes d'un gouffre de l'évaluation
Ils sont plus difficiles à voir, car aucun ne ressemble à un échec. Chacun correspond à un utilisateur qui a fait ce que vous vouliez, puis n'a pas pu savoir qu'il l'avait fait.
Deux événements Enregistrer, deux invitations à la même adresse, deux tentatives de paiement, deux exports du même rapport. C'est le signal d'évaluation le plus précieux qui soit, et presque personne n'a d'alerte dessus. Si les doublons causent de vrais dégâts dans votre produit, ce n'est pas un simple raffinement UX.
Un paramètre activé puis désactivé en moins de dix secondes. Un enregistrement créé puis supprimé. Une modification enregistrée puis annulée. L'utilisateur n'expérimente pas pour le plaisir, il sonde l'interface pour comprendre ce que son action a produit, parce que l'écran ne le lui disait pas.
Recharger une page est le geste humain universel qui signifie « je ne crois pas cet écran ». Quand ces rechargements se concentrent juste après une action précise, cette action a un problème de feedback, pas de performance. Notre guide sur les états de chargement couvre les cas où il s'agit réellement de vitesse.
Est-ce que c'est enregistré, est-ce que c'est parti, est-ce qu'ils l'ont reçu, est-ce que c'est en ligne ? Étiquetez-les à part des « comment faire ». Ils vous indiquent quelles actions de votre produit se terminent en silence, et chacune se corrige en cinq minutes de rédaction plutôt qu'avec une entrée dans la roadmap.
Imports, synchronisations, envois programmés, tout ce qui est asynchrone. Le produit a fait exactement ce qu'il promettait, vingt minutes plus tard, sur un écran que l'utilisateur avait déjà quitté. Pour l'utilisateur, il ne s'est rien passé du tout.
Deux de ces cinq signes vous coûtent directement de l'argent, et pas seulement de la bienveillance. Les actions en double créent des données que votre client doit ensuite nettoyer, ce qui se transforme en conversation avec le support au coût horaire bien réel, et des annulations sur une action payante peuvent ressembler à un litige de facturation. Les trois autres vous coûtent de la confiance, ce qui se manifeste plus tard et se retrace plus difficilement. Notre guide sur la confiance des utilisateurs explique pourquoi un résultat inexpliqué fait plus de dégâts qu'une erreur visible.
Comment combler le gouffre de l'exécution
Tout ce qui se trouve de ce côté de la ligne consiste à rendre les fonctionnalités visibles, lisibles et accessibles au moment où un but se forme. Six leviers, classés selon leur faible coût au regard de ce qu'ils retirent de votre file de support.
1. Nommer la commande comme l'utilisateur nomme son but
Avant d'expliquer quoi que ce soit, vérifiez le mot. Si vos utilisateurs disent « envoyer la facture » et que votre bouton dit Générer le document, vous avez créé de toutes pièces un échec de l'étape trois, et aucun guidage ne le compensera entièrement. Prenez le vocabulaire dans vos recherches sans résultat et vos tickets de support, pas dans votre modèle de données.
Ce que cela supprime : la chasse au bouton. L'utilisateur reconnaît la commande au lieu de la deviner.
2. Placer la réponse sur l'élément, pas dans un document
Une question qui se règle en une phrase doit trouver sa réponse là où elle se pose. Une infobulle attachée au champ qui sème la confusion ne coûte rien à lire et garde l'utilisateur dans sa tâche. L'envoyer vers un article du centre d'aide coûte un changement de contexte et généralement un aller-retour. Notre guide sur l'aide contextuelle explique comment décider quelles questions méritent quel support.
Ce que cela supprime : la sortie du produit pour répondre à une question de dix secondes.
3. Signaler ce que personne n'ouvre
Pour une fonctionnalité à la portée quasi nulle, l'intervention la moins coûteuse est un petit repère persistant sur la commande elle-même, affiché uniquement au segment concerné et retiré dès qu'il s'en sert. Un hotspot fonctionne en mode « pull » plutôt qu'en mode « push » : il attend la curiosité au lieu d'interrompre le travail, ce qui le rend supportable sur un écran utilisé tous les jours.
Ce que cela supprime : l’invisibilité de tout ce qui ne se trouve pas sur le chemin habituel de l’utilisateur.
4. Déclencher le parcours guidé là où commence la tâche, pas là où commence le compte
Une tâche en plusieurs étapes mérite une séquence guidée, mais le déclencheur compte plus que le contenu. Une visite qui s'affiche une fois à l'inscription sert une situation que l'utilisateur quitte en quelques jours. Une visite déclenchée sur la page où la tâche commence réellement le sert pendant des années, y compris la troisième fois qu'il réalise une opération trimestrielle. Notre guide sur les déclencheurs d'onboarding explique comment choisir entre conditions de page, d'événement et de segment.
Ce que cela supprime : un guidage qui n’a jamais existé qu’en première semaine.
5. Donner une seconde porte à chaque parcours
Les utilisateurs passent des choses, et ils ont raison : le paradoxe de l'utilisateur actif explique pourquoi presque tout le monde se lance plutôt que de lire d'abord. Ce qui compte, c'est que passer ne soit pas définitif. Une checklist qui reste accessible, dont un élément peut ouvrir la page concernée, rediriger ou lancer la visite, transforme un parcours ignoré en un parcours auquel l'utilisateur peut revenir quand il en a une raison.
Ce que cela supprime : la décision sans retour prise par l’utilisateur dans ses cinq premières minutes.
6. Montrer ce que l'action va faire avant qu'il ne s'engage
C'est du feedforward, et c'est la façon la moins coûteuse de réduire l'anxiété dans un logiciel. Un aperçu du nombre d'enregistrements concernés, un exemple du message qui va partir, une phrase simple qui annonce ce qui va se passer. Cela n'empêche pas tant les erreurs que cela donne aux gens l'envie d'appuyer sur le bouton, ce qui est le véritable blocage sur toute action irréversible. Notre guide sur la microcopie UX en donne les formules.
Ce que cela supprime : l’hésitation qui empêche un utilisateur d’agir sur une commande qu’il a pourtant trouvée.
Le côté exécution est une couche que vous pouvez ajouter à une interface que vous ne modifiez pas : un repère sur la commande, une phrase sur le champ, une séquence sur la page où commence la tâche, et une liste qui reste accessible.
Comment combler le gouffre de l'évaluation
Tout ce qui se trouve de ce côté de la ligne consiste à répondre à une question que l'utilisateur se pose déjà : que vient-il de se passer ? Ces correctifs sont généralement plus modestes que ceux de l'exécution, et ils sont presque toujours négligés, ce qui fait de cette liste la plus rentable du guide.
1. Rendre le changement d'état visible sur l'écran où il se trouve déjà
Le feedback le plus fort n'est pas un message à propos d'un changement, c'est le changement lui-même, affiché là où l'utilisateur regarde. Un badge de statut qui bascule, une ligne qui apparaît dans une liste, un compteur qui bouge, un champ qui affiche désormais une valeur. Un message peut passer inaperçu. Une différence visible dans ce qu'il était en train de fixer, non.
Ce que cela supprime : le besoin de faire confiance à une notification au lieu de voir le résultat.
2. Nommer l'objet, pas l'opération
Enregistré est la confirmation la plus faible qui soit, car elle confirme que le logiciel s'est exécuté plutôt que le fait que le but de l’utilisateur a été atteint. Facture 1043 envoyée à accounts@northfield.co, ça, c'est du feedback. Le message nomme l'objet, l'action et la destination, c'est-à-dire exactement les faits dont l'utilisateur a besoin pour comparer le résultat à ce qu'il voulait.
Ce que cela supprime : la seconde vérification sur un autre écran pour confirmer la première.
3. Refermer les boucles asynchrones là où se trouve l'utilisateur
Tout ce qui se termine plus tard doit rendre compte plus tard, et le faire à un endroit où l'utilisateur sera réellement. Un import terminé, une synchronisation achevée, un envoi programmé : ce sont les actions les plus susceptibles de se terminer dans un silence total. Une notification in-app ou une annonce qui apparaît à la prochaine visite de l’utilisateur referme une boucle qui, sinon, resterait ouverte pour toujours. Nos guides sur les notifications in-app et sur l'annonce des changements dans le produit couvrent la partie diffusion.
Ce que cela supprime : un travail réussi sur un écran que personne ne regardait.
4. Dire quoi faire ensuite, pas seulement que c'est terminé
L'étape sept est la comparaison avec un but, et ce but n'est presque jamais l'action que l'utilisateur vient d'effectuer : personne ne veut avoir enregistré un paramètre, on veut le résultat que produit ce paramètre. Une confirmation qui se termine par l'étape suivante referme la comparaison à sa place. Votre première campagne est programmée pour lundi, et vous pouvez la prévisualiser ici.
Ce que cela supprime : la pause pendant laquelle un utilisateur qui a réussi ne sait pas s’il a terminé.
5. Faire en sorte que les erreurs disent quoi faire, et ne jamais échouer en silence
Un échec silencieux est le pire gouffre de l'évaluation possible, car l'utilisateur repart convaincu d'avoir réussi et découvre le contraire par un collègue ou un client. Toute erreur visible, précise et accompagnée de l'action suivante vaut mieux qu'une erreur discrète, et il vaut la peine d'auditer votre produit à la recherche des actions qui peuvent échouer sans le dire.
Ce que cela supprime : la catégorie d’échecs que l’utilisateur découvre par quelqu’un d’autre.
6. Rendre l'erreur peu coûteuse et évidente
L'annulation est un mécanisme de feedback, pas seulement une fonction de sécurité. Un moyen visible de revenir en arrière dit à l'utilisateur qu'il peut sonder l'interface sans risque, ce qui lui permet d'évaluer un résultat en le testant plutôt qu'en écrivant au support. Le duo à viser : une indication claire de ce qui s'est passé, plus un moyen de l'annuler en un clic.
Ce que cela supprime : la prudence qui transforme une action incertaine en conversation avec le support.
Remarquez combien de ces six leviers relèvent de la rédaction et de la mise en page plutôt que de l'architecture. C'est la bonne nouvelle du côté évaluation : l'écart tient généralement à une phrase et à une différence visible, pas à une refonte. La mauvaise nouvelle, c'est que personne n'en est responsable. Les problèmes d'exécution sont remontés par les équipes growth et onboarding, parce qu'ils apparaissent dans les funnels. Les problèmes d'évaluation ne sont remontés par personne, parce que le funnel dit que tout va bien, et c'est pourquoi la question de qui est responsable de la couche de guidage s'avère aussi importante que ce que contient cette couche.
Chaque release rouvre les deux gouffres
Les gouffres ne sont pas un problème de première session. Ils se rouvrent à chaque changement que vous livrez, pour chaque utilisateur qui s'était déjà fait un modèle fonctionnel de l'ancien écran.
Quand vous déplacez une commande, vous élargissez le gouffre de l'exécution pour tous ceux qui savaient où elle se trouvait. Ce ne sont pas des débutants, donc aucun parcours d'onboarding ne les rattrapera, et ils chercheront deux fois à l'ancien emplacement avant d'ouvrir un ticket. Quand vous changez ce que fait une action, ajoutez une étape de confirmation ou rendez asynchrone quelque chose qui était instantané, c'est le gouffre de l'évaluation que vous élargissez : la même action qu'ils ont réalisée cent fois produit désormais un signal différent, et leur lecture entraînée de l'écran devient soudain fausse.
C'est pourquoi une note de version n'est pas une stratégie de guidage. Une note vit en dehors du produit, est lue par une petite minorité et est oubliée avant que la personne ne retouche cet écran. Ce qui comble un gouffre créé par une release, c'est un repère à l'endroit du changement, affiché aux personnes concernées, au moment où elles arrivent sur l'écran. Notre guide sur les raisons pour lesquelles les visites produit cassent couvre l'autre moitié du problème : votre guidage existant était ancré sur une interface que vous venez de modifier.
-
Une commande déplacée
Gouffre de l'exécution pour les utilisateurs existants. Signalez le nouvel emplacement au segment qui utilisait l'ancien, et laissez le repère en place pendant un cycle d'utilisation complet plutôt qu'une semaine.
-
Une action dont le comportement a changé
Gouffre de l'évaluation. Le texte de confirmation doit changer avec le comportement, sinon les utilisateurs habitués liront le nouveau résultat comme l'ancien.
-
Une opération devenue asynchrone
Gouffre de l'évaluation, et le plus souvent oublié. Ce qui se terminait sous leurs yeux se termine désormais après leur départ, et il faut donc leur en rendre compte.
-
Une nouveauté livrée
Gouffre de l'exécution pour toute votre base existante d'un coup, puisqu'aucun d'eux ne l'a découverte pendant l'onboarding. C'est le cas où l'annonce dans le produit, juste à côté du changement, fait le travail.
Combler les deux gouffres avec Kompassify
La répartition honnête du travail est la suivante : le gouffre de l'exécution peut en grande partie être comblé par une couche de guidage posée sur une interface que vous ne modifiez pas, et le gouffre de l'évaluation, pour l'essentiel, ne le peut pas, car la confirmation d'un changement d'état appartient au produit qui a changé cet état. Ce qu'une couche de guidage et d'analytics peut faire côté évaluation, c'est vous aider à trouver les écarts et à refermer les boucles plus lentes. Les deux moitiés valent la peine, et une seule a besoin de votre équipe technique.
-
Infobulles et hotspots sur les vrais éléments
Créez-les en sélectionnant la commande sur votre propre écran, sans code, et associez-y la phrase qui répond à la question qu'elle soulève. C'est la solution directe aux échecs des étapes deux et trois.
-
Visites produit avec analytics par étape
Guidez une tâche en plusieurs étapes et voyez quelle étape fait décrocher les gens. Une étape peut aussi attendre le vrai clic de l’utilisateur sur l’élément plutôt qu’un bouton Suivant, pour que le guidage suive le travail au lieu de le commenter.
-
Checklists qui restent accessibles
Un élément peut ouvrir une page, rediriger ou lancer une visite, ce qui donne une seconde porte à chaque parcours et transforme un parcours guidé ignoré en quelque chose auquel l'utilisateur peut revenir. Les coches visibles sont aussi du feedback à part entière : une progression que l'utilisateur voit sans avoir à demander.
-
Annonces pour les boucles qui se referment plus tard
Une cloche et un panneau de nouveautés qui peuvent lancer une visite depuis une annonce et recueillir du feedback, ce qui permet de rendre compte à l'utilisateur d'un changement survenu après son départ.
-
Analytics produit no-code pour repérer les deux gouffres
L'utilisation des fonctionnalités côte à côte vous montre la portée quasi nulle qui signale un gouffre de l'exécution. Les parcours utilisateurs et les événements suivis sont l'endroit où chercher la répétition, l'annulation et le rechargement qui signalent un gouffre de l'évaluation, un schéma qu'aucun rapport de funnel standard ne vous montrera.
-
Ciblage par segment et par page sur chaque parcours
Ainsi, le repère sur une commande déplacée ne s'affiche qu'aux personnes qui utilisaient l'ancienne, et personne ne se voit présenter une fonctionnalité qu'il utilise déjà tous les jours.
Kompassify est no-code : les parcours se construisent en pointant votre propre interface, et la même couche sert un utilisateur dans sa première semaine comme un client depuis deux ans, car le déclencheur est la page et le comportement plutôt que la date d'inscription. C'est gratuit jusqu'à 100 utilisateurs actifs mensuels, les offres commencent à 129 $ par mois, et la solution est conforme au RGPD et hébergée dans l'UE.
Découvrez dans quel gouffre se trouvent vos utilisateurs
Signalez les commandes que personne ne trouve, répondez au niveau de l'élément, et utilisez les rapports d'utilisation des fonctionnalités et de parcours utilisateur pour repérer les répétitions et les annulations que votre funnel prend pour des succès. Aucun code requis. Gratuit jusqu'à 100 utilisateurs actifs mensuels, offres à partir de 129 $/mois, conforme au RGPD et hébergé dans l'UE.
Commencer gratuitement →Ce qu'il faut mesurer
Six chiffres, trois pour chaque gouffre. L'intérêt de les séparer, c'est qu'un chiffre unique d'adoption des fonctionnalités fait la moyenne des deux problèmes et masque celui que vous ne cherchez pas.
| Indicateur | Gouffre | Ce que signifie un mauvais chiffre | Ce que vous pouvez faire |
|---|---|---|---|
| Portée par fonctionnalité | Exécution | La fonctionnalité est invisible pour la plupart des comptes auxquels elle s'adresse. | Signalez la commande à ce segment, puis mesurez de nouveau la portée, pas les clics. |
| Taux entrée vers première action | Exécution | Les gens arrivent sur l'écran et ne font rien. La porte a été trouvée, l'intérieur n'était pas lisible. | Corrigez l'état vide et ajoutez une phrase sur la première commande. |
| Recherches sans résultat | Exécution | Les utilisateurs demandent des choses avec des mots que votre interface n'emploie pas. | Renommez avant d'expliquer, puis vérifiez la même liste un mois plus tard. |
| Taux de répétition sous 60 secondes | Évaluation | L'action s'est terminée et l'écran ne l'a pas dit de manière convaincante. | Rendez le changement d'état visible et nommez l'objet dans la confirmation. |
| Taux d'annulation immédiate | Évaluation | Les utilisateurs sondent l'interface pour comprendre ce que leur action a produit. | Ajoutez du feedforward avant l'action et un résultat précis après. |
| Part des tickets « est-ce que » dans la file | Évaluation | Certaines actions de votre produit se terminent en silence. | Étiquetez par action, corrigez par la rédaction les trois plus fréquentes, suivez le volume de l'étiquette. |
Le décrochage par étape, c’est le côté exécution rendu visible : l’étape où les gens partent est l’étape de la tâche que votre interface n’explique pas.
Deux de ces six chiffres ne figurent probablement pas dans vos analytics aujourd'hui. Le taux de répétition et le taux d'annulation immédiate nécessitent un événement sur l'action et un minimum de réflexion sur la fenêtre de temps à prendre en compte, et une fois en place, ce sont généralement les deux chiffres les plus actionnables de la liste, car chacun pointe vers une phrase précise sur un écran précis. Nos guides sur le suivi des événements et l'analyse comportementale expliquent comment les mettre en place sans équipe data, et le session replay est le moyen le plus rapide de confirmer à quoi ressemblait réellement une répétition.
Les deux gouffres : à faire et à éviter
✅ À faire
- Demandez-vous de quel côté de l'action se situe la confusion avant de choisir une solution.
- Étiquetez les tickets de support « comment faire » ou « est-ce que », et comptez-les séparément.
- Créez une alerte sur les actions répétées dans un court intervalle.
- Nommez l'objet et le résultat dans chaque confirmation.
- Rendez compte de tout ce qui se termine après le départ de l'utilisateur.
- Terminez un message de succès par l'étape suivante, pas par un point final.
- Vérifiez de nouveau les deux gouffres après toute release qui déplace ou modifie une commande.
- Corrigez le mot sur la commande avant d'ajouter du guidage pour l'expliquer.
❌ À éviter
- Répondre à chaque problème d'adoption par une visite de plus.
- Prendre un taux de complétion de quatre-vingt-dix pour cent pour la preuve qu'un parcours est compris.
- Se contenter d'un simple Enregistré comme confirmation d'une action importante.
- Laisser une action, quelle qu'elle soit, échouer en silence.
- Considérer qu'un spinner vaut feedback une fois qu'il a disparu.
- Annoncer une nouvelle fonctionnalité uniquement dans un changelog ou un e-mail de release.
- Rendre plus visible une commande mal comprise et appeler ça de la découverte.
- Balayer les messages « est-ce que ça a marché » en estimant que les utilisateurs lisent mal.
La version en un paragraphe
Chaque tâche qu'un utilisateur entreprend comporte deux écarts. Avant d'agir, il doit comprendre si ce qu'il veut est possible, quelle commande le permet et comment s'en servir : c'est le gouffre de l'exécution, et on le comble par le guidage, par les mots sur vos commandes et en plaçant les réponses sur les éléments qui soulèvent des questions. Après avoir agi, il doit comprendre si quelque chose a changé, ce que cela signifie et si cela correspond à ce qu'il voulait : c'est le gouffre de l'évaluation, et on le comble par des changements d'état visibles, par des confirmations qui nomment l'objet plutôt que l'opération, et en rendant compte du travail qui se termine après son départ. Les deux gouffres produisent une faible adoption des fonctionnalités, et votre funnel ne vous en montre qu'un, car un utilisateur qui agit sans pouvoir savoir ce qui s'est passé est enregistré comme une conversion. Classez vos problèmes d'adoption selon le côté de l'action où ils se situent, comptez les répétitions et les annulations avec autant de soin que les abandons, et cessez de répondre à un gouffre de l'évaluation par davantage de guidage : cet utilisateur n'a jamais été perdu, et lui répéter quoi faire ne répond pas à la question qu'il se pose.
Questions fréquentes
Qu'est-ce que le gouffre de l'exécution ?
Le gouffre de l'exécution est l'écart entre ce qu'un utilisateur veut accomplir et les actions que votre interface lui rend visibles et compréhensibles. Il est large lorsque l'utilisateur ne sait pas si une chose est possible dans votre produit, ne sait pas quelle commande permet de la faire, ou ne parvient pas à utiliser correctement cette commande une fois qu'il l'a trouvée. Tout ce qui se joue dans ce gouffre se passe avant que l'action ne soit réalisée, c'est pourquoi on le comble par du guidage : les mots sur vos boutons, une infobulle sur le champ qui sème la confusion, un repère sur la fonctionnalité que personne n'ouvre, et une séquence guidée déclenchée sur la page où commence la tâche.
Qu'est-ce que le gouffre de l'évaluation ?
Le gouffre de l'évaluation est l'écart entre le nouvel état de votre système après une action et ce que l'utilisateur peut réellement en déduire à l'écran. Il est large lorsque votre produit a changé quelque chose et que l'interface ne le dit pas, le dit d'une manière que l'utilisateur ne sait pas décoder, ou le dit à un endroit où l'utilisateur ne regarde pas. Tout ce qui se joue dans ce gouffre se passe après l'action, c'est pourquoi on le comble par du feedback plutôt que par du guidage : un changement d'état visible, une confirmation qui nomme l'objet et le résultat, un retour sur le travail terminé plus tard, et une étape suivante claire.
Quelle est la différence entre le gouffre de l'exécution et le gouffre de l'évaluation ?
C'est l'action qui les sépare. Le gouffre de l'exécution couvre tout ce qui précède l'action, l'action comprise, et la question de l'utilisateur est : que puis-je faire ici, et où ? Le gouffre de l'évaluation couvre tout ce qui suit l'action, et la question de l'utilisateur est : est-ce que ça a marché, et qu'est-ce qui a changé ? Ils laissent aussi des traces opposées dans vos données : un gouffre de l'exécution signifie que l'événement ne se déclenche jamais, tandis qu'un gouffre de l'évaluation signifie que l'événement se déclenche plusieurs fois, est annulé, ou est suivi d'un rechargement de page et d'un message au support.
Qui a inventé les notions de gouffre de l'exécution et de gouffre de l'évaluation ?
Les deux termes viennent du chercheur en sciences cognitives et designer Donald Norman, dans le cadre d'un modèle en sept étapes décrivant comment les gens agissent sur le monde puis jugent le résultat. Son argument plus large était que l'essentiel de ce qu'on enregistre comme une erreur de l'utilisateur relève en réalité du design : une interface comble ces deux écarts ou laisse la personne bloquée d'un côté, et la traiter de négligente n'explique rien et ne corrige rien.
Quelles sont les sept étapes de l'action ?
But, planifier, spécifier, exécuter, percevoir, interpréter et comparer. Le but se forme dans la tête de l'utilisateur. Planifier, spécifier et exécuter constituent le gouffre de l'exécution : est-ce possible, quelle commande le fait, est-ce que je sais l'utiliser ? Percevoir, interpréter et comparer constituent le gouffre de l'évaluation : quelque chose a-t-il changé, qu'est-ce que ça veut dire, est-ce ce que je voulais ? Ce qui est utile pour une équipe produit, c'est que six des sept étapes peuvent échouer à cause de ce que l'interface a dit ou n'a pas dit, alors que la plupart des dispositifs d'analytics n'instrumentent que la quatrième.
Pourquoi un gouffre de l'évaluation n'apparaît-il pas dans les analytics produit ?
Parce que votre funnel compte l'action, et que dans un gouffre de l'évaluation, l'action a bien eu lieu. L'utilisateur a appuyé sur le bouton, l'événement s'est déclenché, l'étape est enregistrée comme terminée, et le rapport indique que la fonctionnalité se porte bien. Les preuves du problème se trouvent dans des signaux que la plupart des équipes ne suivent pas : la même action répétée en moins d'une minute, une modification faite puis aussitôt annulée, une page rechargée juste après un succès, et des tickets de support qui commencent par « est-ce que c'est enregistré » ou « est-ce qu'il l'a reçu ». Tant que vous ne les comptez pas, un gouffre de l'évaluation reste invisible pour tout le monde, sauf pour votre équipe support.
Comment savoir s'il faut ajouter du guidage ou corriger le feedback ?
Demandez-vous si l'utilisateur a agi. Si l'événement ne se déclenche jamais, ou se déclenche bien moins souvent que le nombre de comptes concernés par la fonctionnalité, vous avez un gouffre de l'exécution et le guidage est le bon outil. Si l'événement se déclenche puis est répété, annulé, ou suivi d'un rechargement ou d'un message du type « est-ce que ça a marché », vous avez un gouffre de l'évaluation, et davantage de guidage l'aggravera, car l'utilisateur n'a jamais été perdu. À l'intérieur du gouffre de l'exécution, il existe un second embranchement à vérifier : jamais ouvert signifie un problème de découvrabilité, tandis qu'ouvert puis abandonné en quelques secondes signifie généralement que le libellé voulait dire autre chose pour l'utilisateur que pour vous.
Quelle est la différence entre feedforward et feedback ?
Le feedforward est l'information qui aide un utilisateur à prévoir ce que fera une action avant qu'il ne s'engage, comme un aperçu du nombre d'enregistrements concernés ou une phrase qui annonce ce qui va se passer. Le feedback est l'information qui lui dit ce qui s'est réellement passé, comme un badge de statut qui bascule ou un message qui nomme l'objet envoyé et sa destination. Le feedforward réduit le gouffre de l'exécution et le feedback réduit le gouffre de l'évaluation, et un produit peut avoir beaucoup de l'un et presque rien de l'autre.
Le guidage in-app peut-il combler le gouffre de l'évaluation, ou faut-il passer par l'équipe technique ?
Le plus souvent, il faut toucher au produit, car la confirmation d'un changement d'état appartient à l'élément qui a changé cet état, et une couche de guidage posée par-dessus votre interface ne peut pas inventer un badge de statut qui n'existe pas. Ce qu'une couche de guidage et d'analytics apporte côté évaluation, c'est de repérer les écarts et de refermer les boucles plus lentes : les rapports d'utilisation des fonctionnalités et de parcours utilisateur vous montrent les répétitions et les annulations que votre funnel prend pour des succès, et une annonce in-app peut rendre compte d'un travail terminé après le départ de l'utilisateur. Le côté exécution, en revanche, peut presque entièrement être comblé sans mobiliser l'équipe technique.