Tests d’utilisabilité des applications mobiles : vos utilisateurs ont une main et la moitié de leur attention

Une femme essaie de renouveler une ordonnance. Elle tient un enfant en bas âge d’un bras, son téléphone de l’autre, le pouce tendu vers un bouton situé dans le coin supérieur, pendant que le soleil se reflète si fort sur l’écran qu’elle plisse les yeux. Elle reçoit un SMS en pleine tâche, y jette un coup d’œil, perd le fil et ferme l’application. Personne dans votre équipe n’a vu la scène, parce que personne dans votre équipe ne teste de cette façon.

C’est l’échec silencieux au cœur de la plupart des tests d’utilisabilité des applications mobiles : la méthode est empruntée telle quelle au web, où une session modérée signifie un participant assis à un bureau, sous un bon éclairage, les mains libres, qui vous accorde toute son attention pendant quarante-cinq minutes. Les tests d’utilisabilité sur ordinateur mesurent une version de votre utilisateur qui n’existe pas sur téléphone.

Comment réaliser des tests d'utilisabilité pour une application mobile ?

Les tests d’utilisabilité des applications mobiles consistent à observer de vraies personnes effectuer de vraies tâches sur l’appareil réel, dans des conditions proches de leur usage réel du produit, tout en mesurant si elles parviennent à terminer la tâche, combien de temps cela prend et à quel endroit elles bloquent. La méthode varie selon la question posée : des sessions modérées sur appareil pour le « pourquoi », des tests à distance non modérés pour le volume, des tests guérilla pour le contexte réel et des études de premier lancement pour ce moment qui ne se présente qu’une fois. Aucune méthode ne couvre à elle seule ces quatre besoins ; la plupart des échecs d’utilisabilité se logent dans l’espace qui les sépare.

Voilà pour la version courte. La version longue, c’est que les tests d’utilisabilité des applications mobiles ne sont pas une seule activité mais quatre, et que choisir la mauvaise pour la question réellement posée explique pourquoi tant d’équipes se retrouvent avec un rapport rempli de constats qui ne prédisent pas ce qui se passe après le lancement.

Pourquoi la méthode desktop ne se transpose pas au mobile

Lancez une session d’utilisabilité modérée classique et vous testez une personne qui a les deux mains libres, une connexion stable, un grand écran, personne pour lui parler et une batterie qui n’entre pas en ligne de compte. Livrez le produit sur un téléphone et cette même tâche doit désormais rivaliser avec un arrêt de bus, une notification Slack, un réseau capricieux et un pouce qui doit couvrir un écran de 6,7 pouces sans rien faire tomber.

Les chiffres confirment à quel point les gens tiennent et utilisent ces appareils différemment. Dans une étude de terrain largement citée, menée auprès de 1 333 personnes utilisant un appareil mobile dans l’espace public, le chercheur Steven Hoober a constaté que, parmi celles qui touchaient l’écran, 49 % tenaient leur téléphone d’une seule main, 36 % le calaient dans une main en tapant de l’autre, et seulement 15 % utilisaient la prise à deux mains dite « en prière » que la plupart des designers formés sur ordinateur supposent par défaut (UXmatters, “How Do Users Really Hold Mobile Devices?”). En combinant ces prises en main, Josh Clark calcule que les pouces pilotent 75 % de toutes les interactions avec un téléphone (A List Apart, “How We Hold Our Gadgets”). Si votre test d’utilisabilité consiste à tendre le téléphone au participant et à le laisser s’en servir confortablement à deux mains, assis à une table, vous avez déjà testé une posture qui ne correspond qu’à environ un de vos utilisateurs réels sur sept.

Vient ensuite l’attention. Un participant à un test sur ordinateur ne reçoit pas d’appel. Un utilisateur mobile, très souvent, si, ou bien il marche, ou il est à un onglet de consulter tout autre chose. Rien de tout cela n’est un cas limite sur mobile. C’est la norme.

Méthodes de test d'utilisabilité mobile : la matrice de sélection

Chaque méthode répond à une question différente et vous rend aveugle à un ensemble différent de problèmes. N’en utiliser qu’une seule, généralement la session modérée parce que c’est la plus familière, signifie que les trois autres questions ne trouvent jamais de réponse.

Aucune ne remplace les autres. Une session modérée qui révèle que « les utilisateurs ne comprennent pas cette icône » et une session guérilla qui révèle que « les utilisateurs n’arrivent pas à toucher cette icône en plein soleil » mettent au jour deux bugs différents avec deux correctifs différents, et un plan de test à méthode unique n’en trouve jamais qu’un seul.

Combien d'utilisateurs faut-il pour des tests d'utilisabilité des applications mobiles ?

Cinq utilisateurs par segment et par cycle reste le bon point de départ. Ce chiffre vient des recherches de Jakob Nielsen et Thomas Landauer, que le Nielsen Norman Group défend toujours : un premier cycle avec cinq participants représentatifs fait généralement ressortir environ 85 % des problèmes d’utilisabilité qu’une étude bien plus vaste détecterait, car la plupart des problèmes se répètent d’un utilisateur à l’autre au lieu d’être propres à une seule personne (NN/g, “Why You Only Need to Test with 5 Users”).

