Project management: Do you test or not test ?

Aujourd’hui, les tests utilisateur s’imposent comme une étape primordiale chez les grands acteurs du web pour tout projet de site, application mobile ou outil informatique réussi. Implacables en matière de compréhension de l’utilisateur, ces tests s’articulent tout au long d’un projet.

Pour l’UX Designer, c’est une source infinie d’informations. Pourtant, ils ne sont pas généralisés dans tous les projets web.

Peur d’être mis face à l’échec ou à l’imprévu, nous cédons encore à la facilité de passer cette étape en pensant que ce serait une perte de temps et d’argent. C’est pourquoi à La Mobilery, nous proposons de vous accompagner tout au long de votre projet. Pour que votre produit ou service soit en phase avec les attentes de vos utilisateurs.

Si mon concept est parfait, pourquoi en douter ?

Prenons l’exemple d’Yves. Yves a besoin d’un site Internet pour son agence d’intérim. Il manque sérieusement de visibilité et a peu de clients. Le projet de création est en pleine phase de génération, c’est-à-dire que l’UX/UI Designer sur le projet propose des solutions de conception. Yves souhaiterait en faire valider une par les intérimaires, qui seraient les utilisateurs du site.

Yves n’a jamais procédé à des tests utilisateurs. Il se demande pourquoi le concept de site qu’il a co-construit main dans la main avec son designer pourrait comporter des failles, il en est très fier. Il lui semble parfait et correspondre à ses attentes, à celles des parties prenantes du projet, et à celle des utilisateurs qu’il connaît, car il voit des intérimaires tous les jours. Il a peur également de perdre du temps, et que cela remette à zéro toutes les réflexions des parties prenantes du projet. Son autre crainte et de devoir retrouver de nouvelles idées qui lui plairont peut-être moins, et de perdre de l’argent sur le projet.

Il choisit donc de lancer le concept du site en phase de maquettage, sans passer par les tests. Lors de la phase de maquettage, de nombreux débats ont émergé sur les maquettes, qui ont déclenché des divergences et désaccords profonds. Les maquettes ont été refaites plusieurs fois, mais une version définitive a finalement finit par émerger.

Plusieurs mois plus tard, le site est lancé. Celui-ci propose un concept unique : il demande directement à l’utilisateur à quel grand domaine de missions il souhaite postuler : BTP, tertiaire, ou industrie ?

Cette idée est brillante pour Yves. Et pourtant, c’est la désillusion : 71% des utilisateurs quittent le site au bout de 5 secondes. Comment aurait-il pu éviter cela ? 

Revenons en arrière. Yves accepte que son UX/UI Designer rencontre une dizaine d’utilisateurs. Celui-ci tire de ces tests les conclusions suivantes :

  • L’utilisateur ne veut pas qu’on lui propose de grandes catégories de missions. Il souhaite pouvoir rechercher par mot-clé et par ville
  • La fonctionnalité proposée ne correspond pas à ses attentes. Il y a un manque d’affordance qui ne lui donne pas envie de poursuivre sa navigation

Ces conclusions lui permettent de réajuster le tir avant de tout concevoir et d’économiser de l’argent et du temps. Les tests utilisateurs faisant foi et étant la ligne directrice des décisions sur les maquettes, il y a eu peu de débats internes des parties prenantes. Ils ont même permis de faire émerger un nouveau concept qui correspond plus au schéma mental de l’utilisateur.

Finalement, il ne vaut mieux pas investir dans les tests pour ne pas subir un échec à la fin du projet ? Selon cette étude, écouter les utilisateurs permettrait d’éviter 43% de chances d’échouer dans vos projets de refonte. 

D’accord, les maquettes sont terminées, maintenant on fait un premier test ?

Agathe connaît un peu la démarche UX. Elle sait que pour son application mobile de vente de pièces détachées automobile, c’est le nerf de la guerre. Mais elle préfère leur montrer le produit du travail de l’équipe terminé et vraiment qualitatif, pour être sûre que l’utilisateur adhère et ait une vision d’ensemble de leur produit.

Les maquettes du designer sont prêtes. Il devient important de procéder aux tests pour s’assurer que l’application correspondent bien à leurs attentes. Elle a peur que les rencontrer un à un prennent trop de temps, et qu’ils aient des avis trop divergents. Elle préfère faire un focus group pour qu’ils confrontent leurs avis et pour trouver une solution qui les confortera tous.

