Lors de son cycle de développement, une solution applicative sera soumise à divers tests afin de vérifier si elle satisfait des critères techniques et si elle répond aux attentes métiers. Cet article porte sur les tests d'« Utilisabilité » et de « Motivation », deux types de tests différents et parfois confondus car évaluant deux notions corrélées mais distinctes.

La relation entre Utilisabilité et Motivation

Commençons par définir ces deux notions.

• La « Motivation », c'est la volonté qu'a un individu a d'utiliser la solution. Cette volonté est générée par des besoins extérieurs à la solution (ceux auxquelles cette dernière répond). Par exemple, les utilisateurs de la plateforme de déclaration des revenus en ligne sont fortement motivés à utiliser cette solution. En effet, s'ils ne le font pas ils risquent une majoration de leur imposition. À l'inverse, imaginez que l'on propose aux clients d'un magasin d'installer une application sur leurs téléphones en échange d'une remise en caisse de 10 centimes. Ces derniers seront très peu motivés à adopter la solution.

• « L'utilisabilité » c'est l'aisance avec laquelle les individus comprennent et utilisent la solution. Par exemple, s'il suffit d'une minute pour déclarer ses impôts en ligne, alors l'utilisabilité de la solution est forte. À l'inverse, si après plusieurs minutes de navigation les utilisateurs ne parviennent pas à déclarer en ligne, alors c'est que l'utilisabilité de la solution est faible.

Ces deux notions sont strictement distinctes. En effet la Motivation est une propriété des individus liée à leurs besoins initiaux alors que l'utilisabilité est une propriété de la solution liée à la qualité de sa conception.

Examinons maintenant le graphique ci-dessous.

Ce graphique (extrait du blog d'Alexander Cowan) qui illustre le modèle comportemental de B.J. Fogg nous apprend que la Motivation et la l'Utilisabilité sont deux critères importants pour qu'un individu "passe à l'action", c'est-à-dire qu'il devienne un utilisateur de la solution. Si les deux critères ne sont pas réunis alors l'individu se placera dans la zone "d'inaction", c'est-à-dire la zone des non-utilisateurs.

Ce graphique montre également que, dans une certaine mesure, les critères de Motivation et d'Utilisabilité se compensent. Une diminution de la Motivation peut être compensée par une augmentation de l'Utilisabilité et vice-versa. Attention cependant car cette compensation n'est pas linéaire. Une légère perte chez l'un doit être compensée par une forte hausse chez l'autre. En effet, on imagine mal qu'une solution sans d'intérêt soit massivement utilisée simplement car elle serait très simple à manipuler.

Examinons maintenant comment évaluer une solution sur les critères de Motiviation et d'Utilisabilité.

Comment tester la « Motivation ?

Un test de Motivation permet de répondre à la question "Les individus désirent-ils utiliser mon application ?". Chronologiquement ce test est effectué avant le lancement d'un projet. Idéalement, en conditionnant le démarrage des projets au succès d'un test de Motivation, on réduirait le taux de projets abandonnés pour cause de manque d'intérêt du public ciblé.

Pour savoir si une solution sera adoptée par ses utilisateurs cibles avant même d'avoir été développée, on peut réaliser une expérimentation qu'on appelle un MVP Sales. Sans jargon, cela revient ici à proposer au téléchargement la solution alors qu'elle n'est pas encore développée afin de mesurer l'intérêt de public.

Le protocole est le suivant :

1. Un support de communication (landing page, email, flyer, etc.) est transmis aux utilisateurs potentiels de la future solution. Les bénéfices de la solution y sont vantés et les individus ciblés sont invités à la télécharger.
2. Une période de temps s'écoule pendant laquelle certains individus essaieront de télécharger l'application (à ce moment-là, ils seront informés que la solution n'est pas encore disponible au téléchargement).
3. À la fin de la période, la mesure du ratio [tentatives de téléchargement / nombre de personnes contactées] permet d'approximer l'adhérence de la population cible et de décider si la solution mérite d'être développée.

Comment tester l'« Utilisabilité » ?

Un test d'utilisabilité permet de répondre à la question "Avec quelle aisance les utilisateurs comprennent-ils le fonctionnement de ma solution ?". Chronologiquement, ce test arrive après le test de motiviation.

Il se déroule de la manière suivante :

1. On place un individu en face de la solution (ou du prototype).
2. On lui demande d'effectuer des tâches précises. Par exemple, dans le cas fictif où l'on développerait une application de gestion de factures, on pourrait demander à l'utilisateur d'éditer la date d'une facture enregistrée.
3. On observe l'aisance qu'a l'individu à effectuer les tâches demandées. On note les étapes où il échoue et les raisons.

Ce protocole permet d'identifier les points de friction de l'interface, c'est-à-dire les situations où l'utilisateur manque de repères pour réaliser une tâche. On peut alors corriger le design de la solution pour supprimer cette friction et améliorer l'utilisabilité.

Voici quelques exemples de problèmes d'utilisabilité qui peuvent être détectés :

• Une fonctionnalité introuvable car accessible seulement après avoir navigué sur plusieurs pages.
• Un champ de saisie de numéro de téléphone qui n'accepte que les numéros au format français (10 chiffres), ce qui empêche tous les potentiels utilisateurs étrangers de s'inscrire.
• Une interface qui ne réagit pas aux interactions de l'utilisateur, lui laissant supposer que ses actions ne sont pas prises en compte.

À retenir

• Motivation et Utilisabilité sont des caractéristiques distinctes et nécessaires à l'adoption d'une solution.
• Elles peuvent se compenser, mais faiblement.
• Elles peuvent (et doivent) être testées séparément.