5.8 Recherche de conception et test d’utilisabilité
Vue d’ensemble et motivation
La recherche utilisateur est la discipline d’apprendre sur les personnes pour qui vous construisez : leurs objectifs, contextes, tâches, et les obstacles qui les font trébucher. Sa valeur centrale est la réduction de risque. L’erreur la plus coûteuse en logiciel n’est pas un bogue ou une date limite manquée ; c’est de bien construire la mauvaise chose, puis de découvrir après le lancement que personne n’en avait besoin ou que personne ne pouvait l’utiliser. La recherche rachète ce risque bon marché, avant que vous n’ayez versé de l’ingénierie dans une direction qui s’avère fausse. Le chapitre 5.1 pose les fondements UX ; ce chapitre va en profondeur sur les deux moteurs qui gardent ces fondements honnêtes, la recherche générative qui vous dit quoi construire et la recherche évaluative qui vous dit si ce que vous avez construit fonctionne réellement.
Pour les grandes équipes les enjeux se multiplient. Quand de nombreuses escouades livrent dans un seul produit, chacune fait des paris sur les utilisateurs à chaque sprint, et sans une habitude de recherche partagée ces paris ne sont que des opinions portant le costume de la confiance. Un petit flux constant de preuves donne à tous la même réalité à partir de laquelle argumenter, pour que les débats se terminent par « allons regarder quelques utilisateurs » plutôt que par qui a le plus d’ancienneté ou la voix la plus forte. La recherche voyage aussi : une étude bien menée peut corriger les hypothèses d’une douzaine d’équipes à la fois, si vous la capturez et la partagez bien.
L’entreprise et l’administration publique élèvent encore la barre. Le logiciel d’entreprise a souvent des utilisateurs captifs qui ne peuvent pas partir, donc les outils inutilisables se paient en erreurs, formation, et heures perdues plutôt qu’en désabonnement que vous pouvez voir sur un tableau de bord. Les services gouvernementaux atteignent le public entier, incluant des personnes en crise, sur d’anciens téléphones, avec une faible confiance numérique, ou sans autre option. De nombreuses normes de service numérique nationales rendent maintenant la recherche utilisateur obligatoire pour exactement cette raison, parce qu’un formulaire que personne ne peut terminer refuse aux gens des prestations auxquelles ils ont droit. Ici la recherche n’est pas une gentillesse. C’est comment vous tenez une promesse publique.
Principes clés
- La recherche réduit le risque de construire la mauvaise chose ; c’est le moins cher avant de construire, pas après.
- La recherche générative trouve le bon problème ; la recherche évaluative vérifie la solution. Vous avez besoin des deux.
- Regardez ce que les gens font, pas seulement ce qu’ils disent ; la préférence déclarée et le comportement réel divergent.
- Les méthodes qualitatives expliquent pourquoi ; les méthodes quantitatives dimensionnent combien. Associez-les.
- Petit et continu bat rare et lourd. Quelques utilisateurs chaque semaine apprennent plus qu’une grande étude par an.
- Vos découvertes ne sont représentatives que comme vos participants, donc recrutez délibérément, incluant des utilisateurs handicapés et difficiles à atteindre.
- La perspicacité qui vit dans le jeu de diapositives d’une équipe est perdue. Capturez la recherche pour que l’organisation entière puisse la réutiliser.
- Le biais s’infiltre par des questions orientées et une synthèse complaisante ; concevez contre cela délibérément.
Recommandations
Séparer la recherche générative de la recherche évaluative
Soyez explicite sur quelle question vous posez, parce que les méthodes diffèrent. La recherche générative (ou de découverte) est ouverte et explore un espace de problème avant que vous n’ayez une solution : qu’est-ce que les gens essaient réellement d’accomplir ? Où l’expérience actuelle fait-elle mal ? Que contournent-ils ? La recherche évaluative teste une conception spécifique contre une tâche : les gens peuvent-ils la terminer, et où trébuchent-ils ? Confondre les deux gaspille les deux. Exécuter une session de test d’utilisabilité rigoureusement scriptée quand vous ne comprenez pas encore le problème vous donne des réponses polies à la mauvaise question, tandis qu’une discussion non structurée quand vous devez valider un flux de paiement vous laisse deviner. Nommez d’abord la question de recherche, puis choisissez la méthode, et injectez les découvertes génératives dans la découverte produit (chapitre 10.14) où la feuille de route est réellement façonnée.
Assortir la méthode à la question
Il n’y a pas de méthode universelle, seulement des ajustements. Les entretiens utilisateur font émerger les motivations, modèles mentaux, et l’histoire, et sont votre cheval de trait pour la découverte. L’enquête contextuelle, où vous observez les gens faire du vrai travail dans leur propre environnement, révèle les contournements et interruptions que les gens ne mentionnent jamais dans une salle de conférence. Les enquêtes mesurent les attitudes et fréquences à travers une grande population mais ne peuvent pas expliquer les raisons derrière elles, et elles punissent brutalement une mauvaise conception de question. Le tri de cartes et le test d’arborescence dérivent et valident l’architecture de l’information des modèles mentaux des utilisateurs : le tri de cartes demande aux gens de grouper et étiqueter des concepts, tandis que le test d’arborescence vérifie s’ils peuvent trouver des choses dans une structure proposée. Les études de journal capturent le comportement qui se déploie sur des jours ou semaines, tel que l’intégration ou la formation d’habitude, que ne peut voir aucune session unique. Une heuristique simple : utilisez les entretiens et l’enquête contextuelle pour comprendre les gens, le tri de cartes et le test d’arborescence pour structurer l’information, les enquêtes et études de journal pour voir à travers le temps et l’échelle, et le test d’utilisabilité pour vérifier une conception.
Exécuter des tests d’utilisabilité tôt, souvent, et petit
Le test d’utilisabilité est la méthode évaluative unique à plus haut levier, et vous pouvez le commencer avec des esquisses papier bien avant que le code n’existe. L’heuristique bien connue est qu’environ cinq utilisateurs par cycle découvrent la majorité des problèmes d’utilisabilité graves et évidents, donc vous êtes mieux servi en exécutant trois cycles de cinq à mesure que la conception évolue plutôt qu’une grande étude de quinze à la fin. Comprenez cependant les limites de l’heuristique. Cinq utilisateurs sont suffisants seulement pour un groupe homogène unique découvrant de grands problèmes ; cela ne mesure pas les taux de réussite, ne couvre pas des segments d’utilisateurs distincts (chaque groupe significativement différent a besoin de sa propre poignée), et n’attrape pas les problèmes rares mais graves. Choisissez le test modéré quand vous voulez sonder le raisonnement, vous adapter à la volée, et gérer des tâches complexes ou sensibles, et le test non modéré quand vous voulez la vitesse, le volume, la portée géographique, et un coût plus bas pour des flux simples. La plupart des équipes matures exécutent les deux : modéré pour comprendre, non modéré pour confirmer à l’échelle.
Écrire des tâches et questions qui ne suggèrent pas la réponse
Votre étude n’est fiable que dans la mesure de votre protocole, et la façon la plus rapide de la ruiner est de télégraphier la réponse que vous espérez. Donnez aux participants des objectifs réalistes, pas des instructions : dites « vous venez de déménager et devez mettre à jour votre adresse » plutôt que « cliquez sur le bouton Modifier le profil et changez votre adresse ». Demandez sur le comportement passé plutôt que les intentions futures, parce que « utiliseriez-vous ceci ? » produit de façon fiable des mensonges polis tandis que « parlez-moi de la dernière fois que vous avez fait cela » produit des faits. Évitez les questions qui supposent leur propre conclusion, et restez vigilant au biais de confirmation, la tendance humaine à remarquer et se souvenir de la preuve qui soutient ce que vous croyez déjà. Le chercheur qui a écrit la conception ne devrait pas discrètement guider les participants vers le succès, et l’équipe qui observe devrait enregistrer ce qui s’est passé avant de débattre de ce que cela signifie. Quand vous séparez la conception et communication des tâches de la conception du produit (chapitre 5.4), vous obtenez un signal plus propre.
Recruter des participants qui représentent réellement vos utilisateurs
Les découvertes héritent du biais de votre recrutement. Si vous testez toujours seulement avec des volontaires confiants, connectés, et à l’aise avec la technologie, vous livrerez quelque chose qui fonctionne magnifiquement pour les gens qui avaient à peine besoin d’aide et échoue pour ceux qui en avaient le plus besoin. Définissez vos segments, puis recrutez délibérément contre eux, incluant des utilisateurs handicapés qui comptent sur la technologie d’assistance (chapitre 5.3) et des groupes difficiles à atteindre tels que les personnes en crise, les personnes à faible confiance numérique, les utilisateurs plus âgés, et ceux sur des connexions lentes ou anciens appareils. Atteindre ces participants prend plus d’effort et souvent un partenariat avec des organisations communautaires, des incitations appropriées, et une logistique flexible, mais le sauter ne fait pas disparaître les utilisateurs ; cela déplace simplement la découverte vers la production, où c’est bien plus coûteux et bien plus dommageable. Filtrez soigneusement pour obtenir de vrais membres d’un segment plutôt que des testeurs professionnels qui déjouent les incitations.
Synthétiser les découvertes en décisions, pas seulement des rapports
Les observations brutes ne sont pas de la perspicacité. Le travail de synthèse est de transformer une pile de notes de session en un petit nombre de décisions sur lesquelles l’équipe peut agir. Le mappage d’affinité, regrouper les observations individuelles en thèmes (la pratique derrière le diagramme d’affinité), est le mouvement standard pour rendre les motifs visibles à travers les sessions. Pour les études riches en entretiens, une analyse thématique légère vous garde honnête sur quels thèmes sont réellement soutenus par les données. Faites remonter les motifs durables dans les modèles partagés du chapitre 5.1, personas fondés sur des preuves et cartes de parcours, pour que la perspicacité se compose au lieu de s’évaporer. Le test d’une bonne synthèse est simple : une décision a-t-elle changé ? Une étude qui produit un beau jeu de diapositives et aucun élément de feuille de route altéré était du théâtre. Terminez chaque étude avec une courte liste classée de découvertes et une action recommandée pour chacune.
Trianguler la recherche qualitative avec l’analytique et l’expérimentation
La recherche qualitative et les données quantitatives répondent à des moitiés différentes de la même question, et chacune couvre l’angle mort de l’autre. La recherche explique pourquoi les utilisateurs se comportent comme ils le font mais ne voit que la poignée de personnes dans la pièce ; l’analytique et l’expérimentation (chapitre 7.4) voient la population entière mais ne peuvent pas expliquer la motivation ou attraper les problèmes de personnes qui ne sont jamais devenues utilisateurs. Utilisez-les comme une boucle : l’analytique montre un décrochage, la recherche l’explique, une refonte l’adresse, et une expérience mesure si la correction a déplacé le chiffre. Quand les signaux qualitatifs et quantitatifs sont en désaccord, traitez la contradiction comme un indice plutôt qu’une nuisance, parce qu’habituellement l’un d’eux mesure quelque chose que vous ne réalisiez pas mesurer. Aucune source n’est le patron de l’autre ; la décision vient de les lire ensemble.
Construire des opérations de recherche pour que la recherche s’échelle
Dès que plus de deux équipes font de la recherche, le goulot d’étranglement cesse d’être la méthode et devient la logistique : recrutement, planification, consentement, incitations, stockage de notes, et trouver l’étude du trimestre dernier avant que quelqu’un ne la relance. Les opérations de recherche (ResearchOps) sont la pratique de rendre cette machinerie fiable. Investissez dans un dépôt de perspicacité cherchable pour que les découvertes soient étiquetées, découvrables, et réutilisables à travers les équipes ; un système de gestion de participant qui respecte le consentement, la confidentialité, et la fréquence à laquelle vous contactez les gens ; et une cadence de recherche régulière pour que les études soient une habitude constante plutôt qu’une course précipitée. Démocratiser la recherche, laisser des non-chercheurs exécuter certaines études, vaut la peine mais seulement avec des garde-fous : modèles, formation, et revue, pour que vous échelonniez le volume d’apprentissage sans échelonner le volume de mauvais protocoles et de conclusions biaisées.
Compromis : avantages et inconvénients
| Méthode | Le mieux pour | Avantages | Inconvénients |
|---|---|---|---|
| Entretiens utilisateur | Découverte, motivations | Pourquoi profond, flexible, bon marché à démarrer | Petit N, sujet au biais d’intervieweur |
| Enquête contextuelle | Comportement du monde réel | Révèle les contournements et le contexte | Chronophage, difficile à planifier |
| Enquêtes | Attitudes à l’échelle | Grand N, quantifiable | Ne peut pas expliquer pourquoi, facile à mal écrire |
| Tri de cartes et test d’arborescence | Architecture de l’information | Ancre la structure dans les modèles mentaux | Portée étroite, exige une analyse soigneuse |
| Études de journal | Comportement dans le temps | Capture les motifs longitudinaux | Abandon élevé, effort de participant |
| Test d’utilisabilité modéré | Comprendre une conception | Sondage, adaptatif, riche | Plus lent, plus coûteux, lourd en planification |
| Test d’utilisabilité non modéré | Confirmer à l’échelle | Rapide, bon marché, largement géographique | Aucun suivi, superficiel sur des tâches complexes |
La tension centrale est la profondeur contre l’échelle, et la résolution est le séquencement plutôt que le choix. Utilisez des méthodes profondes, qualitatives, à petit N pour comprendre et générer des hypothèses, puis utilisez des méthodes larges et quantitatives pour les dimensionner et les confirmer. Une deuxième tension est la vitesse contre la rigueur : la recherche légère continue garde l’équipe apprenant chaque semaine, mais la même vitesse qui la rend précieuse rend facile de couper les coins sur le recrutement et le protocole. Résolvez cela en assortissant la rigueur à la réversibilité. Dépensez un vrai soin méthodologique sur les décisions coûteuses à défaire (flux centraux, architecture de l’information, paris de plateforme) et bougez vite et lâche sur les détails que vous pouvez changer le sprint prochain.
Questions à discuter avec votre équipe
Quand nous faisons un pari produit, quelle est la plus petite recherche qui changerait notre avis, et sommes-nous prêts à l’exécuter avant de nous engager ? Les équipes aiment la recherche en principe et la sautent sous pression de délai, donc la vraie question est de savoir si la preuve a une quelconque autorité sur la feuille de route du tout. Décidez à l’avance ce qui compterait comme preuve infirmante, parce qu’une étude que vous ignorerez peu importe le résultat est un gaspillage du temps de tous et une forme de théâtre. Cela compte le plus pour les décisions coûteuses à inverser, où une semaine de découverte est triviale à côté de mois à construire la mauvaise chose. Apportez une décision actuelle et nommez, à voix haute, la découverte qui vous ferait changer de cap. Si aucune découverte ne pourrait la changer, vous ne faites pas de recherche, vous collectez du réconfort, et vous devriez soit vous engager honnêtement soit rouvrir la décision.
Les gens avec qui nous testons ressemblent-ils réellement aux gens qui utilisent le produit, spécialement ceux qui luttent le plus ? C’est confortable de recruter des volontaires confiants, connectés, et disponibles, et ce confort produit une lecture flatteuse et fausse de combien votre produit est réellement utilisable. Les utilisateurs qui ont le plus besoin que le logiciel fonctionne bien, utilisateurs handicapés, personnes en crise, personnes à faible confiance numérique, sont habituellement les plus difficiles à recruter, donc ils tombent discrètement de l’échantillon à moins que vous ne vous battiez pour eux. Tirez les démographies de participants de vos trois dernières études et posez-les à côté de votre vraie base d’utilisateurs ou vos obligations de service public. Si elles penchent vers des utilisateurs faciles à atteindre, votre confiance est mal placée, et vous devriez corriger le pipeline de recrutement, vous associer à des organisations communautaires, et ajuster les incitations avant de faire confiance à un autre cycle de découvertes.
Où vivent nos découvertes de recherche, et une autre équipe pourrait-elle les trouver et les réutiliser dans six mois ? Dans une grande organisation la même question est recherchée encore et encore parce que personne ne pouvait trouver la réponse que la première équipe avait déjà payée, ce qui est du gaspillage pur habillé en diligence. Décidez qui possède le dépôt de perspicacité, comment les études sont étiquetées et résumées, et quel est le compte-rendu minimum viable pour que capturer une découverte soit assez rapide pour que les gens le fassent réellement. Considérez ce qui arrive au consentement et à la confidentialité du participant à mesure que les découvertes sont réutilisées et partagées, parce que la réutilisation sans soin est un problème de conformité et de confiance. Apportez une décision récente et essayez de tracer la preuve derrière elle. Si vous ne pouvez pas trouver l’étude en moins de quelques minutes, votre recherche s’évapore plus vite que vous ne la produisez.
Quand nous citons la règle « environ cinq utilisateurs », combien de segments distincts ce produit sert-il réellement, et testons-nous un échantillon réel de chacun ? L’heuristique des cinq utilisateurs devient un piège quand un produit a plusieurs groupes d’utilisateurs significativement différents, parce que cinq participants d’un groupe ne vous disent rien sur les autres, pourtant le nombre est cité comme si un cycle réglait la question pour tous. Pour une grande équipe livrant dans un produit partagé, les segments se multiplient rapidement : différents rôles, régions, appareils, besoins d’accessibilité, et niveaux d’expertise, et chaque groupe significativement différent a besoin de sa propre poignée. La pression concurrente est le coût et le calendrier, puisque tester chaque segment à chaque cycle est coûteux, donc décidez quels segments portent le plus de risque, couvrez-les à chaque cycle, et faites tourner le reste. Apportez votre carte de segment réelle et les comptes de participant par segment des cycles récents, et soyez honnête sur quels groupes vous n’avez jamais observés. Dans les contextes d’entreprise et gouvernementaux, où les utilisateurs captifs et les obligations de service public signifient que le segment négligé ne peut pas simplement se désabonner, un segment non testé est une population que vous échouez silencieusement, et cette lacune appartient au plan comme couverture explicite plutôt qu’une statistique moyennée.
Qui est autorisé à exécuter une étude ici, et qu’est-ce qui empêche un enthousiaste non formé de produire du non-sens confiant à l’échelle ? Démocratiser la recherche permet à plus d’équipes d’apprendre plus vite, mais sans modèles, formation, et revue cela échelonne aussi les protocoles biaisés, les questions orientées, et la synthèse complaisante, donc le volume d’apprentissage et le volume de mauvaises conclusions augmentent ensemble. La tension est entre le débit et la confiance : bloquez tout à travers quelques chercheurs et ils deviennent le goulot d’étranglement, ouvrez les portes sans garde-fous et vous inondez l’organisation de découvertes sur lesquelles personne ne devrait agir. Décidez quels types d’étude sont sûrs à déléguer, tel qu’un test de tâche rapide non modéré, contre lesquels exigent une main formée, tel que des sujets sensibles, des participants vulnérables, ou des paris d’architecture de l’information, et apportez les modèles, l’étape de revue, et un audit honnête des études en libre-service récentes pour voir combien survivraient à l’examen. Pour une grande entreprise ou un organisme gouvernemental, ajoutez l’angle approvisionnement et confidentialité : l’outillage de recherche partagé est souvent acheté, et une plateforme en libre-service qui laisse quiconque contacter des participants sans suivi de consentement est un incident de conformité qui attend d’arriver, donc les garde-fous concernent autant la gestion licite des données que la qualité de méthode.
Quand notre analytique et nos entretiens racontent des histoires opposées sur la même fonctionnalité, comment cette équipe décide-t-elle laquelle croire ? Les signaux qualitatifs et quantitatifs répondent à des moitiés différentes d’une question, et traiter une contradiction entre eux comme une nuisance à régler par ancienneté jette l’indice le plus utile que vous ayez, parce qu’habituellement une source mesure quelque chose que vous ne réalisiez pas mesurer. Pour une grande organisation le risque est le tribalisme : une équipe de données qui ne fait confiance qu’aux tableaux de bord et une équipe de recherche qui ne fait confiance qu’aux sessions, chacune rejetant l’autre au lieu de les lire ensemble. Apportez un vrai désaccord récent, le décrochage de l’analytique posé à côté des raisons de la recherche, et parcourez la boucle de l’analytique montrant où, la recherche expliquant pourquoi, et une expérience mesurant si une correction a déplacé le chiffre. Dans les contextes d’entreprise et gouvernementaux, où une seule métrique peut piloter le financement ou un engagement public, nommez à l’avance qui arbitre quand les deux sont en désaccord et quelle preuve clôt l’argument, pour que la décision repose sur une lecture triangulée plutôt que sur quelle fonction a le défenseur le plus bruyant dans la pièce.
Regard sectoriel
Jeune pousse. Avec une poignée de personnes et aucune marge à gaspiller, traitez la recherche comme l’assurance la moins chère que vous puissiez acheter, pas une phase. Faites exécuter par un fondateur cinq sessions modérées sur des prototypes papier avant d’écrire beaucoup de code, cadrant les tâches comme des objectifs plutôt que des instructions, et laissez ce que vous observez tuer ou rediriger l’idée pendant qu’elle n’est encore que des esquisses. Sautez le dépôt et le panel ; le point entier est d’apprendre assez vite pour éviter de construire la mauvaise chose.
Petite entreprise. Vous n’avez probablement aucun chercheur dédié et un budget serré, donc appuyez-vous sur des outils de test non modéré à faible coût et des entretiens légers plutôt qu’une fonction de recherche dotée en personnel. Quand vous achetez un logiciel de test d’utilisabilité, favorisez les outils qui gèrent le recrutement et le consentement pour vous, puisque construire cette machinerie vous-même vaut rarement la peine à votre échelle. Testez les quelques flux qui vous font gagner ou perdre un client, et soyez discipliné sur l’écriture de tâches qui ne suggèrent pas la réponse, parce qu’un mauvais protocole gaspille le peu de budget que vous avez.
Grande entreprise. Avec de nombreuses escouades livrant dans des produits partagés, la contrainte est la gouvernance : un dépôt de perspicacité cherchable, un panel de participant géré avec suivi de consentement, et une cadence de recherche pour que les études soient une habitude plutôt qu’une course précipitée. Démocratisez la recherche dans des garde-fous de modèles, formation, et revue pour que le volume s’échelonne sans échelonner de mauvais protocoles, et assurez-vous que les découvertes sont étiquetées et auditables pour que deux escouades ne paient jamais deux fois pour répondre à la même question. Traitez les données de participant comme régulées : la rétention, le consentement, et la fréquence de contact ont tous besoin de politique.
Gouvernement. De nombreuses normes de service numérique national rendent la recherche utilisateur obligatoire et sujette à évaluation, donc traitez-la comme une porte qu’un service doit passer, avec des preuves. Les règles d’approvisionnement façonnent votre outillage et fournisseurs de recrutement, la transparence signifie documenter avec qui vous avez testé et ce que vous avez trouvé, et la responsabilité publique signifie recruter les utilisateurs les plus difficiles à atteindre, incluant des participants assistés-numériques et handicapés, parce qu’un service qui les exclut refuse aux gens des droits. Gardez des enregistrements clairs de consentement et méthode pour qu’un évaluateur, un auditeur, ou le public puisse voir que la recherche était réelle.
Exemples
Jeune pousse. Une jeune pousse de six personnes construisant un logiciel de dépenses pour indépendants était convaincue que la fonctionnalité tueuse était la numérisation automatisée de reçus, et avait construit une version rudimentaire. Avant d’investir davantage, deux fondateurs ont exécuté cinq sessions d’utilisabilité modérées avec de vrais indépendants utilisant des prototypes papier, cadrant les tâches comme des objectifs (« enregistrez le café que vous venez de mettre en note de frais ») plutôt que des instructions. Quatre des cinq ont complètement ignoré la numérisation et tapé les montants à la main, parce que leur vraie anxiété n’était pas la vitesse de saisie de données mais si une dépense survivrait à un audit fiscal. L’équipe a réorienté le produit autour d’une catégorisation prête pour l’audit et une piste papier claire, exécuté deux autres petits cycles à mesure qu’ils itéraient, et transformé un essai gratuit stagnant en abonnés payants, tout cela pour le coût d’une semaine d’esquisses et de conversations.
Grande entreprise. Une entreprise de logistique mondiale standardisait le logiciel d’entrepôt à travers les sites et a monté une fonction permanente d’opérations de recherche pour garder honnêtes des dizaines d’escouades produit. Ils ont construit un dépôt de perspicacité étiqueté, un panel géré de personnel d’entrepôt qui avait consenti à des sessions périodiques, et une cadence de recherche bimensuelle. Quand deux escouades ont indépendamment proposé de refondre le même flux de numérisation, une recherche dans le dépôt a fait émerger une enquête contextuelle du trimestre précédent montrant que les gants et les conditions de chambre froide, pas la mise en page d’écran, pilotaient la plupart des erreurs de numérisation. Cette découverte réutilisée unique a redirigé les deux escouades vers de plus grandes cibles tactiles et des interactions adaptées aux gants, évité une découverte dupliquée, et mesurablement réduit les erreurs de numérisation une fois livré.
Gouvernement. Un service de santé national refondant son service de prise de rendez-vous a traité la recherche utilisateur comme obligatoire sous sa norme de service numérique, pas optionnelle. Aux côtés du test d’utilisabilité modéré avec un échantillon démographiquement large, l’équipe a exécuté des sessions assistées-numériques avec des personnes qui comptent normalement sur un parent ou un assistant de bibliothèque, et recruté des participants handicapés utilisant des lecteurs d’écran et un accès par contacteur (chapitre 5.3) à travers des partenariats avec des associations caritatives. Le test a révélé que le jargon clinique dans les titres de section causait des utilisateurs plus âgés et à faible confiance à abandonner avant d’atteindre un vrai obstacle. Restructurer le contenu autour des objectifs en langage clair des patients, puis confirmer le gain avec une étude non modérée à l’échelle et une comparaison analytique en direct (chapitre 7.4), a augmenté les prises de rendez-vous en libre-service réussies et réduit la charge de centre d’appels, améliorant à la fois le coût de service et l’équité d’accès.
Argumentaire économique : motivations, retour sur investissement et coût total de possession
Le retour sur la recherche vient de trois leviers. Premièrement, le gaspillage évité : attraper une mauvaise direction pendant une semaine de découverte au lieu d’après un trimestre d’ingénierie est la plus grande économie et la plus sous-comptée, précisément parce que la construction gaspillée ne se produit jamais et donc n’apparaît jamais dans un rapport. Deuxièmement, une réussite plus haute : plus d’utilisateurs terminant des tâches précieuses, ce qui se manifeste comme conversion dans les produits grand public et comme productivité et moins d’erreurs dans les contextes d’entreprise où les utilisateurs sont captifs. Troisièmement, un coût de service plus bas : les services utilisables génèrent moins de contacts de support, moins de formation, et moins d’erreurs en aval à corriger.
Le coût total de possession doit peser le coût de faire de la recherche contre le coût de la sauter. Les coûts de la faire sont visibles et modestes : chercheurs, recrutement et incitations, outillage, un dépôt, et du temps dans le calendrier. Les coûts de la sauter sont plus grands mais dispersés à travers d’autres budgets : transactions abandonnées, tickets de support, jours de formation, refontes tardives coûteuses, lancements échoués, et, dans le secteur public, l’exclusion de citoyens et l’exposition légale et réputationnelle qui suit. Parce que ces coûts se cachent dans le support, la formation, et les opérations plutôt que dans la ligne de produit, le leadership les sous-estime régulièrement, ce qui est exactement pourquoi la recherche semble optionnelle jusqu’à ce qu’un lancement échoue.
Pour faire valoir cela, liez la recherche à des chiffres que les cadres surveillent déjà : taux de complétion et conversion, coût par transaction, volume de support, temps de formation, et taux d’erreur et de retravail. Exécutez un petit avant-après instrumenté sur un vrai flux, montrez le mouvement, et extrapolez à travers le portefeuille. Cadrez la recherche comme réduction de risque sur des décisions irréversibles, le langage qui résonne avec les parties prenantes de finance et gouvernance qui ne liront peut-être jamais un rapport d’utilisabilité mais comprennent un pari qui pourrait mal tourner.
Anti-patterns et pièges
- Théâtre de recherche : des études exécutées pour justifier une décision déjà prise, avec des découvertes discrètement ignorées quand gênantes.
- Suggérer la réponse : des tâches et questions qui télégraphient la réponse désirée, produisant des données flatteuses qui ne signifient rien.
- Synthèse à biais de confirmation : n’entendre que les observations qui correspondent au plan et écarter le reste.
- La faillace des cinq utilisateurs : traiter « environ cinq utilisateurs » comme une loi universelle, ignorant que cela suppose un segment et ne trouve que des problèmes graves, pas des taux de réussite.
- Recrutement de commodité : tester quiconque est facile à atteindre, pour que les utilisateurs handicapés et difficiles à atteindre disparaissent de l’échantillon.
- Confiance en préférence déclarée : croire « oui, j’utiliserais cela » au lieu d’observer ce que les gens font réellement.
- Cimetières de perspicacité : des découvertes enterrées dans les diapositives d’une équipe, pour que la même question soit recherchée encore et encore.
- Démocratisation sans garde-fous : laisser quiconque exécuter des études sans modèles ou revue, échelonnant des protocoles biaisés et des conclusions bancales.
- Tribalisme qualitatif contre quantitatif : choisir une source de données favorite et rejeter l’autre au lieu de trianguler.
Modèle de maturité
- Niveau 1 (Initier) : La recherche est au coup par coup ou absente, et les décisions reposent sur l’opinion et l’ancienneté. Le test d’utilisabilité, s’il se produit, est un événement ponctuel réactif avant le lancement avec quiconque est disponible, et les découvertes changent rarement quoi que ce soit.
- Niveau 2 (Développer) : Certaines équipes exécutent des tests d’utilisabilité et des entretiens occasionnels, mais le recrutement est de commodité, les protocoles sont informels, et les perspicacités vivent dans des jeux de diapositives dispersés. La pratique varie largement d’escouade à escouade, et la recherche est une phase qui est coupée sous pression de calendrier.
- Niveau 3 (Standardiser) : La recherche générative et évaluative sont documentées et exécutées continuellement à travers les équipes, alimentant la priorisation à travers un processus partagé. Le recrutement cible de vrais segments incluant des utilisateurs handicapés et difficiles à atteindre, un dépôt de perspicacité cherchable existe, la synthèse produit des décisions classées, et les opérations de recherche gèrent la cadence, les modèles, et les participants à l’échelle de l’organisation.
- Niveau 4 (Gérer) : Le programme de recherche est mesuré contre des références. Les équipes suivent la couverture de segment d’utilisateur, les taux de réussite et complétion de tâche, le temps de la perspicacité au changement livré, et l’effet en aval sur le volume de support, le temps de formation, et les taux d’erreur et de retravail, et elles fixent des seuils qui déclenchent une action quand une métrique glisse. La réutilisation de dépôt et la qualité d’étude sont surveillées, pour que les leaders puissent voir le retour que la recherche produit plutôt que le supposer.
- Niveau 5 (Orchestrer) : La recherche est une boucle continue et triangulée avec l’analytique et l’expérimentation, fermant de la perspicacité au changement livré à l’effet mesuré, et elle est intégrée à la stratégie produit et la planification de risque à travers l’organisation. La recherche démocratisée fonctionne en sécurité dans des garde-fous, les découvertes se composent et s’adaptent à mesure que le produit et ses utilisateurs changent, et la recherche façonne démontrablement la stratégie, pas seulement les écrans.
Pistes de réflexion
- Combien de découverte est « suffisant » avant de s’engager à une construction, et qui a l’autorité de dire quand vous avez assez appris ?
- Quand l’analytique et les entretiens vous racontent des histoires opposées sur la même fonctionnalité, comment l’équipe devrait-elle décider sur laquelle agir ?
- Où se trouve la ligne entre démocratiser la recherche de façon responsable et laisser l’enthousiasme non formé produire des études biaisées à l’échelle ?
- Comment mesurez-vous le retour d’une étude dont la valeur est une erreur que vous n’avez donc jamais commise et ne pouvez jamais pointer ?
- Quelle est la façon éthique de faire de la recherche avec des personnes en crise ou en circonstances vulnérables sans ajouter à leur fardeau ?
- La recherche utilisateur obligatoire, comme dans les normes de service gouvernemental, devrait-elle être une porte qui peut bloquer un lancement, et qui l’impose ?
Points clés à retenir
- La recherche existe pour réduire le risque de construire la mauvaise chose, et c’est le moins cher avant de construire.
- Séparez la recherche générative (trouver le bon problème) de la recherche évaluative (vérifier la solution) ; choisissez la méthode à partir de la question.
- « Environ cinq utilisateurs » trouve la plupart des problèmes graves dans un segment par cycle, mais ne mesure pas le succès ou ne couvre pas des groupes distincts.
- Écrivez les tâches comme des objectifs réalistes, demandez sur le comportement passé, et concevez contre les questions orientées et le biais de confirmation.
- Recrutez des participants qui représentent véritablement vos utilisateurs, incluant des personnes handicapées et difficiles à atteindre, sinon vos découvertes sont discrètement fausses.
- Synthétisez en décisions classées, pas des jeux de diapositives ; le test est de savoir si une décision a réellement changé.
- Triangulez la recherche qualitative avec l’analytique et l’expérimentation, et capturez les découvertes dans un dépôt partagé pour que l’apprentissage se compose.
Références et lectures complémentaires
- Erika Hall, Just Enough Research.
- Steve Krug, Rocket Surgery Made Easy.
- Jakob Nielsen, Usability Engineering.
- Mike Kuniavsky, Observing the User Experience.
- Steve Portigal, Interviewing Users.
- Tomer Sharon, Validating Product Ideas: Through Lean User Research.
- Hugh Beyer et Karen Holtzblatt, Contextual Design.
- Donna Spencer, Card Sorting: Designing Usable Categories.
- Kathy Baxter, Catherine Courage, et Kelly Caine, Understanding Your Users.
- Kate Towsey, Research That Scales: The Research Operations Handbook.
- Nielsen Norman Group, articles sur le test d’utilisabilité, la taille d’échantillon, et les méthodes de recherche.
- UK Government Digital Service, Service Manual : directive de recherche utilisateur.