Comme la plupart des équipes de développement, ici chez Mendix, nous appliquons Scrum pour créer nos applications. Une partie de la méthode Scrum consiste à valider le produit auprès des utilisateurs et des parties prenantes. Pourtant, cette étape est souvent négligée par de nombreuses équipes de développement malgré tous leurs efforts pour créer un produit fonctionnel. En général, les gens compliquent à l'excès les tests d'utilisabilité et les excluent donc du processus de développement, pensant à tort qu'ils ne sont pas cruciaux ou qu'ils économisent des ressources. C'est dommage, car tester votre produit (de valeur minimale) auprès des utilisateurs conduira à un meilleur résultat.

Les tests d'utilisabilité augmentent le succès de votre application

Le succès d'une application dépend de la manière dont ses utilisateurs l'utilisent. Tout problème d'utilisabilité peut avoir une influence négative sur la volonté d'utiliser votre produit et, par conséquent, sur le succès à long terme de l'application. Selon le livre « Rocket Surgery Made Easy » (Kurt, 2010), toutes les applications présentent des problèmes d'utilisabilité, des plus mineurs aux plus graves. Le problème ici est que les problèmes d'utilisabilité sont généralement négligés par le concepteur, l'équipe de développement et le propriétaire du produit, car la manière dont l'application doit être utilisée est « trop évidente » pour eux.

Les tests d'utilisabilité permettent de détecter et d'expliquer facilement les problèmes d'utilisabilité. La résolution de ces problèmes au cours du développement est essentielle pour créer une application réussie et éviter de consacrer du temps et de l'argent inutiles au développement pour les résoudre par la suite.

Pourquoi les gens ne font-ils pas de tests ?

Même si la validation du produit auprès des utilisateurs et des parties prenantes est un élément essentiel du processus Scrum, les tests d'utilisabilité sont souvent laissés de côté pour les raisons suivantes :