Le jour J du test est arrivé. Le projet a du retard. Il a fallu attendre plusieurs semaines avant de pouvoir tester l’application. Il faut trouver une date pour la quarantaine de participants au test et ce n’est pas simple. Il faut aussi trouver la salle adaptée. Agathe propose aux utilisateurs de réagir en live pour donner leur avis sur le design.

Le test s’éternise pendant plusieurs heures et devient alors un immense brainstorming : pourquoi ne pas proposer des fonctionnalités de troc de pièces détachées et de réparation de véhicule ? La couleur utilisée sur l’application ne plaît pas. Les utilisateurs se questionnent sur un autre modèle de navigation.

Aucun choix n’a finalement été réellement prit. Pourtant, les fonctionnalités et les nouvelles idées plaisent énormément à Agathe. Mais elle n’a plus de budget pour redessiner les maquettes. Le temps presse, car elle n’était pas préparée au fait que les maquettes ne plaisent pas. Les utilisateurs sont déçus, car certains n’ont pas pu s’exprimer tandis que d’autres sont attristés que leurs idées n’aient pas été sélectionnées. Ils ont l’impression d’avoir perdu leur temps, et ne veulent pas re-participer à d’autres tests à l’avenir.

Elle se demande alors comment elle aurait pu éviter cela. Plusieurs best practices auraient pu être appliquées dans le cas présent :

1 – Réaliser le focus group en amont de la phase de maquettage, lors de la phase d’idéation (phase où l’on produit des idées de conception). Ainsi, on a déjà un premier avis des utilisateurs, sans avoir déjà réalisé des maquettes, et on a plus de marge pour rectifier le tir.

2 – Privilégier des petits tests utilisateurs individuels courts et de façon plus fréquente lors des étapes du projet :

  • En phase de prototypage, pour simuler l’enchaînement des actions et comprendre s’il y a des failles dans les différents types de parcours.
  • En phase de maquettage, pour identifier les problèmes de forme, ou tester plusieurs alternatives du système.

3 – Prévoir des goodies ou des chèques cadeaux pour remercier les participants ! Ils ont donné un peu de temps pour venir tester son application, donc si elle veut qu’ils reviennent pour un autre test, il faut les motiver.

Vous l’aurez compris, réaliser des tests est une étape à prévoir tout au long d’un projet (du moment où on commence à générer des solutions de conception, à la fin du projet). C’est véritablement une boucle itérative qui permet de rectifier le tir. Attendre la fin du projet pour avoir plusieurs utilisateurs, c’est prendre le risque de devoir repartir de zéro.

D’ailleurs, l’auteur du livre de référence sur l’ergonomie et le testing « Don’t make me think » (« Ne me faites pas réfléchir »), Steve Krug, conseille de tester tout au long du développement d’un projet.

Top, je vais pouvoir demander un avis à mes utilisateurs !

Elise est vraiment impatiente à l’idée de commencer les premiers tests utilisateur de sa première maquette d’outil de gestion des stocks pour son magasin d’électroménager. Elle pourra enfin avoir un avis sur le fruit du travail de l’équipe projet !

Elle convie alors les utilisateurs pour des entretiens individuels de deux heures chacun, sur 2 jours. Elle décide de convier l’équipe projet à ces tests pour qu’ils puissent voir les résultats en direct, comme ça, tout le monde peut poser des questions à l’utilisateur et être convaincus quand Elise leur dira que la maquette est validée.

Le jour des tests est arrivé. Le premier participant arrive, et Elise lui demande de s’assoir autour de la table avec l’équipe projet. Elle lui montre la maquette et son fonctionnement, et lui demande son avis. Il lui répond que tout lui semble clair et compréhensible. Mais il s’interroge sérieusement sur ce choix de vert dans les boutons, car il n’aime pas le vert. Il n’aime pas non plus les images arrondies, il préfèrerait qu’elles soient carrées.

L’équipe projet défend la maquette : il y a des raisons précises pour lesquelles ces choix de couleurs et de formes ont été choisies, l’utilisateur n’a pas à remettre cela en cause. L’utilisateur se braque : après tout, il a pris de son temps personnel pour venir donner son avis, non ? 

Elise voit bien que le test s’éternise, et que tout le monde commence à s’impatienter. Elle cherche alors à faire absolument valider le fait que le parcours utilisateur est viable, et lui pose plusieurs questions rhétoriques pour l’orienter vers la compréhension du parcours.