La subtilité propre au mobile tient à ce qui compte comme « un segment ». Si votre application compte des groupes d’utilisateurs sensiblement différents (un parcours destiné aux aidants et un autre aux cliniciens, une base d’utilisateurs majoritairement iOS et une autre majoritairement Android avec des appareils plus anciens), chacun d’eux a besoin de ses propres cinq participants, et non de cinq participants répartis entre tous. Quant aux tests à distance non modérés, comme ils coûtent moins cher par participant, il vaut généralement la peine d’aller au-delà de cinq, dans une fourchette de 15 à 30, afin d’obtenir une vraie diversité de tailles d’écran, de versions d’OS et de conditions réseau, plutôt que cinq personnes qui ont toutes testé sur un iPhone récent en WiFi.

Exemple de tests d'utilisabilité d'une application mobile : l'onboarding, ligne par ligne

Voici à quoi ressemble concrètement l’une de ces études, à partir d’un parcours d’onboarding composite qui reflète des schémas que QAwerk observe régulièrement chez ses clients mobiles, plutôt que d’une mission nommément identifiée.

Le parcours testé : une séquence d’onboarding de cinq écrans pour une application de création de contenu (inscription, connexion d’un compte de réseau social, choix d’un modèle de départ, réalisation d’un premier projet, arrivée sur l’écran d’enregistrement/export).

Tâches confiées aux participants : créer un compte sans texte d’aide, connecter un compte externe, produire et exporter un premier contenu en moins de trois minutes, le tout sur leur propre téléphone, à une main, en extérieur.

Métriques recueillies : taux de réalisation de la tâche par écran, temps passé sur la tâche, nombre de touchers jusqu’au premier export réussi, et endroit de l’entonnoir où chaque participant a abandonné (relevé par enregistrement d’écran, et non sur déclaration, car ce que les gens disent qu’ils feraient et ce qu’ils font réellement concordent rarement sur un parcours de cinq écrans).

Trois constats, et le correctif de chacun :

1. L’étape « connecter un compte » a perdu 40 % des testeurs, non pas parce que l’intégration était défaillante, mais parce que le bouton de confirmation se trouvait dans le coin supérieur droit, une zone hors de portée confortable du pouce à une main pour la plupart des styles de prise en main. Correctif : placer l’action principale dans le tiers inférieur de l’écran, la zone que chaque méthode de la matrice ci-dessus a signalée comme accessible sans changer de prise.
2. En plein soleil, les testeurs n’ont pas vu un lien « passer » peu contrasté, parfaitement lisible en intérieur mais qui disparaissait sous les reflets ; ils se sont donc rabattus sur le parcours manuel, plus laborieux, au lieu du raccourci. Correctif : augmenter le ratio de contraste et le tester en extérieur avant de considérer le travail comme terminé, car une revue effectuée uniquement en intérieur validera un écran défaillant.
3. Un appel téléphonique a interrompu trois sessions sur cinq, et deux de ces trois testeurs ont entièrement perdu leur progression dans l’onboarding et ont dû recommencer depuis le premier écran. Correctif : conserver l’état du formulaire en local pour qu’une interruption, qui est un comportement mobile normal et non un bug du test, ne fasse pas perdre sa progression à l’utilisateur.

Ce troisième constat est celui qu’un test de type desktop ne peut structurellement pas produire, car un participant installé devant un ordinateur dans une pièce calme n’est pas interrompu au moment voulu. Il n’apparaît que lorsque le protocole de test laisse place aux conditions réelles au lieu de chercher à les neutraliser.

Tests d'utilisabilité ou tests d'accessibilité : des questions différentes

Il est tentant de confondre les deux, puisque tous deux consistent à observer quelqu’un utiliser une application, mais ils répondent à des questions différentes, avec des critères de réussite différents. Les tests d’utilisabilité cherchent à savoir si une personne peut accomplir la tâche, et avec quelle facilité. Les tests d’accessibilité cherchent à savoir si chaque personne le peut, y compris celle qui utilise VoiceOver, TalkBack ou le contrôle de sélection, au regard d’une norme définie comme WCAG 2.2. Un écran peut réussir un test d’utilisabilité et échouer malgré tout au test d’accessibilité, et l’inverse arrive aussi. Pour le volet conformité, la checklist et le processus de test avec les technologies d’assistance, consultez le guide de QAwerk sur les tests d’accessibilité des applications mobiles.

Quand les tests d'utilisabilité des applications mobiles ne sont pas la bonne option

Toutes les versions ne justifient pas une étude complète. Une modification mineure de texte ou un correctif purement backend ne justifie pas de recruter des participants ; une revue interne de cinq minutes avec une personne qui ne connaît pas le parcours suffira à repérer les problèmes évidents. Et les tests à distance non modérés ne sont pas le bon outil lorsque vous devez comprendre pourquoi quelqu’un a échoué sur une tâche, et pas seulement constater qu’il a échoué ; cette question exige une session modérée, même si elle coûte plus cher par participant. Recourir à la méthode coûteuse pour répondre à une question que la méthode économique résout déjà est une façon courante de gaspiller un budget d’utilisabilité avant même d’arriver au parcours qui mérite réellement cet examen approfondi.

