Il existe un silence bien particulier qui s'installe environ quatre-vingt-dix secondes après le début d'un test d'utilisabilité. Le participant a cessé de bouger la souris. Il regarde un écran que votre équipe a conçu, relu et mis en production, et il n'arrive pas à comprendre quoi faire ensuite.
Personne dans l'équipe produit n'aurait pu prévoir cette pause, parce que tout le monde dans l'équipe produit sait déjà où se trouve le bouton. C'est toute la valeur du test d'utilisabilité : c'est la seule méthode de recherche qui vous montre de façon fiable les parties de votre produit invisibles aux yeux de ceux qui l'ont construit.
Ce guide explique ce qu'est le test d'utilisabilité, présente les six méthodes et le moment où chacune vaut son coût, les métriques qui ont du sens, le nombre de participants réellement nécessaire, un processus en sept étapes à lancer dès cette semaine et un script prêt à copier pour tester le parcours où les problèmes d'utilisabilité coûtent le plus cher : l'onboarding.
À retenir
- Observez les comportements, ne collectez pas d'opinions. Faire un test d'utilisabilité, c'est confier une tâche réaliste à quelqu'un et observer ce qui se passe. Dès que vous demandez « est-ce que ça vous plaît ? », vous avez cessé de tester l'utilisabilité.
- Cinq participants par groupe trouvent la plupart des problèmes. Cinq est le bon chiffre pour des tests qualitatifs qui cherchent des problèmes. C'est le mauvais si vous comptez publier un pourcentage.
- Le taux de réussite des tâches est la métrique phare. Les gens parviennent-ils à terminer la tâche sans aide ? Tout le reste (temps passé, erreurs, scores de facilité) explique ce chiffre au lieu de le remplacer.
- Le modéré trouve le « pourquoi », le non modéré trouve le « combien ». Utilisez des sessions modérées pour les parcours précoces, complexes ou ambigus ; des sessions non modérées pour les tâches bien définies que vous voulez faire passer en volume.
- Test d'utilisabilité et A/B testing se succèdent, ils ne s'opposent pas. Testez pour trouver la cause et concevoir la correction, puis faites un A/B test de la correction à grande échelle.
- L'onboarding est le parcours le plus rentable à tester. C'est la seule partie de votre produit que chaque utilisateur vit, une seule fois, sans aucune connaissance accumulée sur laquelle s'appuyer.
Qu'est-ce qu'un test d'utilisabilité ?
Définition du test d'utilisabilité : une méthode de recherche dans laquelle des utilisateurs représentatifs tentent d'accomplir des tâches réalistes dans un produit pendant qu'un observateur note où ils réussissent, hésitent ou échouent. Son but est de mesurer la facilité avec laquelle une tâche précise peut réellement être accomplie, pas de recueillir des avis sur le design.
La distinction compte plus qu'il n'y paraît. Demandez à quelqu'un ce qu'il pense d'un écran : il sera poli, serviable et presque entièrement à côté de la plaque, non pas parce qu'il ment, mais parce que les gens sont de mauvais témoins de leur propre confusion. Demandez à la même personne d'accomplir une tâche sur cet écran et observez : en une minute, vous aurez vu des choses qu'elle n'aurait jamais su formuler.
Ce que le test d'utilisabilité fait bien
- Trouver le point exact d'échec. Les analytics vous disent que 40 % des utilisateurs décrochent à l'étape trois. Un test d'utilisabilité vous dit que c'est parce que les boutons principal et secondaire se ressemblent trait pour trait.
- Révéler les problèmes de vocabulaire. Le jargon interne s'infiltre sans cesse dans les interfaces, et les utilisateurs contournent les mots qu'ils ne comprennent pas plutôt que de poser la question.
- Tester avant de construire. Un prototype cliquable se teste en un après-midi. Une fonctionnalité livrée coûte un trimestre.
- Trancher les débats internes à moindre coût. Trois enregistrements de vraies personnes qui échouent sur quelque chose clôturent une discussion plus vite que n'importe quelle quantité d'opinions.
Ce que le test d'utilisabilité fait mal
- Vous dire si les gens veulent le produit. C'est une question de désirabilité et de marché, plus proche de la recherche Jobs to Be Done que de l'utilisabilité.
- Produire des chiffres statistiquement fiables à partir de petits échantillons. « Quatre participants sur cinq ont échoué » est un signal, pas une mesure.
- Prédire le comportement à long terme. Une tâche réussie pendant une session ne dit rien sur le retour de la personne la semaine suivante.
- Remplacer les analytics. Le test explique un comportement que vous avez déjà détecté. C'est un mauvais moyen de détecter ce comportement au départ.
Test d'utilisabilité, recherche UX ou A/B testing
Ces trois termes sont employés indifféremment en réunion de planification, alors qu'ils répondent à des questions vraiment différentes. Choisir le mauvais, c'est ainsi que des équipes se retrouvent avec une superbe présentation de recherche qui ne change rien, ou avec un A/B test qui prouve que la version B est moins bonne sans jamais expliquer pourquoi.
| Méthode | Question à laquelle elle répond | Taille d'échantillon | Résultat |
|---|---|---|---|
| Test d'utilisabilité | Les gens peuvent-ils accomplir cette tâche, et où exactement ont-ils du mal ? | 5–8 par groupe | Points d'échec observés, verbatims, liste de corrections priorisée |
| Recherche utilisateur / UX (entretiens, études terrain) | Que cherchent réellement à accomplir les gens, et dans quel contexte ? | 8–15 | Jobs, besoins, modèles mentaux, définitions de segments |
| A/B testing | Laquelle de ces deux versions obtient le meilleur résultat sur une métrique ? | Des centaines à des milliers | Un gagnant statistiquement comparable, sans explication |
| Analytics produit | Où, à grande échelle, les utilisateurs décrochent-ils ? | Tous les utilisateurs | Entonnoirs, taux de décrochage, comportement par cohorte |
L'enchaînement qui fonctionne : les analytics trouvent où les utilisateurs décrochent → le test d'utilisabilité explique pourquoi → vous concevez une correction → l'A/B testing prouve que la correction fonctionne à grande échelle. Sauter l'étape du milieu explique pourquoi tant d'expériences restent non concluantes : sans diagnostic, la version B n'est qu'une supposition en blouse de laboratoire.
Les 6 méthodes de test d'utilisabilité
Tout test d'utilisabilité se situe quelque part sur deux axes : un chercheur est-il présent, et cherchez-vous à compter ou à expliquer ? Ces deux choix produisent les six formats pratiques ci-dessous.
1. Test modéré à distance
Un chercheur et un participant partagent un écran en visio. Le participant enchaîne les tâches en pensant à voix haute ; le chercheur reste silencieux et ne pose une relance que lorsqu'il se passe quelque chose d'intéressant. C'est la méthode par défaut de la plupart des équipes SaaS : elle offre la profondeur d'un test en présentiel sans les déplacements, et les enregistrements se partagent en un clic avec le reste de l'équipe.
Coût : modéré. Délai : quelques jours. Idéal pour : tout ce dont vous n'êtes pas sûr.
2. Test non modéré à distance
Les participants reçoivent des tâches et les réalisent seuls pendant que leur écran et leur voix sont enregistrés. Vous obtenez dix sessions en une nuit au lieu de cinq en une semaine, et vous perdez la possibilité de demander « qu'est-ce que vous vous attendiez à voir se produire ici ? » au seul moment où cela comptait.
Le non modéré fonctionne bien quand la tâche est sans ambiguïté et que le produit fonctionne réellement. Il fonctionne mal sur des prototypes sommaires, où les participants passent la session perdus face au test plutôt que face au design.
3. Test modéré en présentiel
C'est toujours l'option la plus fidèle, car vous voyez la posture, l'hésitation et ces petits signaux physiques qui ne survivent jamais à un appel vidéo. Le coût est réel, si bien que la plupart des équipes la réservent aux parcours à fort enjeu (un changement de tarif, un tunnel de paiement, la refonte d'un workflow central) ou aux participants difficiles à joindre autrement.
4. Test guérilla
Cinq minutes, une tâche, avec qui veut bien. L'échantillon n'est pas représentatif et vous devez l'assumer honnêtement. Mais si votre question est « est-ce que quelqu'un comprend à quoi sert ce bouton ? », le test guérilla y répond aujourd'hui plutôt que dans trois semaines, et un échec net reste instructif quel que soit le participant.
5. Test du premier clic et tree testing
Des méthodes ciblées et quantitatives, centrées sur la navigation. Le test du premier clic demande où quelqu'un cliquerait pour atteindre un objectif ; le tree testing lui demande de trouver un élément dans une version épurée de votre architecture de l'information, sans aucun design visuel. Les deux passent à l'échelle de centaines de participants, les deux sont peu coûteux, et les deux excellent à prouver qu'un libellé de menu dont personne n'a débattu échoue en silence.
6. Test de benchmark
Les mêmes tâches, le même script, mesurés avec les mêmes métriques tous les quelques mois. Chaque série prise isolément compte moins que la tendance : un taux de réussite qui glisse de 78 % à 61 % en trois versions vous dit que l'accumulation de fonctionnalités a rendu un parcours central plus difficile, ce qui est le mécanisme derrière la plupart des cas de feature bloat.
Les métriques d'utilisabilité qui comptent
Les petites études qualitatives produisent des observations, pas des statistiques. Notez quand même les chiffres : ils disciplinent l'analyse et rendent possible la comparaison d'une série à l'autre, mais soyez honnête sur ceux qui ont du poids avec n=5.
| Métrique | Ce qu'elle mesure | Comment la lire |
|---|---|---|
| Taux de réussite des tâches | Part des participants qui terminent la tâche sans aide | Le chiffre phare. Tout ce qui passe sous environ 78 % sur une tâche centrale mérite une attention immédiate |
| Temps passé sur la tâche | Le temps nécessaire pour terminer | Utile comparé à lui-même dans le temps, ou à une attente réaliste, pas à une cible arbitraire |
| Taux d'erreur | Mauvais clics, mauvais chemins, mauvaises saisies par tâche | Des erreurs identiques qui se répètent désignent un défaut de design corrigeable, pas des utilisateurs distraits |
| Aides | Le nombre de fois où le modérateur a dû intervenir | Une aide est un échec qui porte un nom poli. Comptez-les honnêtement |
| Single Ease Question (SEQ) | Une note de 1 à 7 demandée juste après chaque tâche | Une seule question, posée pendant que l'expérience est fraîche. La métrique subjective utile la moins chère qui existe |
| System Usability Scale (SUS) | Un questionnaire de 10 items en fin de session, noté de 0 à 100 | Environ 68 correspond à la moyenne. Surtout parlant comme tendance d'une série à l'autre ou face à votre propre score passé |
| Point de décrochage | L'étape précise où les participants s'arrêtent | Le résultat le plus actionnable de toute la session, et celui qui se reporte directement sur votre entonnoir |
Ne publiez pas de pourcentages calculés sur cinq personnes. « 60 % des utilisateurs ont échoué » sur un échantillon de cinq, cela fait trois personnes, et l'intervalle de confiance autour de ce chiffre est énorme. Dites plutôt « trois participants sur cinq ont échoué à la même étape, tous pour la même raison ». C'est plus honnête et, en pratique, nettement plus convaincant.
Combien de participants vous faut-il ?
C'est la question la plus débattue du test d'utilisabilité, et sa réponse est banale : tout dépend de si vous cherchez des problèmes ou si vous les mesurez.
✅ Cinq suffisent quand…
- Vous voulez trouver des problèmes d'utilisabilité, pas les compter
- Les participants appartiennent à un groupe raisonnablement homogène
- Vous prévoyez de corriger ce que vous trouvez et de tester à nouveau
- Vous testez un prototype ou un seul parcours
❌ Cinq ne suffisent pas quand…
- Il vous faut un chiffre que vous comptez publier ou comparer
- Vous servez des segments réellement distincts (faites-en cinq par segment)
- Vous faites un benchmark d'une version à l'autre
- La décision est coûteuse et irréversible
La règle des « cinq utilisateurs » vient de l'observation de Jakob Nielsen selon laquelle environ cinq participants font apparaître à peu près 85 % des problèmes d'utilisabilité d'un parcours donné, parce que les problèmes ne sont pas répartis uniformément : les plus graves touchent presque tout le monde. Cette logique tient pour la découverte de problèmes et s'effondre complètement pour la mesure, où il vous faut généralement 20 participants ou plus par groupe.
La reformulation la plus utile : faites plus de séries, pas de plus grosses séries. Trois séries de cinq participants, avec des corrections entre chacune, amélioreront un produit bien plus qu'une seule série de quinze, parce que les séries deux et trois testent quelque chose de meilleur que la première.
Comment mener un test d'utilisabilité en 7 étapes
Définir la question à laquelle le test doit répondre
Rédiger des tâches réalistes, formulées comme des résultats
Recruter les bons participants
Préparer le script et l'environnement
Mener la session et rester silencieux
Analyser par tendances, pas par anecdotes
Corriger, livrer et tester à nouveau
1. Définir la question à laquelle le test doit répondre
« Testons le nouveau tableau de bord » n'est pas une question de recherche. « Un nouvel utilisateur peut-il créer et partager un rapport sans aide ? » en est une. Une question unique et précise détermine vos tâches, vos participants et ce qui compte comme résultat, et elle empêche la session de dériver vers une discussion générale sur le produit.
La meilleure source de ces questions, c'est votre propre entonnoir. Partout où les analytics d'onboarding montrent une chute inexpliquée, vous tenez une question qui vaut cinq sessions.
2. Rédiger des tâches réalistes, formulées comme des résultats
Une tâche doit décrire un objectif et un contexte, et elle ne doit pas contenir les instructions pour l'accomplir. La façon la plus courante de ruiner un test d'utilisabilité est de nommer le bouton dans la consigne.
✅ Bonnes formulations de tâches
- « Votre manager veut les chiffres du mois dernier avant vendredi. Envoyez-lui un rapport qu'il pourra ouvrir. »
- « Vous venez de rejoindre cette équipe. Trouvez sur quoi vous êtes censé travailler en premier. »
- « Un collègue doit relire ceci avant envoi. Faites en sorte que ce soit possible. »
❌ Formulations qui donnent la réponse
- « Cliquez sur Rapports, puis choisissez Exporter, puis sélectionnez PDF. »
- « Utilisez la fonction de partage pour partager le document. »
- « Trouvez-vous la nouvelle navigation intuitive ? »
3. Recruter les bons participants
Représentatif vaut mieux que pratique. Si vous testez une expérience de première utilisation, le seul critère éliminatoire est la familiarité avec votre produit, ce qui exclut vos collègues, vos investisseurs et tout client existant.
Les sources qui fonctionnent : des inscrits récents qui ne se sont pas encore reconnectés une deuxième fois, des utilisateurs d'une cohorte partie en churn, un panel de recrutement, ou un sondage in-app ciblé qui propose une contrepartie aux utilisateurs présentant un comportement précis. Filtrez sur le comportement qui compte, pas sur l'intitulé de poste.
4. Préparer le script et l'environnement
Écrivez le script, y compris l'introduction, et lisez la même introduction à chaque fois. Deux éléments y ont leur place et sont régulièrement oubliés : une déclaration explicite que vous testez le produit et non le participant, et l'autorisation d'enregistrer.
Vérifiez ensuite l'environnement. Un compte de test prérempli avec de jolies données de démo masquera tous vos problèmes d'état vide ; un compte réellement vierge reproduira la vraie expérience de première utilisation. Décidez délibérément lequel des deux vous testez.
5. Mener la session et rester silencieux
Le silence est le principal outil du modérateur et la partie la plus difficile du travail. Quand un participant hésite, l'envie d'aider est irrésistible, et aider détruit justement les données que vous êtes venu chercher. Attendez. Comptez jusqu'à dix. La plupart du temps, il s'en sort seul et vous apprenez exactement comment.
Trois phrases couvrent presque toutes les situations :
- « À quoi pensez-vous en ce moment ? » : face au silence
- « Que vous attendriez-vous à voir se produire si vous cliquiez là ? » : face à l'hésitation
- « Que feriez-vous si je n'étais pas là ? » : face à une demande d'aide directe
6. Analyser par tendances, pas par anecdotes
Après les sessions, listez chaque problème observé avec le numéro du participant et l'étape où il est survenu. Puis regroupez-les. Un problème apparu une fois est une note ; un problème apparu dans quatre sessions sur cinq à la même étape est un défaut qui mérite sa place dans le backlog.
Classez les groupes par gravité (a-t-il bloqué la tâche ?) et par fréquence (combien de participants l'ont rencontré ?). Bloquant et fréquent passe en premier. Le piège séduisant, ici, c'est la citation marquante d'un participant éloquent : ce sera la chose la plus mémorable du débrief, et ce n'est pas forcément la plus importante.
7. Corriger, livrer et tester à nouveau
Un test d'utilisabilité qui se termine par un document a échoué. Le résultat doit être une courte liste priorisée, chaque élément ayant un responsable, la plupart étant petits : un libellé, une valeur par défaut, une étape réordonnée, une explication déplacée là où la confusion se produit.
Cette dernière catégorie mérite qu'on s'y attarde. Une part importante des constats d'utilisabilité ne sont pas des problèmes de mise en page mais une explication manquante à un moment précis. Ceux-là n'ont pas besoin d'une refonte ; ils ont besoin d'une infobulle ou d'une courte visite produit ancrée sur l'élément exact où quatre personnes sur cinq ont marqué une pause. Avec Kompassify, vous pouvez livrer cette correction l'après-midi même, sans mise en production, et tester à nouveau la semaine suivante.
Comment tester l'utilisabilité de votre parcours d'onboarding
L'onboarding mérite sa propre section, car il enfreint les règles habituelles du test. Chaque utilisateur le vit, chacun le vit une seule fois, et c'est le seul parcours où le participant n'a aucune connaissance accumulée sur laquelle s'appuyer. C'est aussi le parcours que votre propre équipe est le moins capable d'évaluer, parce qu'aucun d'entre vous ne peut oublier ce qu'il sait de votre produit.
Commencez au vrai début
Pas le tableau de bord. Pas un compte préconfiguré. Le vrai point d'entrée, la landing page ou le formulaire d'inscription, car une part surprenante de la friction de première utilisation naît avant même que quiconque soit connecté, sous la forme d'un champ déroutant, d'une étape obligatoire inattendue ou d'un décalage entre ce que la page marketing promettait et ce sur quoi le produit s'ouvre. Notre guide du parcours d'inscription couvre ce passage en détail.
Fixez une seule tâche formulée comme un résultat, puis taisez-vous
Une seule tâche, formulée comme le résultat que l'utilisateur est venu chercher : « Allez jusqu'au point où vous sauriez si cet outil vaut la peine d'être utilisé. » Puis arrêtez de parler. La tentation de commenter est la plus forte ici, et chaque phrase que vous ajoutez éloigne le test de la réalité.
Notez quatre choses
- Le temps jusqu'au premier résultat utile, la version observable du time to value
- Le premier moment d'hésitation, généralement plus tôt que ce qu'imagine quiconque dans l'équipe
- Chaque question posée à voix haute : chacune est un morceau de texte manquant dans le produit
- S'ils ont seulement atteint l'aha moment, et si oui, s'ils l'ont remarqué
Testez délibérément l'état vide
L'échec d'onboarding le plus courant, c'est un utilisateur qui arrive sur un écran vide sans aucune idée de ce qu'il doit y mettre. Il n'apparaît jamais en revue interne, car les comptes internes regorgent de données. Faites passer au moins un participant par un compte réellement vide et observez ce qui se passe, puis lisez notre guide des états vides.
Bouclez la boucle dans le produit
Les constats sur l'onboarding se traduisent de façon exceptionnellement directe en corrections dans le produit. Les participants restent bloqués sur le tableau de bord vide ? C'est une checklist. Personne n'a trouvé la fonctionnalité qui apporte la valeur ? C'est une visite produit déclenchée à la première arrivée. Tout le monde a posé la même question à l'étape trois ? C'est une ligne de microcopie.
Comme il s'agit de configuration et non de code, vous pouvez corriger le lundi et tester à nouveau le jeudi, et c'est ce qui fait de l'onboarding le parcours où le test d'utilisabilité porte ses fruits le plus vite. Les analytics produit de Kompassify vous indiquent ensuite si la correction a fait bouger l'entonnoir pour tout le monde, pas seulement pour vos cinq participants.
Un script de test d'utilisabilité à copier
Adaptez les parties entre crochets. Gardez la structure, et gardez l'introduction identique d'une session à l'autre : c'est cette constance qui rend cinq sessions comparables.
Introduction (2 minutes)
- « Merci d'avoir pris le temps. Cela devrait durer environ [30] minutes. »
- « Nous testons le produit, pas vous. Il n'y a pas de mauvaise réponse ; si quelque chose est déroutant, c'est un problème de notre design. »
- « Pensez à voix haute, s'il vous plaît. Dites-moi ce que vous regardez, ce que vous attendez et ce qui vous surprend. »
- « Je vais surtout rester silencieux, pour voir comment vous l'utiliseriez seul. »
- « Est-ce que je peux enregistrer l'écran et le son ? Cela reste en interne. »
Échauffement (3 minutes)
- « Parlez-moi un peu de votre poste et de ce à quoi ressemble une semaine type. »
- « Comment gérez-vous aujourd'hui [le job auquel ce produit répond] ? »
- « Qu'est-ce qui vous a poussé à chercher autre chose ? » : la force de rejet (push), en une seule question
Tâches (20 minutes)
- Tâche 1 (première impression) : « Regardez cette page. Sans cliquer sur quoi que ce soit, dites-moi ce que fait selon vous ce produit et à qui il s'adresse. »
- Tâche 2 (le job principal) : « [Scénario réaliste]. Allez jusqu'au point où vous auriez ce dont vous avez besoin. »
- Tâche 3 (le parcours suspect) : « [L'étape précise où votre entonnoir indique que les gens abandonnent]. »
- Après chaque tâche : « Sur une échelle de 1 à 7, à quel point était-ce facile ou difficile ? » (SEQ)
Conclusion (5 minutes)
- « Quelle a été la partie la plus déroutante ? »
- « Si vous pouviez changer une seule chose, laquelle ce serait ? »
- « Auriez-vous continué si je n'avais pas été là ? À quel moment vous seriez-vous arrêté ? »
- Facultatif : le System Usability Scale en 10 items
Les erreurs courantes en test d'utilisabilité
✅ À faire
- Tester avec des personnes qui n'ont jamais vu le produit
- Rédiger les tâches comme des résultats, jamais comme des instructions
- Rester silencieux pendant les hésitations
- Enregistrer les sessions et partager les extraits, pas seulement la synthèse
- Prioriser selon la gravité et la fréquence à la fois
- Mener souvent de petites séries plutôt que rarement une grosse
- Tester à nouveau après avoir corrigé
❌ À éviter
- Tester avec des collègues, des amis ou des power users existants
- Nommer le bouton sur lequel vous voulez qu'ils cliquent
- Leur demander si le design leur « plaît »
- Secourir un participant dès qu'il marque une pause
- Publier des pourcentages calculés sur cinq personnes
- Tester sur un compte de démo rempli de jolies données d'exemple
- Laisser les constats finir leur vie dans une présentation
L'erreur qui invalide tout : orienter le participant. Cela se produit par petites touches : une tâche qui nomme l'élément de menu, un modérateur qui dit « avez-vous essayé en haut à droite ? », un hochement de tête quand quelqu'un se dirige vers la bonne réponse. Chacune paraît anodine, et ensemble elles transforment un test d'utilisabilité en démo guidée qui confirme ce que vous pensiez déjà.
Corrigez ce que révèlent vos tests d'utilisabilité sans attendre une mise en production
Kompassify vous permet d'ajouter des visites produit, des infobulles, des checklists d'onboarding et des sondages in-app exactement là où les utilisateurs bloquent, sans code et sans déploiement. Mesurez le résultat grâce aux analytics produit intégrés. Gratuit jusqu'à 100 utilisateurs actifs mensuels, conforme au RGPD et hébergé dans l'UE.
Commencer gratuitement →Questions fréquentes
Qu'est-ce qu'un test d'utilisabilité ?
Le test d'utilisabilité est une méthode de recherche dans laquelle de vrais utilisateurs tentent d'accomplir des tâches réalistes dans un produit pendant qu'un observateur note où ils réussissent, hésitent ou échouent. L'objectif n'est pas de demander aux gens si l'interface leur plaît, mais d'observer ce qui se passe réellement quand ils essaient de s'en servir. Le test d'utilisabilité mesure la facilité avec laquelle une tâche précise peut être accomplie, et il fait apparaître de façon fiable des problèmes que les équipes internes ne voient pas, parce qu'elles savent déjà comment le produit fonctionne.
Combien d'utilisateurs faut-il pour un test d'utilisabilité ?
Cinq participants par groupe d'utilisateurs est le chiffre de travail de référence, issu du constat de Jakob Nielsen selon lequel cinq utilisateurs découvrent en général environ 85 % des problèmes d'utilisabilité d'un parcours donné. Cinq convient aux tests qualitatifs, destinés à trouver des problèmes. Si vous avez besoin de chiffres statistiquement fiables, par exemple un taux de réussite des tâches que vous comptez publier ou comparer dans le temps, il en faut nettement plus, généralement 20 ou davantage par groupe. Si vous servez des segments réellement distincts, faites cinq participants par segment plutôt que cinq au total.
Quelle est la différence entre test d'utilisabilité et A/B testing ?
Le test d'utilisabilité vous dit pourquoi quelque chose échoue ; l'A/B testing vous dit quelle version gagne. Le test d'utilisabilité est qualitatif, se fait avec une poignée de participants et produit des explications et des causes observées. L'A/B testing est quantitatif, exige un trafic réel important et produit un résultat statistiquement comparable, sans aucune explication. Les deux fonctionnent mieux l'un après l'autre : un test d'utilisabilité pour découvrir le problème et concevoir une correction crédible, puis un A/B test de cette correction à grande échelle.
Quelles sont les principales métriques d'un test d'utilisabilité ?
Les plus utiles sont le taux de réussite des tâches (la part des participants qui terminent la tâche sans aide), le temps passé sur la tâche, le taux d'erreur, le nombre d'aides nécessaires, le score de la Single Ease Question recueilli juste après chaque tâche et le System Usability Scale recueilli à la fin de la session. Le taux de réussite et les points de friction observés pèsent le plus dans les petites études qualitatives ; les scores des questionnaires deviennent surtout parlants quand vous les comparez d'une série à l'autre.
Quelle est la différence entre test d'utilisabilité modéré et non modéré ?
Dans un test modéré, un chercheur est présent, sur place ou à distance, et peut poser des questions de relance quand un participant hésite. Il apporte des enseignements plus riches et convient le mieux aux parcours complexes et aux premiers prototypes. Dans un test non modéré, les participants réalisent les tâches seuls pendant que leur écran est enregistré. C'est moins cher, plus rapide et plus facile à mener en volume, mais vous ne pouvez pas creuser au moment où quelqu'un se perd, si bien qu'il fonctionne surtout pour des tâches bien définies dans un produit qui marche.
Comment tester l'utilisabilité d'un parcours d'onboarding ?
Recrutez des personnes qui n'ont jamais vu le produit, car quiconque le connaît ne peut plus ressentir la confusion de la première utilisation. Commencez la session au vrai point d'entrée, en général la page d'inscription plutôt qu'un compte déjà connecté, et fixez une seule tâche formulée comme un résultat, par exemple obtenir un premier résultat abouti. N'expliquez rien. Notez où les participants s'arrêtent, ce qu'ils disent à voix haute et combien de temps prend le premier résultat utile. Bouclez ensuite la boucle dans le produit en ajoutant un guidage contextuel exactement là où les gens ont bloqué, par exemple avec les visites produit no-code de Kompassify, puis testez à nouveau.
À quelle fréquence faut-il mener des tests d'utilisabilité ?
Mieux vaut petit et continu que grand et ponctuel. Pour la plupart des équipes SaaS, un bon rythme est une courte série à chaque sprint ou tous les deux sprints, avec trois à cinq participants et un périmètre étroit centré sur ce qui vient de sortir ou va sortir. En plus, organisez une session dédiée sur tout parcours dont les analytics montrent un décrochage inexpliqué, et retestez votre inscription et votre expérience de première utilisation au moins deux fois par an ; elles dérivent à mesure que les fonctionnalités s'accumulent. Notre guide d'audit de l'onboarding explique comment structurer cette revue périodique.