Les tests d'utilisabilité ont une réputation imméritée d'être coûteux et lents. Quand les gens entendent « recherche utilisateur », ils imaginent un miroir sans tain, un modérateur avec un presse-papiers, et une chronologie de deux semaines. Cette version des tests existe et a ses utilisations — mais ce n'est pas la version que la plupart des équipes produits ont besoin la plupart du temps.
La version que la plupart des équipes ont besoin est plus simple : cinq utilisateurs, un prototype Figma ou un environnement de staging, un appel vidéo, et 45 minutes par session. Bien fait, cela fait surface la majorité des sérieux problèmes d'utilisabilité avant qu'ils n'expédient. Fait de manière cohérente — même une fois par sprint — cela produit une amélioration composée dans la qualité du produit que aucune analyse post-lancement ne peut reproduire.
Voici comment le lancer à partir de zéro.
Cinq participants est le bon nombre pour la plupart des tests d'utilisabilité. La recherche de Jakob Nielsen a établi que cinq utilisateurs découvrent environ 85% des problèmes d'utilisabilité, avec des rendements décroissants après cela. Exécuter trois sessions de cinq utilisateurs à différents points du processus de conception est plus précieux que une session avec quinze.
Les critères de recrutement sont plus importants que le nombre. Un test d'utilisabilité avec cinq personnes qui correspondent étroitement à votre utilisateur cible révélera les vrais problèmes. Un test avec quinze personnes qui ne correspondent pas générera du bruit. Définissez deux ou trois critères de sélection — rôle, contexte d'utilisation, niveau de confort technologique — et tenez-vous en à eux.
L'itinéraire de recrutement le plus rapide pour la plupart des équipes consiste à envoyer un e-mail aux utilisateurs existants qui ont donné la permission de contact. Proposez un incitatif modeste — une carte-cadeau de 20 euros suffit pour une session de 45 minutes. Visez à programmer des sessions au cours de la même semaine; plus l'écart entre le recrutement et les tests, plus le taux d'annulation.
L'erreur de scénarisation la plus courante est d'écrire des tâches comme des instructions : « Cliquez sur Paramètres, puis accédez à Notifications, puis modifiez votre préférence en... » Cela indique à l'utilisateur ce qu'il faut faire, ce qui signifie que vous testez s'il peut suivre les directions, pas si l'interface est intuitive.
Écrivez plutôt des tâches comme des scénarios : « Imaginez que vous recevez trop de notifications et que vous ne souhaitez recevoir que des alertes quand quelqu'un vous mentionne directement. Montrez-moi ce que vous feriez. » Cela donne à l'utilisateur un objectif réaliste et vous permet d'observer comment il navigue réellement — y compris où il se confond.
La partie la plus difficile de la modération d'un test d'utilisabilité résiste à l'envie d'aider. Quand un utilisateur est confus, chaque instinct dit de sauter et de montrer où cliquer. Mais la confusion est les données. Un utilisateur qui lutte vous dit quelque chose ne va pas avec l'interface — et le moment où vous intervenez, vous perdez le signal.
Demandez aux utilisateurs de penser à voix haute tout au long de la session : « Alors que vous allez, dites-moi juste ce que vous regardez et ce que vous pensez. » Cela produit un flux continu de données sur leur modèle mental. Notez non seulement les erreurs mais les hésitations — un utilisateur qui s'arrête pendant trois secondes avant de cliquer sur le bon bouton a toujours révélé un problème de conception, même s'il a finalement réussi.
L'étape de synthèse est là où la plupart de la valeur est créée — et où la plupart des équipes réduisent les coins. Les notes brutes de cinq sessions ne sont pas des résultats. Ils deviennent des résultats lorsque vous débriefez en équipe, regroupez les observations par thème et attribuez des évaluations de sévérité.
Faites le débriefing le même jour que les sessions, tandis que les observations sont fraîches. Regroupez les problèmes en trois godets : critique (les utilisateurs n'ont pas pu accomplir la tâche), modéré (les utilisateurs ont accompli la tâche mais avec une difficulté importante ou une erreur) et mineur (la friction qui n'a pas empêché l'achèvement). Les problèmes critiques doivent être corrigés avant le lancement. Les problèmes modérés doivent être priorisés au prochain sprint. Les problèmes mineurs vont dans le backlog.
Écrivez les résultats sur une seule page : les trois premiers problèmes critiques, avec des preuves d'au moins deux participants chacun, et un changement de conception proposé pour chacun. Tout ce qui a besoin de plus d'espace que cela appartient à un document séparé.