Comment QAwerk mène les tests d'utilisabilité des applications mobiles

Le processus de test d’utilisabilité de QAwerk combine hallway testing, évaluation heuristique et sessions structurées basées sur des tâches, sur de vrais appareils iOS et Android plutôt que sur des simulateurs, afin de vérifier la fluidité de la navigation, le comportement des éléments interactifs et la capacité de l’application à atteindre réellement l’objectif pour lequel l’utilisateur l’a ouverte. Sur Unfold, l’application de création de contenu qui appartient aujourd’hui à Squarespace, cette combinaison de tests fonctionnels et d’utilisabilité sur 8 appareils iOS et 12 appareils Android a permis de recenser plus de 1 000 bugs et plus de 2 800 scénarios de test avant des mises en production qui ont aidé l’application à conserver une note de 5 étoiles sur l’App Store ; l’étude de cas Unfold complète donne tous les détails.

Comme QAwerk teste à n’importe quelle étape, et pas seulement une fois un build terminé, les sessions d’utilisabilité peuvent porter sur un prototype cliquable avant qu’un seul sprint ne soit consacré à construire le mauvais parcours, ou sur une application en production pour détecter ce qui n’apparaît qu’après le lancement. Découvrez notre processus de tests d’utilisabilité complet, ou l’ensemble de nos services de test d’applications mobiles si l’utilisabilité n’est qu’un volet d’une vérification plus large avant le lancement.

Checklist des tests d'utilisabilité des applications mobiles

Qu’il s’agisse d’une étude complète avec cinq participants ou d’une rapide vérification interne, les tests d’utilisabilité des applications mobiles se résument à cinq points à vérifier avant de considérer un parcours comme terminé :

• Portée du pouce : les actions principales se situent dans les deux tiers inférieurs de l’écran, pas dans les coins supérieurs.
• Taille des zones tactiles : les éléments interactifs mesurent au moins 44x44pt (iOS) ou 48x48dp (Android), avec un réel espacement entre les cibles adjacentes, et pas seulement une marge visuelle.
• Récupération après erreur : une action qui échoue (connexion perdue, mauvais toucher, parcours interrompu) indique à l’utilisateur ce qui s’est passé et comment réessayer, sans lui faire perdre sa place.
• Résistance aux interruptions : l’état du formulaire et du parcours survit à un appel téléphonique, à une application passée en arrière-plan ou à une alerte de batterie faible.
• Utilisation à une main : la tâche principale peut être réalisée à une main, testée sur l’appareil réel, et pas seulement examinée sur une recopie de l’écran sur ordinateur.

Questions fréquentes

Comment réaliser des tests d'utilisabilité pour une application mobile ?

Recrutez des participants qui correspondent à votre base d’utilisateurs réelle, confiez-leur des tâches réalistes sur l’appareil réel (et non sur un simulateur ou une recopie d’écran sur ordinateur), et combinez au moins deux méthodes : généralement une session modérée pour le « pourquoi » et des tests guérilla ou non modérés pour les conditions réelles, car aucune méthode ne détecte à elle seule à la fois les échecs de raisonnement et ceux liés à l’environnement.

Quelles sont les méthodes de test d'utilisabilité mobile ?

Les quatre méthodes principales sont les sessions modérées sur appareil, les tests à distance non modérés avec capture de l’écran et du visage, les tests guérilla dans l’environnement réel du participant, et les études consacrées au premier lancement ou à l’onboarding. Chacune cible un type d’échec différent, et la plupart des produits mobiles en nécessitent plusieurs au cours de leur cycle de vie.

Combien d'utilisateurs faut-il pour des tests d'utilisabilité des applications mobiles ?

Cinq participants par segment d’utilisateurs et par cycle de test suffisent généralement à faire ressortir la grande majorité des problèmes d’utilisabilité lors d’un premier passage. Chaque segment d’utilisateurs distinct a besoin de ses propres cinq participants ; pour les tests à distance non modérés, il vaut généralement la peine d’en recruter entre 15 et 30 afin de couvrir appareils et conditions réseau.

Les tests d'utilisabilité des applications mobiles sont-ils la même chose que les tests d'accessibilité ?

Non. Les tests d’utilisabilité vérifient si un utilisateur type peut accomplir une tâche facilement. Les tests d’accessibilité vérifient si les utilisateurs qui s’appuient sur des technologies d’assistance peuvent tout simplement l’accomplir, au regard d’une norme comme WCAG 2.2. La plupart des programmes de QA mobile ont besoin des deux, menés séparément.

Combien de temps dure un cycle de tests d'utilisabilité d'une application mobile ?

Un cycle modéré avec cinq participants prend généralement une à deux semaines de bout en bout, recrutement, sessions et rapport de constats compris. Les cycles guérilla et non modérés vont plus vite, souvent trois à cinq jours, car la planification d’un modérateur ne fait pas partie du calendrier.