MODULE No 23

Titre : Heuristiques pour une bonne IPM

But : Présenter quelques règles à ne pas sous-évaluer quand on conçoit une IPM.

Antécédents : Module 21

Corps :

1. S’adapter aux types d’utilisateurs et à leurs connaissances. On ne peut pas concevoir une IPM sans connaître les caractéristiques des utilisateurs. Ce qui, entre autres, implique de connaître leur niveau de scolarisation, le type de travaux qu’ils exécutent, la fréquence d’emploi du système, etc. Surtout il faut avoir une certaine connaissance du fonctionnement de la psychologie humaine (le domaine de la psychologie cognitive s’intéresse avec plus ou moins de succès à l’étude de la partie « soft » des humains). La tâche de concevoir une IPM pour monsieur tout le monde est certainement très différente de celle de définir une IPM pour des entomologistes experts de la vie des fourmis âgées de 12 jours ! Le plus grand danger qui guette le concepteur d’IPM est de penser que l’utilisateur est comme lui-même (il est vrai que ce danger nous guette partout et non seulement dans la conception des IPM). Ceci implique, par exemple, des touches de raccourci pour des utilisateurs experts si on ne veut pas trop les irriter, mais il ne faut pas imaginer que les utilisateurs occasionnels s’en servent.

2. Dans un produit donné l’IPM doit être cohérente (cohérence interne) : c’est-à-dire que le même type d’action doit toujours donner le même type de résultat. Ceci permet à l’utilisateur d’exploiter l’une des caractéristiques les plus belles et les plus puissantes de l’esprit humain : le raisonnement par analogie. Et… la paresse.

3. Un produit doit viser une IPM cohérente avec d’autres produits s’exécutant sur la même machine ou sur des machines différentes (cohérence externe). à ce propos on peut parler de compatibilité entre les produits. Il est clair que les normes des organismes internationaux ou celles qui existent de facto chez un constructeur sont très importantes. Comme dans toute normalisation il y a le danger de forcer tous les développements dans une certaine direction et donc de diminuer les chances d’améliorations radicales. Mais est-cela un vrai danger ?.

4. S’adapter à la tâche de l’utilisateur : c’est-à-dire lui présenter les objets qui font partie de son monde et non les objets qui ont été créés par les informaticiens et qui sont censés l’aider. Mais pour trouver les « bons » objets il faut l’observer pendant son travail, s’intéresser à ce qu’il fait, faire taire notre besoin de montrer que l’on en sait plus que lui, etc. Parfois, quand on écrit une nouvelle application, on doit faire des grands changements si la première application n’avait pas été conçue selon cette règle. Dans ce cas, il est souvent très difficile de trouver un compromis entre la « bonne » solution et les habitudes (mauvaises, d’un certain point de vue) de l’utilisateur.

5. L’utilisateur doit pouvoir passer d’une tâche à une autre très facilement. Il faut que tout s’inscrive dans un environnement dans lequel l’utilisateur se trouve « chez lui » et que s’il veut changer de tâche il ne doit pas devoir faire un grand nombre de manœuvres pour conserver l’état de son travail.

6. Il faut appliquer la règle de Miller concernant le nombre d’items retenus dans la mémoire à court terme des individus : 7 + ou - 2. Règle utile non seulement pour les IPM mais plus en générale pour la conception du logiciel (plus en général pour toute description).

7. L’utilisateur doit sentir qu’il contrôle l’application : ceci implique que le logiciel ne donne pas des ordres et ne réprimande pas l’utilisateur et que celui-ci puisse choisir ce qu’il veut faire. S’il a plusieurs champs à saisir il faut, si les règles le permettent, qu’il puisse les entrer dans l’ordre qu’il préfère. Avec le danger que l’interface devienne trop complexe ou que l’utilisateur ait trop de messages d’erreurs..

8. L’IPM doit être la plus simple possible. Ceci peut parfois être en contradiction avec l’exigence que l’utilisateur contrôle l’application.

9. Il faut permettre à l’utilisateur d’expérimenter (une manière très naturelle d’apprendre) : pour permettre cela il faut que la commande UNDO (défaire) soit toujours présente et que, si une action destructive peut être faite, des messages de confirmation très clairs soient affichés (avec l’option « non » par défaut).

10.Pour favoriser l’apprentissage en travaillant, il faut qu’une aide contextuelle soit toujours présente. L’aide devrait aussi être si bien intégrée que l’utilisateur ne devrait pas savoir s’il est dans « l’aide » ou dans la « vraie » application. Lorsque l’utilisateur est dans l’aide il doit donc pouvoir saisir des données pour l’application.

11.Les réponses de la machine doivent arriver assez vite pour ne pas irriter l’utilisateur. S’il est impossible de donner la bonne réponse dans des temps inférieurs à 1..3 secondes il faut informer l’utilisateur que le système est en train de travailler pour lui donner la réponse : avec une sablier au minimum (la lumière du disque dur qui clignote ne suffit pas !).

12.L’utilisateur ne se trompe jamais. D’une manière moins radicale : le système doit être très robuste et ne pas faire payer trop cher les erreurs. Il faut donc être très « gentil » dans la gestion des soi-disant erreurs, (causées souvent par une mauvaise conception de l’interface) et, surtout, il faut que toute catastrophe possible soit bien annoncée !

13. WYSIWYG (what you see is what you get) est très souvent nécessaire pour ne pas créer des mauvaises surprises (surtout lors de l’impression).

14.Il faut que toute entreprise travaillant d’une manière non ponctuelle avec les IPM crée des normes qui doivent s’intégrer dans les normes des constructeurs qui, à leur tour, devraient s’intégrer dans les normes internationales. Chaque individu aura aussi ses « normes » personnelles (pratiquement son style) qui doivent s’intégrer avec celles de l’entreprise.

Conséquent : Avoir quelques points de repères assez solides avant d’aborder la conception des IPM

Note 01 :