• État d'esprit : livrons l'application dès que possible, et nous l'ajusterons plus tard si nécessaire.
• Nous (l'équipe de développement) ne rencontrons aucun problème d'utilisation, donc tout devrait bien se passer.
• Cela nécessite une expertise et des connaissances que l’équipe de développement ne possède pas.
• Et engager un tiers pour le faire coûte trop cher.

On pense souvent qu'un test d'utilisabilité prend plusieurs jours, voire plusieurs semaines. Face à un tel calendrier, la plupart des gens préfèrent consacrer des ressources à la création de nouvelles fonctionnalités plutôt qu'à tester et à peaufiner des éléments qui nous semblent évidents. 

Une méthode de test d'utilisabilité créée pour vous

Sachant à quel point les tests d'utilisabilité peuvent avoir un impact, notre équipe de conception a établi une méthode de test Mendix produits que nos fabricants pourraient intégrer à leur processus. Après avoir expérimenté, nous avons trouvé un moyen simple, rapide et peu coûteux de tester Mendix applications. L'approche que nous avons conçue s'inspire du livre « Rocket Surgery Made Easy » (Kurt, 2010) et donne aux développeurs, aux concepteurs et aux propriétaires de produits des informations précieuses sur la façon dont l'application est utilisée et sur la façon dont elle peut être améliorée

Au cours de ce processus, vous découvrirez toujours des choses intéressantes auxquelles vous n'aviez jamais pensé, et la résolution des problèmes d'utilisabilité rendra véritablement l'application plus conviviale. Cette approche est également une excellente occasion d'accroître l'implication des parties prenantes en leur demandant de participer. De plus, le résultat pourrait montrer que les hypothèses utilisées lors du développement sont, en fait, invalides.

Le Mendix méthode de test d'utilisabilité

Dans l'idée de simplifier les choses, notre méthode se compose de trois étapes principales. Vous trouverez ci-dessous la liste de chaque étape, ainsi que quelques conseils pour vous aider à tirer le meilleur parti de chaque expérience de test. 

Préparez le test

• Prévoyez 3 séances – Astuce : utilisez la revue de sprint pour réaliser le test.
• Définir les scénarios utilisateurs.
• Préparez la demande dans le Mendix environnement de test.
• Effectuez un test pilote.

Faire le test

• Les observateurs doivent se mettre en sourdine, éteindre les caméras et prendre des notes.
• Désignez un animateur pour guider les participants.
• Demandez aux participants de « réfléchir à voix haute » lorsqu’ils exécutent des scénarios utilisateur.
• Utilisez les 15 dernières minutes pour poser des questions aux participants et vice versa.

Revoir le test

• Chaque observateur présente trois problèmes d’utilisabilité importants qu’il a trouvés.
• Ensemble, l’équipe définit les cinq principaux problèmes d’utilisabilité.
• Traduisez chaque problème d'utilisabilité en nouvelles histoires/tâches et ajoutez-les au backlog du projet.

Pour mieux illustrer cette méthode, examinons le test que nous avons créé pour l'application Hackathon* à titre d'exemple. L'objectif de ce test était de trouver les problèmes d'utilisabilité pour les organisateurs lors de la configuration d'un événement Hackathon dans l'application. Il convient de noter qu'il n'a fallu qu'une matinée pour effectuer le test. 

*Remarque : l'application Hackathon permet aux organisations de mettre en place et d'héberger un événement de hackathon en ligne complet où les hackers peuvent s'inscrire, télécharger et regarder les solutions et voir les gagnants. En outre, un jury peut être ajouté, qui peut évaluer les solutions et attribuer des prix. L'application Hackathon est désormais disponible en Marketplace.

Mise en place du test d'utilisabilité 

Au total, trois sessions de 60 minutes chacune ont été planifiées dans l'avant-dernier sprint du projet. Cela a permis à l'équipe de résoudre les problèmes d'utilisabilité lors du dernier sprint avant de publier l'application. Pour impliquer les parties prenantes dans la validation de l'application, nous leur avons demandé d'agir en tant que participants ou observateurs.

Une autre partie de la préparation consistait à définir les scénarios d'utilisation pour les participants. L'équipe et le propriétaire du produit ont répondu aux questions suivantes :

• De quelles choses ne sommes-nous pas sûrs ?
• Quelle est la fonctionnalité la plus importante de l’application ?

L'une des choses qui nous intéressait était de savoir comment les organisateurs avaient mis en place un nouvel événement de hackathon dans l'application. Ont-ils pu remplir le formulaire sans aucun doute ni contretemps ? Ont-ils eu le sentiment de pouvoir ajouter toutes les informations nécessaires pour un nouvel événement ? De plus, la possibilité de laisser un message aux hackers sur la page du fil d'actualité a été testée avec les participants en créant le scénario utilisateur suivant :

« Pour soutenir les hackers pendant le hackathon, vous souhaitez publier une liste de conseils. Partagez ces conseils en utilisant l'application :

Tips:

1. 1. Levez-vous et déplacez-vous pour vous sentir éveillé.
   2. Faites une sieste pour réduire la somnolence. 
   3. Offrez une pause à vos yeux pour éviter la fatigue.

Lors de la rédaction des scénarios, des instructions minimales ont été ajoutées pour laisser aux participants le soin de décider de la manière dont ils souhaitaient réaliser l'ensemble. Cette façon de procéder permettrait de tirer des enseignements plus précieux que de leur imposer une méthode stricte de réalisation.

Ensuite, l’application a été ajoutée à l’environnement de test du Mendix Plateforme. Pour générer un environnement de test réaliste, des données factices d'autres événements de hackathons ont été ajoutées et des comptes utilisateurs ont été créés pour que les participants puissent accéder à l'application. Enfin, la configuration et l'environnement de test ont été vérifiés à l'aide d'un test pilote.

Après avoir effectué les dernières modifications dans la configuration, nous étions prêts à démarrer le test d'utilisabilité réel !

Réalisation du test d'utilisabilité

Au début de chaque séance, l'animateur (cette fois c'était le concepteur, mais cela peut être n'importe qui dans l'équipe) expliquait le dispositif et demandait aux participants leur permission d'enregistrer la séance pour permettre à l'équipe de vérifier les choses par la suite.

