Notre approche : intégrer rapidement les utilisateurs au processus de conception à l’aide de tests

La refonte d’une application métier utilisée au quotidien par des professionnels peut bouleverser leurs habitudes de travail. Ne pas impliquer ses utilisateurs actuels dans la conception de la nouvelle version d’un outil, c’est prendre le risque que cette nouvelle version ne corresponde pas à leurs attentes et qu’elle soit rejetée.

L’un de nos clients nous a sollicité pour évaluer l’expérience utilisateur de la refonte d’un de leur produit, sur laquelle nous les avons accompagnés. Les tests utilisateurs que nous avons mis en place auprès des équipes internes nous ont également permis d’obtenir leur approbation en tant qu’utilisateurs de l’outil actuel et futurs utilisateurs de la nouvelle version.

Client

Anonyme

Durée du projet

1 mois

01

Déroulé du projet

Formuler des hypothèses :  quels sont les objectifs des tests ?

La première étape d’une recherche utilisateur est la définition des hypothèses. Nous avons réalisé cette phase en équipe, en réunissant l’équipe produit et représentants métier pour répondre aux questions :

  • Qu’est-ce qu’on sait avec certitude ? Les éléments objectifs qui viennent de la data, des outils de tracking comportemental ou de la connaissance des utilisateurs. Ce que nous n’aurons pas besoin de remettre en question lors des tests.
  • Qu’est-ce qu’on pense savoir ? Nos partis pris, nos à priori sur l’interface ou sur les utilisateurs. Les points qui suscitent des débats en interne et sur lesquels nous devons trancher.
  • Qu’est-ce qu’on ne sait pas ? Tout ce sur quoi nous n’avons ni données objectives, ni visibilité, ni avis arrêté.  

Sur la base de cette matière, nous avons ensuite fait le tri entre ce qui était prioritaire et ce qui ne l’était pas. Parmis ce qu’on savait avec certitude, nous avons sélectionné les éléments qui pouvaient nous aider à rédiger le protocole, formuler le scénario et structurer les missions que les testeurs allaient devoir remplir :

  • Qui sont les utilisateurs, les gens qui vont tester l’interface
  • Quel type de travail font-ils au quotidien, quelles tâches ils réalisent dans l’outil et dans quel contexte ils l’utilisent
  • Avec quels clients et quels partenaires ils interagissent
  • Quels sont leurs besoins, leurs motivations et les problématiques qu’ils rencontrent 

Enfin, parmis ce qu’on pensait savoir et ce qu’on ne savait pas, nous avons identifié les points les plus importants à aborder durant les tests. L’attention, le  temps disponible et l’énergie des testeurs étant limitée, il était important de se concentrer sur les éléments critiques pour l’expérience de ces utilisateurs :

  • Est-ce que les parcours utilisateurs leur permettaient de réaliser leurs tâches rapidement et avec facilité, en toute autonomie ?
  • Est-ce que la navigation leur permettait de s’orienter et de trouver simplement ce qu’ils cherchaient dans l’outil ?
  • Le vocabulaire employé était-il pertinent et cohérent ? Les mots employés étaient-ils ceux qu’ils utilisaient ?

Ces différentes questions nous ont permis d’élaborer les grandes lignes du protocole de tests : le document qui centralise le contexte de la recherche utilisateur, ses objectifs, la méthode (outils, types de tests…) ainsi que les missions attribuées aux participants et les questions qui les accompagnent.

02

Définir un scénario : que doit contenir le prototype ? 

Sur la base des éléments à tester en priorité (fonctionnalités, parcours, éléments d’interface…), nous avons élaboré un scénario correspondant à l’usage quotidien de l’outil. Ce scénario tenait en une phrase, incluant : quel est le rôle du testeur, dans quelle situation utilise-t-il l’outil et quel est le but de cette utilisation. La personne qui participe au test doit alors se projeter dans ce scénario, à la manière d’un jeu de rôle. L’implication dans le scénario était facilitée du fait que les testeurs aient été choisis parmi les utilisateurs de l’application, et donc que la mise en situation correspondait à la réalité de leur travail.

Le scénario était ainsi le point de départ, à partir duquel nous avons ensuite imbriqué les différentes missions. Chacune d’entre elle contenait :

  • une tâche à effectuer en toute autonomie : il était important de ne donner aucune indication pour rester au plus proche de l’utilisation réelle
  • des questions génériques sur la tâche réalisée : difficultés rencontrées, perception globale du parcours…
  • des questions plus spécifiques : mots utilisés dans l’interface, hiérarchie de l’information, préférence entre 2 variantes d’un même écran…

Chaque mission était ainsi réalisée en entonnoir, allant du plus global (interagir avec le prototype pour atteindre un objectif) au plus spécifique (donner son ressenti sur des éléments très précis du parcours). De plus, chaque nouvelle mission reprenait le parcours là où la précédente s’arrêtait. L’ensemble du test racontait ainsi une histoire logique et crédible aux testeurs.

Cette structure de test avait un double avantage :

  • faciliter l’immersion du testeur, lui donner le sentiment d’interagir avec un outil réel dans un but précis, pour l’aider à formuler des retours pertinents 
  • définir les limites du prototype, afin qu’il permette aux testeurs de réaliser leurs missions sans se rendre compte qu’il est incomplet

