Concepts :
|
· Parler aux utilisateurs. |
· Visiter les sites du client. |
· Observer les utilisateurs au travail. |
· Enregistrer les utilisateurs au travail sur vidéo. |
· Apprendre sur l'organisation du travail. |
· Essayez-le vous-même. |
· Demander aux utilisateurs de penser tout haut en travaillant. |
· Conception participative. |
· Inclure des utilisateurs experts dans l'équipe de conception. |
· Effectuer l'analyse des tâches. |
· Utiliser des enquêtes et des questionnaires. |
· Développer des objectifs testables. |
Dans le processus Rational Unified Process (RUP), les ateliers sont utilisés à différentes étapes clés, mais doivent être complétés par les types d'activités que Gould décrit pour se faire une image précise. (Ceci en partie parce que les gens décrivent fréquemment ce qu'ils font d'une manière bien différente de la manière dont ils le font réellement. Les tâches les plus communément effectuées et les détails visiblement les moins importants, comme le placement du travail ou l'existence de "mystérieux" bouts de papier, sont souvent oubliés ou omis parce qu'ils ne font pas "officiellement" partie du processus en cours.)
Les tâches d'utilisation doivent être effectuées en parallèle et très tôt dans le développement. Les tâches doivent comprendre l'esquisse de l'interface utilisateur et les projets de guides de l'utilisateur et de l'aide en ligne. Gould a également indiqué que l'utilisabilité devrait être la responsabilité d'un groupe.
La caractéristique importante de la conception intégrée est que l'approche globale - le framework - pour une conception détaillée de l'interface utilisateur est développée et testée de manière précoce. C'est là une importante différence entre la conception centrée sur l'utilisateur et les autres techniques purement incrémentielles. Elle assure que la conception incrémentielle réalisée durant les phases ultérieures s'adapte d'une manière transparente au framework et que l'interface utilisateur est cohérente dans son apparence, sa terminologie et son concept.
Dans le RUP, ce framework peut être établi en utilisant un modèle de domaine pour assurer que toute la terminologie et tous les concepts qui apparaîtront dans l'interface utilisateur sont connus et compris dans le métier en général et par les utilisateurs en particulier. (Il y aura également des sous-ensembles du modèle de domaine qui ne sont pertinents que pour des groupes spécifiques d'utilisateurs. Une attention toute particulière doit être portée pour que le modèle de domaine soit organisé de manière à ce que ces sous-ensembles soient facilement identifiés.) Avec la progression de la conception de l'interface utilisateur, plusieurs classes de domaine seront représentées comme éléments de l'interface utilisateur. Les éléments d'interface utilisateur et leurs relations doivent être cohérents avec le modèle de domaine et doivent être représentés d'une manière homogène à travers toutes les parties du système en cours de conception. (Ceci est de nature non seulement à aider les utilisateurs, mais également à améliorer la réutilisation des composants de l'interface utilisateur.)
Des tests utilisateur précoces se traduisent par la création de scénarimages très tôt dans le processus et par le développement précoce de prototypes généraux. Des prototypes détaillés suivront ultérieurement en cours de processus.
Des Scénarimages peuvent être utilisés en conjonction avec les cas d'utilisation pour rédiger des scénarios concrets d'utilisation du système en cours de conception. Ceci peut prendre une forme narrative, narrative illustrée (en utilisant les maquettes de l'interface utilisateur pour l'illustrer), de scénarimages, de visites guidées (avec des utilisateurs), et de groupes de concentration sur l'utilisateur, qui sont des approches inhabituelles à de nombreux développeurs de logiciels. Toutefois, elles sont de toute évidence plus rentables que la découverte d'une conception inappropriée ou d'exigences mal comprises, une fois l'implémentation en cours.
Le développement orienté objet est devenu synonyme d'un processus itératif. La conception par itération est bien appropriée à des problèmes nécessitant un affinement de la compréhension et ayant des exigences changeantes. Il n'est donc pas surprenant de voir la conception par itération comme un composant essentiel de la conception centrée sur l'utilisateur. Ceci est partiellement dû aux changements des besoins des utilisateurs à travers le temps, et également à la complexité inhérente à la production de solutions de conception répondant à des besoins divers.
Notez que pour une méthode centrée sur l'utilisateur, la conception itérative se fait dans le cadre d'une structure intégrée. Nous avons délibérément évité le développement incrémentiel, en dehors d'un framework établi, et pouvant conduire à une solution "mosaïque".
Les systèmes itératifs reposent sur leur capacité à intégrer les besoins des utilisateurs pour réussir. Ceci signifie non seulement l'identification des diverses communautés d'utilisateurs, mais également la reconnaissance de l'ensemble des compétences, des expériences et des préférences des utilisateurs individuels.
Alors qu'il est tentant pour les développeurs et les responsables de penser qu'ils comprennent les besoins des utilisateurs, ceci est rarement le cas en pratique. L'attention est souvent portée sur la manière dont les utilisateurs devraient effectuer les tâches plutôt que sur la manière dont ils préfèrent les réaliser. Dans de nombreux cas, le problème de la préférence est bien plus que le simple fait de sentir la maîtrise, même si ce fait est un problème en lui-même. La préférence sera également déterminée par l'expérience, la capacité et le contexte d'utilisation. Ces questions sont considérées suffisamment importantes dans le processus de conception pour garantir la conformité à la norme internationale, [ISO 13407], processus de conception centrés sur l'homme pour les systèmes interactifs. La norme et les questions annexes à la normes sont traitées en termes généraux dans la suite de cette page.
Les utilisateurs appréhendent un système et interagissent avec lui à travers son interface utilisateur. Les concepts, les images et la terminologie présentés dans l'interface doivent être appropriés aux besoins de l'utilisateur. Par exemple, un système qui permet aux clients d'acheter leurs propres billets serait bien différent d'un système professionnel utilisé par le personnel de vente de billets. Les différences principales ne sont pas dans les exigences ou même dans les cas d'utilisation détaillés, mais dans les caractéristiques des utilisateurs et les environnements dans lesquels le système peut fonctionner.
L'interface utilisateur doit également tenir compte d'une gamme potentiellement vaste d'expérience, comportant au moins deux dimensions, celle de l'informatique et celle du domaine, comme indiqué dans la Figure 1 ci-dessous. L'expérience en informatique comprend non seulement les connaissances générales de l'ordinateur, mais également du système en cours de développement. Les utilisateurs ayant peu d'expérience soit dans l'informatique, soit dans le domaine, représentés dans le coin gauche de la figure, auront besoin d'une approche radicalement différente de l'interface utilisateur que celle des utilisateurs experts, représentés dans le coin droit.
Figure 1 : Effets de l'expérience informatique et dans le domaine sur la facilité d'apprentissage par rapport à la facilité d'utilisation
Toutefois, gardez-vous de conclure que les utilisateurs inexpérimentés deviendront experts avec le temps. Un certain nombre de facteurs peuvent se liguer contre cette issue favorable, comme la faible fréquence d'utilisation, la faible motivation ou la grande complexité. Inversement, certains systèmes peuvent avoir une prédominance d'utilisateurs experts. Les facteurs qui agissent ici peuvent être la formation, la fréquence d'utilisation élevée ou la grande motivation (dépendance professionnelle). Certains de ces points, avec leurs effets sur la conception de l'interface utilisateur, sont présentés dans le Tableau 1.
Faible |
Elevée |
|
---|---|---|
Expérience informatique |
Simple question-réponse, simple remplissage de formulaire, style d'interface Web (liens hypertexte) ou style d'interface par menus |
Remplissage de formulaires complexes, style d'interface Web (liens hypertexte) ou par menus (des questions-réponses ou des formulaires simples seraient très frustrants pour desutilisateurs expérimentés) |
Expérience dans le domaine |
Terminologie et concepts courants |
Terminologie et concepts spécifiques au domaine |
Formation |
Concentration sur la facilité d'apprentissage (cohérence, prévisibilité, mémorisation facile) |
Concentration sur la facilité d'utilisation (directe, personnalisable, non intrusive) |
Fréquence d'utilisation |
Facile à apprendre et à se rappeler, style d'interface simple |
Facile à utiliser, plusieurs raccourcis et techniques permettant le contrôle par l'utilisateur |
Motivation |
Facile à utiliser, puissant sans paraître complexe. |
Elaboré, avec plusieurs fonctionnalités avancées et personnalisables. |
Tableau 1, Quelques facteurs affectant la conception de l'interface utilisateur
Les systèmes interactifs doivent être conçus pour intégrer une gamme appropriée d'expériences utilisateur et de circonstances, ou bien des dispositions doivent être prises pour restreindre le champ de la conception. A titre d'exemple, la formation peut être utilisée pour réduire l'exigence de la facilité d'apprentissage pour un système complexe. L'autre alternative consisterait à réduire le champ du système pour qu'il réponde mieux aux exigences de base de ses utilisateurs (suggestion faite par Alan Cooper dans son livre The Inmates Are Running the Asylum [COO99]).
Dans le cadre de la conception centrée sur l'utilisateur, nous aurons besoin de considérer les compétences et les attributs physiques des utilisateurs. Ces questions sont de plus en plus incorporées dans la législation. Il s'agit surtout de faciliter l'accessibilité pour les utilisateurs handicapés. Rendre les systèmes accessibles à une large gamme d'utilisateurs est généralement bénéfique à la communauté des utilisateurs dans son ensemble.
Le tableau ci-après présente la législation et les ressources pertinentes pour plusieurs endroits du monde :
Description | Site Web |
---|---|
AUSTRALIE |
|
Disability Discrimination Act(Loi sur la discrimination à l'encontre des handicapés) | hhttp://www.hreoc.gov.au/disability_rights/dda_guide/dda_guide.htm |
Droits des handicapés | http://www.hreoc.gov.au/disability_rights/index.html |
EUROPE |
|
Forum européen des personnes handicapées | http://www.edf.unicall.be |
ROYAUME-UNI |
|
Disability Discrimination Act(Loi sur la discrimination à l'encontre des handicapés) | http://www.hmso.gov.uk/acts/acts1995/1995050.htm |
New Deal for Disabled People (Nouvelle chance pour les personnes handicapées) | http://www.disability.gov.uk |
Digital Access Campaign (Campagne d'accès à l'informatique) | http://www.rnib.org.uk/digital/welcome.htm |
NATIONS UNIES |
|
Règles standards des Nations Unies pour l'égalité des chances en faveur des personnes handicapées | http://www.un.org/esa/socdev/enable/dissre00.htm |
Informations sur le développement social sur Internet | http://www.unescap.org/esid/psis/disability/index.asp |
ETATS UNIS |
|
Americans with Disabilities Act (ADA): US Department of Justice (Loi sur les américains handicapés) : Ministère de la justice) | http://www.usdoj.gov/crt/ada/ |
Section 508 of the Workforce Investment Act: US Department of Justice (Section 508 de la loi sur l'investissement humain : Ministère de la justice) | http://www.usdoj.gov/crt/508/508home.html |
US Access Board Electronic and Information Technology Advisory Committee (EITAAC) (Comité consultatif pour la technologie de l'informatique et de l'électronique auprès du conseil américain de l'accès) | http://www.access-board.gov |
World Wide Web Consortium Web Accessibility Campaign (Campagne d'accès au Web du consortium World Wide Web) | http://www.w3.org/wai/ |
AUTRES RESSOURCES |
|
Ressources Internet relatives aux handicapés | http://www.disabilityresources.org |
Tableau 2a, Législation relative aux handicaps par pays, région ou organisme
Législation mise à part, la conception centrée sur l'utilisateur et la conception des interfaces utilisateur font de plus en plus l'objet d'une normalisation, comme indiqué ci-après.
Description | Site Web/Normes |
---|---|
ANSI |
www.ansi.org |
ANSI ANSI-HFES ANSI-NSC |
L'ANSI et l'organisme Human Factors and Ergonomics Society ont publié un certain nombre de normes communes. L'ANSI a également la norme ANSI-NSC Z365 qui se rapporte au contrôle et à la prévention des troubles liés au stress cumulé (également connus sous le nom d'atteinte par sollicitation répétitive ou RSI). L'ANSI élabore également des normes concernant l'interaction homme-machine, comme partie du panel des normes de l'infrastructure informatique(IISP). |
ISO |
www.iso.ch |
ISO 9241 | Vaste série de normes traitant essentiellement de l'ergonomie des stations de travail, mais comprenant également des lignes directrices pour l'utilisabilité (partie 11). Ces normes sont à la base des normes ANSI-HFES 200, en cours de développement. |
ISO 10075: 1991 | Principes d'ergonomie concernant le travail intellectuel |
ISO 17041-1 : 1995 | Contrôle du curseur dans l'édition de texte |
ISO 11581 | Série en cours de développement traitant des icônes et des pointeurs. |
ISO 13407 : 1999 | Normes pour les processus de conception centrée sur l'homme pour les systèmes interactifs. |
Tableau 2b, Normes ANSI et ISO concernant la conception des interfaces utilisateur et la conception centrée sur l'utilisateur
Le développement de systèmes appropriés aux besoins de l'utilisateur implique un effort important dans l'analyse des exigences. Dans la conception centrée sur l'utilisateur, cet effort est concentré sur les utilisateurs. Ils sont décrits plus en détail par la suite dans la discipline Exigences sous Acteurs.
Toutefois, le point le plus important dans la conception centrée sur l'utilisateur réside dans la compréhension des exigences des personnes réelles qui rempliront les rôles décrits dans les artefacts mentionnés ci-dessus. En particulier, il faut éviter de sombrer dans la facilité qui consiste à concevoir un système pour des personnes hypothétiques. Les artefacts décrivant les utilisateurs ne doivent être rédigés qu'après un contact approfondi et sur place avec les utilisateurs. Dans la conception centrée sur l'utilisateur, ce contact sur place constitue une partie d'un processus parfois appelé enquête contextuelle. Hugh Beyer et Karen Holtzblatt (dans leur livre intitulé Contextual Design, [BEY98]) décrivent les prémisses de l'enquête contextuelle comme étant :
"...d'aller où travaille le client, d'observer le client au travail et de parler au client au sujet du travail."
(Quelques exemples concrets ont déjà été énumérés sous Concentration sur les utilisateurs.) Cette approche est utilisée non seulement pour avoir une meilleure compréhension des exigences du système, mais également des utilisateurs eux-mêmes, de leurs tâches et de leurs environnements. Chacun a ses propres attributs et pris ensemble, ils sont désignés par le contexte d'utilisation. Ils sont détaillés dans la norme ISO relative à la conception centrée sur l'utilisateur, décrite ci-après.
La norme ISO sur les processus de conception centrée sur l'Homme pour les systèmes interactifs [ISO13407] identifie la première étape de la conception comme étant la compréhension et la spécification du contexte d'utilisation. Les attributs proposés sont :
Contexte | Attributs |
---|---|
Tâches |
Les buts de l'utilisation du système, la fréquence et la durée de performance, les considérations de santé et de sécurité, l'affectation des activités, les étapes opérationnelles entre les ressources humaines et technologiques. Les tâches ne doivent pas être décrites uniquement en termes de fonctions ou fonctionnalités offertes par un produit ou système. |
Utilisateurs (pour chaque type ou rôle différent) |
Connaissances, compétences, expérience, niveau d'études, formation, attributs physiques, habitudes, préférences, capacités. |
Environnements |
Matériel, logiciel, supports ; environnements matériel et social, normes pertinentes, environnement technique, environnement ambiant, environnement social et culturel |
Tableau 3 : Contexte d'utilisation dans la norme ISO pour la conception centrée sur l'utilisateur
Il serait utile de diviser le contexte de l'utilisateur en ses deux parties constitutives (type d'utilisateur et rôle de l'utilisateur) puis de considérer les relations entre les quatre contextes :
Figure 2 : Relations entre les contextes
La Figure 2 montre que chaque tâche est effectuée dans un rôle accompli par un utilisateur dans un environnement donné. Ces contextes correspondent aux artefacts RUP comme indiqué dans le Tableau 4.
Contexte ISO 13407 | Artefact RUP |
---|---|
Environnements |
|
Utilisateurs |
|
Rôles |
|
Tâches |
|
Tableau 4, Contextes de la norme ISO sur la conception centrée sur l'utilisateur et artefacts RUP
Chacun de ces contextes peut avoir un impact significatif sur la conception de l'interface utilisateur appropriée. Par conséquent, nous nous trouvons face à un nombre potentiellement important de permutations. Même pour un petit système, il peut y avoir 2 environnements (bureau et site client), 3 types d'utilisateurs (débutant en vente, expert en vente et direction) et 6 rôles (assistant de vente par téléphone, représentants commerciaux externes, etc.). Ce qui signifie jusqu'à 36 variations potentielles par tâche, même si l'ensemble de combinaisons réalistes est habituellement beaucoup plus limité.
En clair, les tâches doivent être décrites individuellement, mais une seule description ne conviendra pas pour toutes les permutations. Une des approches consiste à prendre en compte les contextes de l'utilisateur et de l'environnement dans la description des rôles. C'est la solution adoptée par Constantine et Lockwood [CON99]. Elle implique la proposition d'un "rôle utilisateur" séparé pour chaque permutation significative de rôle, utilisateur et environnement, puis de nommer le rôle utilisateur qui en résulte par une phrase descriptive, plutôt que par un simple nom. Comparez par exemple le rôle "Client" aux rôles utilisateur "Client occasionnel", "Client Web", "Client régulier" et "Client avancé".
Chaque description de rôle utilisateur comprend les détails du rôle lui-même, plus ses utilisateurs (désignés par titulaires du rôle) et l'environnement. Cette approche peut être adoptée par RUP en choisissant les acteurs qui correspondent aux rôles utilisateur.
Les termes scénarios, cas d'utilisation et cas d'utilisation essentiels présentent un degré de chevauchement déroutant et sont utilisés dans différentes approches de conception pour signifier des choses légèrement différentes. Dans RUP par exemple, "scénario" signifie une instance de cas d'utilisation ;
simplement un "chemin" spécifique à travers les flots de base et alternatifs possibles. Toutefois, il est commun de trouver des méthodes de conception centrées sur l'utilisateur et de conception de l'interface utilisateur décrivant les scénarios comme étant des descriptifs d'utilisation, contenant beaucoup plus de détails que le simple flot des événements. Tout en étant non pertinentes dans les phases ultérieures de la conception, ces informations supplémentaires font partie de la compréhension des utilisateurs, des tâches et des environnements. Par conséquent, les scénarios peuvent être largement utilisés dans les scénarimages et
les
jeux de rôles) dans la discipline de modélisation métier, mais l'intérêt se déplace verrs les cas d'utilisation dans la discipline Exigences.
La Figure 3 montre la nature de ce chevauchement. L'échelle du haut intègre un certain nombre de facteurs différents qui tendent à varier ensemble. Par exemple, au fur et à mesure que l'objet se déplace plus vers les exigences, la structure devient habituellement plus formelle. Les cas d'utilisation essentiels apparaissent à droite des cas d'utilisation génériques parce que les rôles utilisateur les rendent légèrement plus spécifiques (voir la section précédente) et ils présentent une structure plus formelle.
Figure 3 : Chevauchement des concepts entre scénarios et cas d'utilisation dans la conception centrée sur l'utilisateur
Les différences entre les cas d'utilisation système et les cas d'utilisation essentiels sont mieux illustrées par l'exemple. Le Tableau 5 montre un cas d'utilisation provenant de "Software for Use", de Constantine et Lockwood [CON99]:
Action utilisateur | Réponse système |
---|---|
insérer carte | lecture de la bande magnétique demande de code personnel |
saisir le code personnel | vérification du code personnel affichage du menu des options de transaction |
appuyer sur une touche | affichage du menu compte |
appuyer sur une touche | invite pour le montant |
saisir le montant | affichage du montant |
appuyer sur une touche | restitution de la carte |
retirer la carte | délivrance des billets |
prendre les billets |
Tableau 5 : Cas d'utilisation générique pour le retrait de billets dans un distributeur automatique
Cet exemple détaille la séquence d'événements entre l'acteur et le système, avec la ligne verticale entre les deux colonnes représentant l'interface utilisateur. Notez qu'alors que Constantine et Lockwood recommandent ce style pour les cas d'utilisation essentiels, ce cas d'utilisation particulier n'est pas un cas essentiel. La raison en est qu'il est basé sur un détail syntaxique de l'interaction. C'est-à-dire sur la manière dont l'interaction se déroule. Un cas d'utilisation essentiel est centré sur l'objet de l'interaction (appelé la sémantique). Le tableau 6 représente la version essentielle de l'interaction.
Intention de l'utilisateur | Responsabilité du système |
---|---|
S'identifier | vérifier identité présenter les choix |
choisir | délivrer les billets |
prendre les billets |
Tableau 6 : Cas d'utilisation essentiel pour le retrait d'argent dans un distributeur automatique
Ce cas d'utilisation capture l'essence de l'interaction de retrait d'argent. Les en-têtes Action de l'utilisateur et Réponse du système ont été remplacées par Intention de l'utilisateur et Responsabilité du système, pour refléter le changement du centre d'intérêt. Une bonne conception de l'interface est centrée sur les buts et les intentions de l'utilisateur ; souvent cachés dans les cas d'utilisation conventionnels. Les cas d'utilisation essentiels sont particulièrement utiles lorsque :
Les cas d'utilisation essentiels ont toutefois leurs inconvénients. Les cas d'utilisation parfaitement rectilignes, tel celui présenté dans le tableau 5, peuvent porter à un important débat lorsqu'il s'agit de distiller leur essence. Par exemple, est-ce que l'insertion d'une carte identifie le client ou le compte ? Dans la plupart des distributeurs, c'est le compte qui est identifié, même si Constantine et Lockwood ont choisi d'interpréter ceci comme étant une identification du client. Ceci a pu être une décision délibérée à la lumière des technologies les plus récentes, comme le balayage de la rétine et l'identification par les empreintes digitales, ou a pu être une erreur. La conséquence qui résulte dans ce cas, c'est que les clients qui ont plusieurs comptes auront à faire un choix supplémentaire.
L'autre difficulté est que les cas d'utilisation essentiels ne sont pas adaptés à une revue avec les utilisateurs finaux et autres intervenants en raison de leur nature abstraite. Pour une part, ce problème réside dans l'obligation de retraduire les cas d'utilisation en une forme concrète représentant les actions de l'utilisateur. Une fois le modèle de conception disponible, ceci peut être fait par la rédaction de scénarios décrivant l'interaction en termes concrets (similaire dans leur concepts à la réalisation du cas d'utilisation, même s'ils portent plus sur l'interaction utilisateur-système que sur la collaboration des objects internes).
En résumé, la construction de cas d'utilisation essentiels peut ne pas être une bonne idée si :
RUP ne se réfère pas explicitement aux cas d'utilisation essentiels, mais dans Activité : Concevoir l'interface utilisateur, les cas d'utilisation essentiels sont considérés comme point de départ, puis développés et complétés avec les exigences d'utilisabilité pour créer des Scénarimages, comme expliqué dans Principes et conseils : Scénarimage.
Ceci signifie la suppression de tout le détail de la conception ou de l'implémentation courante de manière à ce que seule la sémantique, la signification de l'interaction, demeure. Puis, au fur et à mesure de l'exploration de diverses alternatives de conception, le détail sémantique (comment l'interaction se déroule) est ajouté au cas d'utilisation essentiel, sous forme de type de réalisation. (Chaque conception alternative est en effet une réalisation du même cas d'utilisation essentiel.)
Les scénarimages peuvent alors être utilisés comme entrée pour Activité : Prototyper l'interface utilisateur, pour développer le prototype de l'interface utilisateur.
RUP (Rational Unified Process)
|