Ergonomie, Tests Utilisateurs et Agilité

Posté par jc-QualityStreet le 19 juin 2007

Toujours dans la lignée de l’Ergonome Agile, le retour d’experience de Desirée Sy (d’Autodesk) sur la réalisation de tests utilisateurs dans des contextes agiles : « Adapting usability investigations for Agile User-Centered Design ».
Son « User Experience Group », habitué à travailler dans de le cadre cycles en cascade, a dû modifier son approche pour s’adapter à des cycles itératifs plus courts :

• Ajustement sur la façon de préparer et mener les tests Utilisateurs (temps, granularité, protocole, types de participants…)
• Ajustement sur le mode de présentation, de transmission et d’exploitation des résultats
• Ajustement sur la façon d’envisager le design des écrans : découpage en fonction des priorités, des risques, création progressive

Au final, des bénéfices constatés :

• Conception plus fluide, mieux réussie
• Réduction des biais dû à une mauvaise interprétation des feedbacks utilisateurs
• Mode de communication plus efficace avec les équipes
• Implémentation rapide des changements demandés suite aux tests: dans l’itération suivante et pas 2 ans plus tard !!
• Mise en place d’une démarche de tests utilisateurs tout au long du projet : pas seulement à la fin ni au début

Une interface conviviale (3/3)

Posté par jc-QualityStreet le 12 mars 2007

vers des exigences d’ergonomie…
Ceci est le dernier volet de ma série consacrée au traitement de cette exigence “L’interface doit être conviviale” avec un focus sur les exigences ergonomiques, le test I.H.M. et le test d’utilisabilité (”user testing” ou “usability testing” en anglais).

Une exigence (”ce que le système doit faire”) doit, dans sa forme, être non ambigue, mesurable et vérifiable. Dans mon précédent billet, je vous présentais la stratégie à adopter pour préciser et requalifier une exigence imprécise en d’autres types d’exigences, dont les exigences d’ergonomie. Voici donc quelques exemples d’exigences d’ergonomie, accompagnées de leur mode de vérification:

• L’application devra se conformer à la nouvelle charte graphique ABC (Test I.H.M.)
• L’interface doit prévenir l’accès de l’application par des automates (logiciels dits robots) (Test I.H.M.)
• La nature hiérarchique des informations doit être présentée aux utilisateurs (Test I.H.M. / Test d’utilisabilité)
• Le tunnel de conversion une fois entamé ne doit pas avoir plus de 15% d’abandon (Test d’utilisabilité)
• L’application devra proposer sur tous les écrans un accès permanent aux principales rubriques et aux utilitaires (Test I.H.M.)
• Le temps pour effectuer la tâche A doit être inférieur à celui sur la version précédente (Test d’utilisabilité)
• L’application devra proposer des écrans et moyens d’interaction cohérents (Test I.H.M.)
• Les utilisateurs devront donner à l’application une note de satisfaction supérieure à celle de la version existante (Test d’utilisabilité)
• 90% des utilisateurs devront réussir la tâche A sans erreur (Test d’utilisabilité)

Je distingue pour ma part (Watkins ne parle quant à lui que de “Test de convivialité” - tiens tiens “convivial”) deux modes de vérification de ces exigences: Test I.H.M. et Test d’utilisabilité. Pourquoi cette distinction ?
Disons déjà qu’on ne teste pas forcément la même chose et qu’on ne couvre pas les mêmes exigences. Ensuite, les coûts, techniques et moyens à mettre en oeuvre sont différents. Enfin le test d’utilisabilité nécessite la présence d’un ergonome pour préparer, conduire et analyser ce type de test bien particulier.

Les Tests I.H.M. ont pour but de vérifier entre autres la bonne application des régles, principes définis dans une charte d’ergonomie ou dans tout autre livrable d’ergonomie (écrans, cinématique). Plus précisément, ils vont donc vérifier la présentation visuelle (menus, paramètres d’affichage, propriètés des fenêtres, résolutions d’écran, effets de bord, position des éléments, format des tableaux, des objets…), la navigation et les interactions (par saisie, menus, claviers, déplacements dans l’écran, touches Tab, raccourcis, liens, breadcrumb, enchaînement des écrans…)
Ces tests peuvent être réalisés par un testeur (ou mieux un ergonome) sur la base d’une documentation précise.

Les tests d’utilisabilité consistent à observer en situation quasi réelle l’utilisation de l’application par des utilisateurs représentatifs. Je glisse dans cette catégorie les interviews des utilisateurs à propos du produit à concevoir ou évaluer. Plus précisément, ces tests ont pour but de valider l’acceptation, de vérifier la perception et la compréhension des contenus et fonctionnalités, des moyens de navigation, et la facilité d’utilisation. Ils cherchent aussi à vérifier le respect de certaines exigences d’ergonomie plus précises sur la base de métriques (nombre d’erreurs, temps de réalisation d’une tâche, satisfaction exprimée) relatives à la facilité d’utilisation, de compréhension ou d’apprentissage.
Ces tests doivent être menés par des ergonomes, à tout moment du cycle de vie logiciel (itératif, c’est mieux ou en cascade). Ces tests sont au coeur de la norme ISO 13407 (Conception Centrée sur l’Homme).
Le choix entre ces deux types de test sera fonction notamment de l’exigence à tester et de la stratégie de test avancée.

Qualité du logiciel, ergonomie et processus unifié

Posté par jc-QualityStreet le 12 janvier 2007

Dans l’autre sens cette fois.
La recherche de la qualité du logiciel et de la qualité des processus est mon leitmotiv depuis quelques années et sera à l’honneur sur QualityStreet. Si vous êtes devant ce blog c’est que vous percevez déjà la nécessité de tester ce que vous produisez et que le chiffre de 30% de test dans la charge globale d’un projet ne vous fera pas bondir !!
Ce que j’apprécie beaucoup dans le Processus Unifié c’est qu’il met le focus sur cette discipline et permet d’introduire facilement les concepts de validation, de vérification. Il me permet même de faire le lien avec mon activité initiale d’ergonome, que ce soit au niveau de:

• la vérification (le produit est-il bien fait ?) : cela peut être par rapport à une charte d’ergonomie, de standards…
• ou de la validation (est ce le bon produit ?) par des utilisateurs (tests utilisateurs pour les ergos.; tests d’acceptation pour les ingenieurs qualité).

Vous me voyez venir…
oui, le test peut être un point d’entrée idéal vers une démarche ergonomique. Si en plus mon équipe développe en mode UP, dans une démarche itérative, et bien je peux même faire mes tests plus tôt et avoir accés à mes utilisateurs. Voilà la boucle est bouclée, avec un peu d’efforts je m’approche sans en avoir l’air de l’ISO 13407 (conception centrée utilisateur).
OK, ça fait beaucoup de raccourcis…mais je vous promets de déveloper tout cela par la suite.