Dans le cadre d’un test utilisateur sur un prototype non fonctionnel, le travail de prototypage est central : il peut nécessiter un certain temps pour lui apporter le plus de soin possible. Formaliser le scénario et les missions nous a ainsi permis de trouver un équilibre entre la profondeur apportée au prototype et sa rapidité de production.

03

Intégrer le protocole : comment bien choisir son outil de test ?

Il existe de nombreux outils pour mener des tests ou de la recherche utilisateur. Chacun a ses propres limites et avantages, et la spécificité du projet permet de choisir l’outil le plus pertinent. Pour ce projet, voici les paramètres qui nous ont aiguillé dans notre choix d’outil :

  • la nature du prototype : non fonctionnel, basé sur des wireframes. Certains outils sont plus avantageux selon que les tests sont réalisés sur ce type de proto ou sur un site déjà développé.
  • la nature du panel de testeurs : issu des équipes internes, sur des profils très techniques, qu’il aurait été compliqué de recruter via un panel externe.
  • le timing : les tests devaient être réalisés rapidement et les testeurs avaient peu de disponibilités.
  • le besoin de données chiffrées et objectives : certaines de nos hypothèses étaient chiffrées, et nous avions besoin de récolter des metrics UX issus des sessions de tests pour les évaluer.

Notre choix s’est donc porté sur Maze, un outil qui permet d’intégrer rapidement son protocole de tests et de le lier à son prototype très facilement. Il est idéal pour tester rapidement des produits et offre de nombreuses fonctionnalités :

  • définir l’écran de début, l’écran de fin et le parcours attendu pour la réalisation d’une mission
  • les “clips”, des enregistrements vidéos de l’écran du testeur lors de certaines missions
  • poser des questions de tout type : fermées, ouvertes, à échelle… 
  • inclure des méthodes de test spécifiques : tri de cartes ouvert/fermé, test des 5 secondes…
  • générer un rapport de datas complet à la fin des tests : temps moyen pour réaliser une mission, score d’utilisabilité, pourcentage d’échec à une mission…
04

Analyser les tests : comment les utilisateurs ont-ils réagi ? 

Maze génère un lien à partager aux testeurs pour qu’ils démarrent leur session de test à tout moment. Le lien reste effectif autant de temps qu’il le faut. L’utilisation de Maze nécessite donc de communiquer efficacement au lancement des tests et d’être vigilant pour relancer fréquemment les participants en attente. Il est possible de suivre l’évolution des tests à mesure que les sessions sont complétées, et Maze indique même l’indice de confiance des résultats selon le nombre de sessions enregistrées.

Sur ce projet, les réactions ont globalement été très positives, et ont permis de valider les hypothèses et donc les grands principes ergonomiques de la refonte. Là où les tests révèlent toute leur force, c’est qu’ils ont également mis la lumière sur des leviers d’amélioration de l’expérience utilisateur. Les points relevés n’étaient pas nécessairement bloquants, mais ils représentaient des points de friction dans le parcours utilisateur, pour des raisons diverses :

  • sur un des écrans affichant une liste de tâches, la visibilité de la prochaine action à effectuer (et donc l’action principale) pouvait être améliorée en la repositionnant là où les utilisateurs s’attendaient à la trouver
  • entre les 2 versions d’un même écran proposées aux testeurs, aucune n’avait suscité l’adhésion franche et unanime (chaque version avait récolté 47% des préférences), ce qui indiquait qu’aucune des 2 solution n’était satisfaisante 
  • plusieurs termes employés en barre de navigation latérale semblaient ambigus pour les testeurs

D’autres ajustements mineurs relevaient purement et simplement de l’ergonomie ou de contraintes métiers, mais ces 3 enseignements majeurs correspondaient aux habitudes, au contexte et aux modèles mentaux des utilisateurs finaux. Nous avons pu prioriser et dimensionner le travail nécessaire pour améliorer le prototype, mais surtout, les tests nous ont rassuré sur l’adhésion des futurs utilisateurs, qui se sont exprimés positivement sur le travail de refonte. 

05

Organiser la restitution : comment partager et diffuser les enseignements des tests ? 

L’ensemble des enseignements tirés de l’analyse des tests a été formalisé dans un documents qui comprenait :

  • le statut des hypothèses à l’issu des tests : validées ou invalidées
  • les constats classés et triés du plus impactant au moins impactant : niveau de criticité du constat, sources (données chiffrées, retours des testeurs, click maps, heat maps…) et recommandations
  • la synthèse des tests : les points importants à retenir
  • les prochaines étapes : améliorations à apporter pour la prochaine version du prototype

Le document a été présenté au reste de l’équipe produit, puis partagé en interne. La transmission du savoir issu des tests était très importante, afin de partager la connaissance des utilisateurs et d’évangéliser la démarche UX auprès des différentes équipes. Les bénéfices de la démarche ont amené la mise en place d’autres tests par la suite sur d’autres briques du produit.

Chiffres du projet

17

testeurs

3/3

hypothèses validées

11

constats issus des tests

1

document de synthèse des tests

1

rapport analytics des tests

La méthodologie mise en place

L’équipe

Consultant UX/Product Manager, UX designer

Les expertises

UX Design, User Research, Product Management, Gestion de projet

Les outils

Figma, InVision, Google Doc, Maze

Site web

Cas anonyme

Une conversation est plus simple que 1.000 mots