Conception des IHM
Introduction Le domaine des IHM est un domaine de science ‘ non exacte’ . Les méthodes de conception utilisées dans ce domaine sont les méthodes classiques de conception utilisées dans le génie logiciel. Pour produire des logiciels qui prennent l’utilisateur en considération, il faut : Impliquer l’utilisateur dans le processus de développement
Connaître les utilisateurs L'utilisateur constitue l'élément le plus important dans un système informatique comportant une interface. L'importance de la compréhension des utilisateurs est souvent sous-estimée. C'est pourtant un point critique car il y a souvent une différence entre les concepteurs d'un système et ses utilisateurs (en terme de formation, connaissances, habileté, attitude, point de vue, vocabulaire,…) La prise en compte des utilisateurs doit intervenir assez tôt dans la phase d'analyse d'un projet logiciel.
Connaître les utilisateurs Elle nécessite, de la part des concepteurs, des connaissances techniques qui se traduisent par : • Une bonne capacité d'écoute et de communication • La faculté de pouvoir extraire les informations importantes parmi des données peu structurées • La capacité de se mettre à la place de l'autre
Développement centré sur l’utilisateur Une bonne connaissance du comportement des utilisateurs permet de créer des logiciels qui leur sont adaptés (notion d'ergonomie). Diverses méthodologies de développement tendent à prendre en compte les utilisateurs dès la phase initiale et à les impliquer tout au long des cycles de développement du logiciel. Ces approches sont connues sous le nom de: Développement centré sur l'utilisateur ( User-Centered Design )
Développement centré sur l’utilisateur Un développement centré sur l'utilisateur (User-Centered Design) apporte plusieurs avantages : Faire communiquer toutes les personnes qui ont des bagages, forces, langages différents. Concentration sur les fonctions réellement souhaitées (évite de développer des options inutiles) Réduction des coûts liés à la formation et à la maintenance Diminution du temps d'apprentissage Exploitation plus efficace du logiciel Augmentation de la satisfaction des utilisateurs
« Cycle de vie en étoile » Développement centré sur l’utilisateur Analyse de la tâche et des besoins Implémentation Utilisateur Évaluation Prototypage Spécification des besoins Conception détaillée « Cycle de vie en étoile »
Développement centré sur l’utilisateur Dans le cycle de vie en étoile l’utilisateur est au cœur du processus de développement. L’utilisateur intervient dans toutes les phases: Analyse, Conception, Évaluation… L’ingénieur et la direction ne sont plus les seuls concepteurs
Les étapes de la méthode centrée utilisateur On commence généralement par : L'analyse de la tâche (comment elle se fait) L'analyse de la situation de travail (dans quelles conditions) La conception Le prototypage L’implémentation L‘évaluation
1) Analyse de la tâche L'analyse de la tâche a pour but de recueillir des informations sur la manière dont les utilisateurs effectuent l'activité pour laquelle le logiciel est développé. On procède généralement en deux étapes : • Des interviews permettent d'identifier la tâche prévue : ce qui doit être fait • L'observation ensuite des utilisateurs sur le lieu de travail de manière à déterminer l'activité effectivement réalisée (manuellement ou ancien logiciel) On établira ensuite un modèle de la tâche qui comportera notamment : • Les buts des utilisateurs et la manière de les atteindre • Les informations nécessaires pour accomplir la tâche • Le traitement des cas exceptionnels L'analyse de la tâche servira à structurer l'interface homme-machine : • Découpage en fenêtres • Organisation des menus • Informations à afficher dans les fenêtres
2) L’analyse de la situation L'analyse de la situation consiste à connaître le contexte dans lequel les utilisateurs vont se servir du logiciel. On procède généralement par observation, interview ou questionnaire dans le contexte d'utilisation (sur le lieu de travail). Les informations recueillies permettent d'ajuster le logiciel à la population ciblée. On déterminera notamment : • Les connaissances informatiques des utilisateurs • Leurs connaissances du domaine applicatif • L'environnement général d'utilisation (éclairage, bruit, …) • Fréquence et durée d'utilisation du logiciel Ces éléments seront importants pour déterminer : • Le type de guidage que devra offrir le logiciel • Le mode de dialogue le mieux adapté
Techniques d’observation Interviewer l’utilisateur dans son bureau Lui demander de se souvenir d’un problème particulier Donner une limite de temps Demander à l’utilisateur de décrire chaque incident en détail Attention Pas de question générale, pas de question de conception
Type d'utilisateurs • des utilisateurs intermédiaires Si une interface est destinée à être utilisée par une importante population d'utilisateurs ( sites web, des logiciels freeware, etc.), il y aura une grande diversité dans le niveau des utilisateurs. On va trouver : • des utilisateurs débutants (novices) • des utilisateurs intermédiaires • des utilisateurs expérimentés Conclusion : Il y a toujours une large population d'utilisateurs Intermédiaires sur lesquels on concentrera l'effort principal lors de la conception d'une interface.
Développeur ≠ Utilisateur En tant que développeur d'une application ou d'un site web, il y a un point essentiel à garder à l'esprit : Vous n'êtes pas l’utilisateur ! Il faut impérativement optimiser la conception des interfaces en prenant en compte des utilisateurs externes et non pas se baser sur des utilisateurs impliqués - d'une manière ou d'une autre - dans le cycle de développement du projet. La solution pour éviter de tomber dans ce genre de problèmes consiste à: Créer des prototypes (dès les premières phases de la conception) Organiser des tests d'utilisabilité en choisissant correctement les utilisateurs.
3) Scénario de conception Créer une description réaliste de l’utilisation du nouveau système Procédure : Prendre un scénario de travail existant Utiliser les idées générées pendant les questionnaires Modifier le scénario de travail pour inclure le nouveau système en cours de conception Faire un scénario avec texte et images
4 ) Le prototypage Un Prototype Diffère du produit final par le processus de conception Offre toutes les fonctionnalités mais ne sont pas mises en œuvre réellement (on voit la statique de l'interface mais pas la dynamique)
4 ) Le prototypage Procédure: Produire un prototype testable d’une nouvelle interface Procédure: Utiliser le scénario de conception Créer les « propositions » Exécuter un scénario et essayer des variantes
5) Évaluation Procédure : Déterminer le meilleur choix de conception qualitativement Procédure : Voir chaque prototype Le présentateur déroule le scénario Présenter les écrans, Le groupe identifie autant de problèmes que possible Identifier les problèmes du point de vue de l’utilisateur Faire une comparaison entre les choix de conception
Évaluation Heuristique Méthode proposée par Nielsen et Molich (1993) établir un jugement au sujet d'une interface Procédure : inspection systématique de l'interface (ou d'un prototype) basée sur 10 règles heuristiques incitant l'évaluateur à focaliser sur des points précis de l'interface
Évaluation Heuristique H1) Interface simple et naturel H2) Utiliser le langage de l'utilisateur H3) Minimiser la charge de la mémoire de l'utilisateur H4) Uniformité H5) Feedback H6) Visibilité des moyens de sortie H7) Flexibilité H8) Messages d'erreurs de qualité H9) Prévenir les erreurs H10) Aide et documentation
Évaluation Heuristique Conduite de l'inspection heuristique Inspection menée par groupe de 3 - 5 évaluateurs Pour chaque problème d'utilisabilité, associer au moins une règle heuristique Pour chaque problème d'utilisabilité, associer un niveau de difficulté Regrouper les évaluations individuelles en une seule évaluation
Évaluation Heuristique Avantages Facile à mettre en oeuvre Tous le monde peut s'entraîner à utiliser cette méthode Rapport coût / bénéfice ! Inconvénients Résultats fortement liés à l'expérience des évaluateurs Couverture limitée à un certains nombre de problème seulement