Après les tests, personne ne sait quoi faire de toutes les remarques des utilisateurs : l’équipe projet n’est pas d’accord avec les remarques des utilisateurs. Elle pense qu’ils se trompent et ne veulent pas prendre les remarques en compte. Elise pense quant à elle qu’il faut prendre en compte toutes leurs remarques. Car l’avis des utilisateurs, c’est important. De plus, quand elle leur a expliqué le parcours, ils ont tous compris, non ? 

Si Elise avait attendu la fin du projet, elle se serait certainement aperçue que ses tests étaient biaisés : en indiquant le chemin d’accès à l’information à l’utilisateur, elle lui donne les clés pour sortir. Alors que si elle avait proposé à l’utilisateur de faire un certain nombre de tâches concrètes avec le système, elle aurait pu observer sa réaction seul face à l’outil.

De plus, en voulant valider à tout prix les maquettes pour apaiser l’équipe projet, elle fait l’erreur de se tromper d’objectif. Les tests utilisateur n’ont pas pour fonction de faire valider un travail. Mais ils ont pour fonction de découvrir des problèmes d’ergonomie rencontrés lors de l’utilisation d’un système. Tester pour valider a donc peu de sens si elle n’est pas attentive aux véritables problèmes rencontrés par les utilisateurs. Car un test sert principalement à cela !

Tout le monde a un avis. Les goûts et les couleurs, ça ne se discute pas. Ce n’est qu’en observant l’utilisateur et son comportement non-verbal qu’elle pourra obtenir et connaître sa véritable expérience. Lui expliquer l’expérience ne lui permettra pas de la vivre, il n’aura que son point de vue subjectif.

Les désaccords de l’équipe projet vis-à-vis de l’utilisateur auraient pu également être évités. Un test doit être réalisé dans les conditions les plus similaires au contexte habituel : si l’outil est sensé être utilisé lors d’un chantier. L’outil doit être testé dans des conditions les plus proches du contexte de base par exemple. Avoir l’équipe tout autour de l’utilisateur ne reproduit donc pas un contexte habituel.

De plus, avez-vous déjà remarqué comme il est gênant et stressant de se sentir épié ? Vous vous sentez jugé dans chacune de vos actions, et vous ne maîtrisez plus ce que vous faites alors qu’habituellement si. Pour cela, il faut reproduire une situation moins stressante pour l’utilisateur que celle réalisée par Elise : n’invitez pas toute l’équipe projet à participer au test ! Et expliquez bien à l’utilisateur que ce n’est pas lui qui est testé, mais bien le prototype ou la maquette.

On ne peut pas prendre en compte tous les avis des utilisateurs dans un test. Elise a fait l’erreur de prendre en compte toutes les remarques des utilisateurs et de ne pas les séparer par remarques d’ordre esthétique (qui font appel à la subjectivité de l’utilisateur) et d’ordre fonctionnel. A moins que ce soit le 10e utilisateur qui vous dit que ce vert ne convient pas. Ne prenez pas chaque avis personnel pour argent comptant ! Il faut prendre en compte les remarques qui sont faites le plus souvent.

Pour finir, le test était beaucoup trop long : réaliser un test de plus d’une heure va fatiguer l’utilisateur. En effet, si au départ l’utilisateur sera motivé et concentrer. Le testeur commencera à moins bien participer au bout d’une heure, et biaiser l’analyse. Un test qui dure entre une demi-heure et une heure est largement suffisant et donnera de meilleurs résultats.

Vous l’aurez compris. Un test qui donne des résultats est réalisé en observant l’utilisateur avant toute chose. On ne lui demande pas ici un avis sur le système, mais véritablement de l’utiliser pour en tirer ses réactions. En session de test, l’UX Designer n’intervient qu’en cas de nécessité (si l’utilisateur est bloqué depuis trop longtemps ou qu’il y a un bug). C’est uniquement pour demander à l’utilisateur d’exprimer à voix haute sa frustration, son étonnement, ses remarques, son incompréhension…

C’est une véritable erreur de penser qu’une personne non préparée à la conduite de test utilisateur (chef de projet par exemple) pourra arriver à tirer des résultats sensés d’une méthode qui, à première vue, parait abordable. En réalité cette méthode nécessite une bonne préparation, ainsi que les techniques de conduite d’entretien et d’analyse plus poussées qu’elles n’en ont l’air à première vue.

Cet article vous a plu ? N’hésitez pas à écrire un commentaire. Vous souhaitez réaliser des tests utilisateur pour votre projet avec l’aide d’un UX Designer ? N’hésitez pas à nous contacter !

Marie Romon


10 mai 2021