Enterprise UX - Proving Improvement through Quantified Data?
Je travaille dans une organisation où je me concentre sur l'amélioration de la convivialité des applications d'entreprise (applications RH et autres applications que les gens sont obligés d'utiliser pour terminer leur travail).
Ce que j'essaie de trouver, c'est une manière cohérente de montrer une amélioration par rapport à l'état actuel, à la fois en termes de satisfaction et de temps, qui peut être facilement converti en argent.
De plus, la mesure des améliorations de l'utilisabilité avec des mesures standard est difficile pour bon nombre de ces applications, car elles nécessitent des connaissances de domaine spécifiques pour effectuer les tâches. Par exemple, considérons une application que seuls les analystes financiers utilisent. Comment pourrais-je obtenir du bon temps, des tâches, des données sur le taux de réussite sur quelque chose qui existe déjà, où toutes les personnes avec lesquelles je testerais ont déjà les connaissances du domaine et l'expertise du système pour faire leur travail (même si c'est difficile)? Je ne peux pas simplement tirer quelqu'un et le faire tester, car le système lui-même ne fait en aucun cas partie de leur travail, et il ne le sera jamais.
Quelle approche devrais-je adopter pour montrer des améliorations quantitatives sur des applications spécifiques au domaine, où la base d'utilisateurs sait tous comment utiliser la version actuelle (et a développé la solution de contournement nécessaire pour devenir compétent), tout en tenant compte de la capacité d'apprentissage de un nouveau déploiement pour accomplir les mêmes tâches?
J'ai bien peur qu'une partie de ce que vous demandez n'existe tout simplement pas. La satisfaction est une émotion. Vous ne pouvez pas le mesurer avec précision. C'est comme dire "Fred aime Wilma 4,18 fois plus que Barny aime Betty". Je sais que cela vous faciliterait la tâche si vous pouviez simplement avoir des chiffres, mais la psychométrie ne fonctionne pas de cette façon.
Il n'y a pas non plus de raccourcis pour mesurer la satisfaction. Si vous voulez savoir comment un certain groupe d'utilisateurs réagira à un système, vous devez appliquer des mesures traditionnelles, en utilisant les vrais utilisateurs de vos participants. S'il s'avère que vous devez payer le temps des analystes financiers à leurs taux courants, votre expérience d'utilisation sera terriblement coûteuse, mais il n'y a aucun moyen de contourner cela.
Pour mesurer la satisfaction pure, il existe un certain nombre d'échelles et de mesures que vous pouvez utiliser. SUS est très populaire dans l'industrie, et il se termine par un simple score. D'autres, comme DeLone McLean, QUIS ou PSSUQ fonctionneront également, vous devrez peut-être simplement faire la moyenne des éléments séparés si vous besoin d'un nombre. Mais vous devez noter que dans la plupart de ces instruments, la précision du résultat est supérieure à leur précision - c'est-à-dire que vous vous retrouvez avec un nombre normalisé à un certain intervalle, peut-être un nombre entier s'il est normalisé entre 1 et 100, mais cela ne signifie pas que vous pouvez dire avec certitude qu'un système qui mesure à 79 est meilleur qu'un système qui mesure à 76. Aussi, si vous répétez des mesures avec différents groupes d'utilisateurs, ou avec une tâche différente, ou dans un contexte différent, les chiffres deviennent encore moins comparables. Vous pouvez mesurer les chiffres, et c'est le mieux que vous puissiez faire, mais si vous effectuez de petits changements incrémentiels uniquement, ou si votre utilisabilité globale est déjà très élevée ou encore très bas, il est peu probable que vous voyiez une belle tendance propre. Et cela ne signifie pas que vous échouez dans votre travail pour améliorer l'application, cela signifie simplement que les émotions humaines ne peuvent pas être exprimées en chiffres.
Mesurer l'efficacité et l'effectivité est plus facile, car les chiffres sont beaucoup plus comparables. Encore une fois, vous avez besoin des vrais utilisateurs et vous devez leur donner des tâches réalistes. Si vous le faites d'une autre manière, vous obtiendrez un tas de chiffres plutôt dénués de sens.
Mesurer l'apprentissage est plus difficile que mesurer la satisfaction des personnes qui connaissent déjà l'application. Vous devez trouver un groupe d'utilisateurs naïf à votre application (mais qui a déjà des modèles mentaux solides dans votre domaine, si vos utilisateurs attendus en ont), le tester, puis les former et tester à nouveau. Ensuite, vous comparez les mesures entre les deux tests. Vous devez le faire dans différentes sessions, au moins au début, avec une formation approfondie et une utilisation entre les deux. Il est logique de mesurer les progrès au sein d'une seule session si vous êtes sûr que l'application est si simple que les utilisateurs n'ont pas besoin de plus qu'une session de test d'utilisation typique pour l'apprendre, ou si vous êtes vraiment intéressé par le niveau de performance après une brève exposition, pas après une longue utilisation. Mais le second est rare avec des applications écrites pour un usage professionnel.
Grossman et al ont fait une très belle enquête sur les mesures d'apprentissage. Je suggère de lire l'intégralité de l'article, mais pour être complet, voici une liste des mesures d'apprentissage qui ont été trouvées dans la littérature:
Mesures de tâche: mesures basées sur les performances de la tâche T1. Pourcentage d'utilisateurs qui terminent une tâche de manière optimale. T2. Pourcentage d'utilisateurs qui terminent une tâche sans aucune aide. T3. Capacité à terminer la tâche de manière optimale après un certain délai. T4. Diminution des erreurs de tâche sur un certain intervalle de temps. T5. Temps jusqu'à ce que l'utilisateur termine avec succès une certaine tâche. T6. Temps jusqu'à ce que l'utilisateur termine un ensemble de tâches dans un délai. T7. Qualité du travail effectué au cours d'une tâche, telle que notée par les juges. Mesures de commande: mesures basées sur l'utilisation des commandes C1. Taux de réussite des commandes après avoir été formé. C2. Augmentation des commandes utilisées sur un certain intervalle de temps. C3. Augmentation de la complexité des commandes au cours de l'intervalle de temps. C4. Pourcentage de commandes connues de l'utilisateur. C5. Pourcentage de commandes utilisées par l'utilisateur. Mesures mentales: Mesures basées sur les processus cognitifs M1. Diminution du temps de réflexion moyen sur un certain intervalle de temps. M2. Ondes alpha vs bêta dans les modèles EEG pendant l'utilisation. M3. Modification de la taille des morceaux au fil du temps. M4. Questionnaire du modèle mental, résultats du prétest et du post-test. Mesures subjectives: mesures basées sur les commentaires des utilisateurs S1. Nombre de commentaires d'utilisateurs liés à l'apprentissage. S2. Réponses au questionnaire d'apprentissage. S3. Vingt-six déclarations Likert. Mesures de documentation: Mesures basées sur l'utilisation de la documentation D1. Diminution des commandes d'aide utilisées sur un certain intervalle de temps. D2. Temps nécessaire pour examiner la documentation jusqu'au démarrage d'une tâche. D3. Il est temps de terminer une tâche après avoir examiné la documentation. Mesures d'utilisation: mesures basées sur le changement d'utilisation U1. Comparer la "qualité d'utilisation" dans le temps. U2. Comparer "l'utilisabilité" pour les utilisateurs novices et experts. Mesures de règle: Mesures basées sur des règles spécifiques R1. Nombre de règles nécessaires pour décrire le système.
Grossman, T., Fitzmaurice, G., et Attar, R. (2009). Une enquête sur la capacité d'apprentissage des logiciels: mesures, méthodologies et lignes directrices. Dans Conférence sur les facteurs humains dans les systèmes informatiques (pp. 649–658).