Tout au long des séances, les observateurs ont éteint leur caméra et coupé leur micro pour préserver l’interaction entre le participant et l’animateur. Une tactique encore plus efficace consisterait à les laisser observer depuis une « autre pièce » pour éviter de donner aux participants le sentiment que quelqu’un les observe (ou même les juge).

Les participants ont été invités à réfléchir à voix haute lors de l'exécution des scénarios utilisateur (la « méthode de réflexion à voix haute »). Cela a permis à l'équipe de mieux comprendre ce qui se passait que si elle avait simplement regardé. Par exemple, un participant n'a pas trouvé le bouton « Nouveau Hackathon ». Grâce à lui qui nous a « indiqué » où il pensait pouvoir trouver le bouton, l'équipe a obtenu de précieuses informations sur la manière d'améliorer l'emplacement du bouton le plus important de l'application.

Pendant que les participants parcouraient les scénarios, l’animateur n’était là que pour les guider si nécessaire. Croyez-moi, c’est lorsque quelqu’un est coincé et doit trouver sa propre solution que l’on obtient les informations les plus précieuses. Les questions des participants, de l’animateur et des observateurs ont été notées et traitées au cours des 15 dernières minutes de la session. Cette partie se prête parfaitement à la réflexion sur les « points sensibles » des participants, en particulier lorsque l’on leur pose des questions plus générales, comme : « S’il y a une chose dans l’application que vous pourriez changer, quelle serait-elle ? »

Dans cet exemple, les trois participants ont répondu à cette question de la même manière : ils amélioreraient la navigation vers la page « Fil d'actualité ». Les observateurs ont également remarqué que trouver la page était effectivement une tâche difficile pour eux.

Revoir le test d'utilisabilité

Immédiatement après les séances, une réunion de synthèse a été organisée avec les observateurs pour discuter des résultats. Au début de la réunion, chacun a sélectionné et présenté les trois problèmes d’utilisabilité les plus cruciaux qu’il avait identifiés. Après cela, l’équipe a travaillé ensemble pour déterminer les cinq problèmes d’utilisabilité les plus importants et les a classés de 1 (le plus important) à 5 (le moins important). En fonction du nombre de problèmes essentiels que vous avez identifiés, votre « top 5 » pourrait être « top 7 » ou « top 10 », etc.

L’un des problèmes majeurs que nous avons constatés était que le processus d’ajout des récompenses et des prix dans l’application n’était pas clair. Aucun des participants n’a pu le faire sans faire d’erreur. L’équipe n’a jamais remarqué que cela constituait un problème potentiel, car la manière dont cela devait être fait était trop évidente pour toutes les personnes impliquées dans la création de l’application.

À la fin de la revue, les problèmes les plus critiques ont été traduits en nouvelles histoires/tâches et ajoutés au backlog du projet. En raison des avantages de la Mendix Grâce à la plateforme, les nouvelles histoires/tâches ont été rapidement traitées par l'équipe. Tout cela a permis d'obtenir une version améliorée de l'application en moins d'un sprint (deux semaines) !

Conclusion

L’avantage des tests d’utilisabilité est que les avantages parlent d’eux-mêmes après avoir effectué plusieurs tests réussis. Non seulement vous produirez un produit plus performant, mais les équipes impliquées commenceront également à considérer les tests d’utilisabilité comme un élément essentiel du processus de développement auquel elles souhaitent participer, car elles auront un aperçu direct de la manière dont leur produit est utilisé et de la manière dont il peut être amélioré.

J'espère que vous vous sentirez encouragé à commencer à tester votre Mendix applications.

Allez le fabriquer (et le tester) !