LOG2420 | Analyse et conception d’interfaces utilisateur ... · attentes. Un processus adapt e au d eveloppement d’application interactive doit investir bien ... 1.Les exigences,

LOG2420 — Analyse et conception d’interfacesutilisateur

Ecole Polytechnique de MontrealNotes du cours

Hiver, 2017

Michel C. Desmarais

Version 27 janvier 2017

1

partie TABLE DES MATIERES

Table des matieres

I Processus de developpement centre utilisateur 3

1 Cycles de conception et de developpement 3

1.1 ISO 13407 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Exigences utilisateur 19

2.1 Elaboration et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2 Utilisabilite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2

Premiere partie

Processus de developpement centreutilisateur

1 Cycles de conception et de developpement

La conception et le developpement d’applications interactives comportent des caracteristiquesdifferentes du developpement de logiciels non interactifs. Nous referons au terme conceptioncentree utilisateur (ou developpement centre utilisateur pour rerefer au cycle complet) pourdesigner un processus comportant les caracteristiques et activites propres et adaptees a laconception et au developpement d’applications interactives.

D’une part et comme nous l’avons vu dans l’introduction, le produit final qui interessele client d’une application interactive provient de l’utilisation du logiciel par l’utilisateur.Or, ce produit depend en bonne partie de l’utilisateur, de son expertise, de son degre defamiliarite avec l’application, et bien entendu de la qualite de l’interface. Il faut donc que leprocessus de developpement tienne compte de l’utilisateur et de sa maıtrise l’interface pouraccomplir un certain nombre de taches. L’evaluation de la satisfaction des exigences ultimesdu systeme doit se faire au niveau du systeme utilisateur-ordinateur. Au contraire, dans le casd’un systeme qui n’a pas d’interface directe avec l’ordinateur et qui est pilote par une autreapplication ou un mecanisme quelconque, on peut plus facilement se contenter de valideruniquement les specifications fonctionnelles offertes par le systeme. Par exemple, dans le casd’une librairie graphique ou de calcul scientifique, on peut souvent se contenter de verifier lefonctionnement par des tests unitaires l’ensemble de l’API sur les plates-formes visees. Destests plus pousses vont aussi valider la performance de l’utilisation de la librairie dans uncontexte pratique, mais les resultats sont souvent previsibles ou, du moins, ne reservent pasautant de surprises que pour les applications interactives. Et ces tests sont, quoi qu’il en soit,a effectuer pour toute application. Tandis que la validation que les exigences utilisateurs sontles bonnes, ainsi que les tests pour valider que les utilisateurs vises reussissent a effectuerles taches desirees correctement, sont des activites qui sont en sus et qui ne s’appliquent quepour les applications interactives.

Une autre difference majeure entre une application interactive et un logiciel non interactifest que la gestion des exigences est tres differente. Or, la gestion des exigences est critique,car on sait fort bien que les erreurs au niveau des exigences sont les plus couteuses : uneerreur au niveau des exigences qui est decouverte dans la phase de deploiementdu logiciel peut couter de 100 a 1000 fois le cout de correction lors de la phase

Premiere partie 1 CYCLES DE CONCEPTION ET DE DEVELOPPEMENT

de specification des exigences 1.

Or, les exigences utilisateurs sont particulierement changeantes et volatiles en com-paraison a des exigences techniques. Par exemple, dans le cas du developpement de piloteslogiciel d’un nouvel appareil, une carte de communication ou un numeriseur video, peu im-porte, les specifications sont relativement stables et bien definies. Souvent, les specificationssuivent des normes et il n’y a que tres peu d’inconnus. Au contraire, les exigences utilisateurssont mal connues au debut. Les utilisateurs potentiels que l’on a questionnes initialementn’ont qu’une vague idee de ce que doit faire l’application et c’est souvent au moment decommencer a l’utiliser (dans la phase de deploiement) qu’il realisent que des fonctions cri-tiques manquent ou ne sont pas implantees de la bonne facon et ne correspondent pas a leursattentes. Un processus adapte au developpement d’application interactive doit investir biendavantage dans la validation des exigences tot dans le processus pour eviter ces situationset il doit recourir a des activites specifiques a ce type de developpement comme des analysesde taches et des maquettes plus ou moins interactives pour valider les concepts initiaux.

Le developpement de logiciel

— Il existe des differences fondamentales entre le developpement d’un logiciel interactifet un logiciel non interactif— Ex. logiciel interactif : interface a un telephone portable— Ex. logiciel non interactif : pilote de la carte antenne du telephone portable

— La difference principale : les exigences utilisateurs sont volatiles, elles changentau long du projet

— Pour des applications interactives, c’est pres de 50% du code qui est dedie a l’inter-face

— Par consequent, le processus de developpement doit etre adapte

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Le cout de changements d’exigences selon la phase

1. Sharif, B., Khan, S. A., Bhatti, M. W. (2012). Measuring the Impact of Changing Requirementson Software Project Cost : An Empirical Investigation. International Journal of Computer Science Issues(IJCSI), 9(3).

Young, R. (2001). Effective Requirements Practices.

4


Cout Phase1$ Exigences2–6$ Conception10$ Codage15–60$ Tests (developpement)30–70$ Tests (acceptabilite)40–1000$ Operations

source : Young, R. (2001). Effective Requirements Practices.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Modele en cascades avec retours

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Le modele en spirale s’approche du centre utilisateur sans toutefois en comporter lesparticularites specifiques.

Modele en spirale

5


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Le modele en spirale est un autre modele bien connu qui se prete a la conception d’inter-faces utilisateur, sans toutefois specifier explicitement les caracteristiques et activites propresau developpement centre utilisateur. Neanmoins, l’emphase mise sur les iterations et le pro-totypage progressif de l’application finale lui confere un caractere peut-etre plus pres de cetype de developpement que le RUP en lui-meme.

Modele iteratif

est adaptable, mais pas adapte au modele centre utilisateur. Les cas d’utilisation sont lesartefacts cles pour le developpement d’applications interactives.

6


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les modeles iteratifs, comme le processus unifie (unified process), dont le RUP c© est unproduit commercial bien connu) est un processus tres repandu dans l’entreprise et enseignea l’Ecole, tout comme dans plusieurs autres institutions. Il n’est pas specifiquement adapteau developpement d’applications interactives, mais il comporte une structure generale et unensemble d’artefacts qui peuvent se preter a un tel type de developpement.

Dans le cadre du processus unifie, un des plus importants artefacts pour la conceptiond’application interactive est le cas d’utilisation. Il s’approche de la notion de scenario (Rossonet Carroll, 2002) 2, mais s’en distingue par son niveau de genericite qui est plus eleve que lescenario. On peut considerer le scenario comme une mise en contexte d’un cas d’utilisation.Rosson et Carroll suggerent qu’un scenario devrait etre une description plus specifique d’uncas d’utilisation ou les problemes d’utilisabilite sont specifiquement releves (p. 19).

Bref, on peut, avec le processus unifie, implanter un processus de developpement relati-vement bien adapte pour les applications interactives, comme on peut passer completementa cote des activites importantes (voir par exemple Gulliksen et al, 2005) 3.

Plusieurs de ces processus existent et nous en survolons quelques-uns tres brievementavant de ce concentrer sur le processus centre utilisateur de conception d’interfaces ISO-13407 (maintenant ISO-9241-210 :2010).

2. Rosson, M.-B. et Carroll, J. M. (2002) Usability Engineering, Scenario-Based Development of Human-Computer Interaction. Morgan Kaufmann.

3. Gulliksen, J., Goransson, B., Boivie, I., Blomkvist, S., Persson, J., and Cajander, A., “Key principlesof user-centred systems design”. In Seffah, A., Gulliksen J. and Desmarais, M.C., Human-Centered SoftwareEngineering : Integrating Usability in the Development Process, Wiley, 2005.

7


Processus de developpement centre utilisateur selon Constantine et Lockwood (1999)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Constantine et Lockwood (1999) 4 definissent un cycle de developpement propre a l’ap-proche centree utilisateur. On y retrouve certaines activites propres au developpement centreutilisateur, notamment l’analyse de taches, la modelisation du contenu de l’interface et l’ins-pection de l’utilisabilite, ainsi que d’autres activites propres a ce cycle mais a saveur centreeutilisateur comme le “dialogue collaboratif autour des exigences” et “la contextualisationoperationnelle”.

Un autre processus processus bien connu est celui de Mayhew (1999) 5. Il a la particularited’etre relativement bien arrime avec des jalons et artefacts de processus et pratiques repandusdans l’industrie, tel que la production d’un guide de style.

Processus de developpement centre utilisateur selon Mayhew (1999)

4. Constantine L., and Lockwood, L. Software for Use : A Practical Guide to the Essential Models andMethods of Usage-Centered Design. Reading, MA : Addison-Wesley, 1999.

5. Mayhew, D. J. (1999). The usability engineering lifecycle. San Francisco, CA. : Morgan KaufmannPublishers, Inc.

8


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


9


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Quelques premisses fondamentales d’un cycle centre utilisateur

1. Les exigences, et en particulier les exigences utilisateur :— peuvent difficilement etre entierement, precisement et correctement specifiees ;— il faut un une serie de prototypes pour aider a mieux les circonscrire et les com-

prendre ;— elles evoluent au long des iterations.

10


2. Il est essentiel de bien connaıtre les utilisateurs et le contexte d’utilisation afind’effectuer une conception eclairee

3. On ne peut anticiper parfaitement le comportement des utilisateurs, il faut testeravec une approche empirique et faire appel a plusieurs experts pour evaluer unprototype.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1 Le cycle centre utilisateur ISO 13047

ISO 13407

(1) Planification duprocessus centré-ut i l isateur

(2) Comprendre et spécifierle contexte d’utilisation

(3) Spécifier les exigences utilisateurset organisat ionnel les

(4) Concevoir dessolutions de conception

(5) Évaluer les solutionspar rappor t aux exigences

Exigences satisfaites?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

L’organisme de normalisation ISO a aussi defini un cycle de conception centre utilisateur,ISO 13407 (maintenant ISO 9241-210 :2010). Ce cycle ne couvre pas l’ensemble du processusde developpement, mais porte uniquement sur la specification des exigences utilisateurs.C’est probablement la phase la plus critique du cycle de developpement d’une applicationinteractive puisqu’elle aborde le probleme de la definition et de la validation des exigencesutilisateur qui, si elles sont erronnees, auront un impact majeur sur la qualite du logiciel etle debordement de l’echeancier ou du budget du projet (comme c’est generalement le caspour toute exigence mal definie ou invalide).

Le cycle de validation des exigences comporte cinq etapes que nous revisons ici.

(1) Planification du cycle centre utilisateur

— Enjeux de l’utilisabilite pour le projet

11


— Impact sur les operations— Complexite (ex. flux d’echanges entre utilisateurs dans l’organisation)

— Analyse cout-benefice— Determine l’effort qu’on devrait y consacrer— Ex. 1% de 50 utilisateurs × 20h × 40 sem × 3 ans × 50 $ = 60 000 $— 1% de 4h = 2,5 minutes !

— Qui sont les utilisateurs ?— Utilisateurs captifs ?— Experience et habilete

— Frequence d’utilisation— La loi de la puissance de l’apprentissage (T = K1 ×Kn

2 )

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

La premiere etape du cycle defini par ISO 13407 est celle de la planification du cyclecentre utilisateur. Cette etape consiste en premier lieu a bien circonscrire les objectifs glo-baux du projet et a etablir le lien entre ces objectifs, les exigences utilisateurs et les objectifsd’utilisabilite. Une des activites potentielles de cette etape est l’analyse cout-benefice afinde baliser le retour potentiel de facteurs d’utilisabilite. Par exemple, on tentera de chiffrercombien chaque dollar investi en utilisabilite peut representer en calculant le gain de pro-ductivite pour l’ensemble des utilisateurs. Parfois, ce gain peut etre tres important lorsqu’ily a plusieurs utilisateurs qui utilisent le logiciel durant de longues periodes. Inversement, onpeut aussi decouvrir que les enjeux d’utilisabilite ne sont pas tres grands et l’on reduira laportee des efforts investis en proportion.

On determinera aussi, dans les grandes lignes, qui sont les intervenants et les principauxutilisateurs (les details quant aux utilisateurs seront completes a l’etape suivante) et commenton les impliquera dans le projet. Les grands objectifs d’utilisabilite a atteindre et les jalonsqui y correspondent dans le plan de projet seront definis. Le choix du nombre d’iterations,la composition de l’equipe et la facon dont on fera la gestion du volet utilisabilite serontdefinis.

(2) Contexte d’utilisation

— Utilisateurs— Experience et habiletes, connaissances du domaine, age et sexe, attitudes et mo-

tivations— Diversite (horizontale et verticale)

— Taches— Frequences— Importances respectives— Durees et niveau de difficulte

12


— Dependances— Environnement technique

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

(2) Contexte d’utilisation (suite)

— Environnement physique— Bruit, chaleur, vibrations, eclairage (ex. guichets dans le rayon du soleil !)— Posture, risques a la sante (normes internationales)

— Environnement organisationnel— Pratiques, politiques d’utilisation et d’achats materiels, relations de pouvoir— L’exemple de Chernobyl revele l’importance de bien prendre en compte

les pratiques

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Avant de definir les exigences utilisateurs, il importe de specifier le contexte d’utilisation.Quel est le profil des utilisateurs vises ? Quelles taches vont-ils effectuer avec l’application etavec quelle frequence ? Quelles sont les dependances entre les taches et les informations quisont necessaires pour les effectuer ? Quel est le flux d’information qui s’echange entre utili-sateurs ? Quelles sont les conditions physiques d’utilisation ? Etc. Le contexte d’utilisationpermet de cerner des informations critiques pour la definition des exigences utilisateur.

(2) Methodologies d’analyse du contexte d’utilisation

— Questionnaires, documentation— Interviews— Observations ethnographiques— Journal de bord— Analyse de tache

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Il existe un bon nombre de methodes pour aider la specification du contexte d’utilisa-tion. Certaines sont bien connues comme les questionnaires et les interviews, d’autres le sontmoins et proviennes de domaines comme l’ergonomie, l’ethnographie et la communication.Une des techniques fondamentales est l’analyse des taches qui est tres utilisee en ergonomie.Les techniques d’observation, tres utilisees en ethnographie, sont aussi utiles pour tirer uneinformation sur le contexte et les taches des utilisateurs qui ne se retrouve pas dans au-cune documentation et dont meme les interviews ne refletent pas le contenu. On pense, parexemple, a des pratiques non documentees ou a des echanges qui, bien qu’informels, sont des

13

(1) Planification duprocessus centré-ut i l isateur

(2) Comprendre et spécifierle contexte d’utilisation

(3) Spécifier les exigences utilisateurset organisat ionnel les

(4) Concevoir dessolutions de conception

(5) Évaluer les solutionspar rappor t aux exigences

Exigences satisfaites?


elements cles d’echange d’information pour effectuer differentes taches. En communicationet en etudes psycho-sociales, on utilise souvent un journal de bord pour colliger des informa-tions sur les activites realisees par des individus et ainsi en etablir la frequence, l’horaire ouautre information qui doit etre recueilli sur plusieurs jours et ne se prete pas a l’observationdirecte et dont il est parfois difficile de se rememorer fidelement.

Maguire (2001) passe en revue plusieurs activites qui sont utiles a la definition du contexted’utilisation.

Exemple d’analyse de tache

Taches pour de gestion d’un magasin (http://www.usabilis.com/methode/analyse-tache.htm)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

(3) Exigences utilisateurs, d’utilisabilite et organnisationnels

— Exigences utilisateurs— surtout des exigences fonctionnelles qui decoulent des taches

14

http://www.usabilis.com/methode/analyse-tache.htm

http://www.usabilis.com/methode/analyse-tache.htm


— Exigences d’utilisabilite— Taux de succes— Nombre d’erreurs— Temps d’execution des taches— Rythme d’apprentissage— Satisfaction

— Les exigences changent selon les categories d’utilisateurs et le niveau d’apprentissage— Exigences organisationnels

— Processus et flux d’echanges— Ex. taux d’appels d’un centre de telemarketing ou taux de recouvrement d’un

service de facturation

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Distinguons dans un premier entre exigences utilisateurs et exigences d’utilisabilite. Lespremieres sont notamment les exigences fonctionnelles que l’on retrouve dans l’interfaceutilisateur. Elles decoulent normalement de l’analyse des taches que les utilisateurs doiventeffectuer. Les exigences d’utilisabilite, elles, portent sur les criteres d’utilisabilite qui doiventetre respectes lors de l’execution de ces taches avec les fonctions du systeme. Il s’agit, parexemple, du taux de succes, du taux d’erreurs, du temps d’execution, pour ne nommer queles principales.

A noter que toutes ces exigences peuvent varier selon les categories d’utilisateurs. Celadecoule du fait que differentes categories peuvent avoir differentes taches et les exigencesfonctionnelles doivent donc necessairement varier. De plus, les profils utilisateurs peuventaussi varier, ce qui explique pourquoi les exigences d’utilisabilite peuvent varier a leur tour.

Lorsque le systeme s’adresse a une organisation et implique plusieurs groupes de per-sonnes, des exigences organisationnelles peuvent alors s’appliquer. Par exemple, dans le casou l’on desire introduire un systeme de gestion des appels de clients dans un centre de soutientechnique, on pourra etablir une exigence quant au nombre maximal de requetes qui ne sontpas reglees au cours du premier appel. Une telle exigence aura un impact sur la conceptionde l’interface afin de maximiser le nombre de problemes regles sur le champ.

(4) Solutions de design

— Remue-meninges— Conception parallele— Scenarisation— Diagrammes d’affinite et tri de cartes— Maquettes papier— Prototypes— Wizard of oz

15


— Prototypage organisationnel

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Une fois un ensemble d’exigence defini, le cycle ISO 13407 prescrit la definition de solu-tions pour satisfaire les exigences definies a l’etape precedente. Lors des premieres iterations,ces solutions peuvent etre tres embryonnaires. On peut premierement evoquer des conceptstres generaux qui serviront de base a l’ebauche de maquettes. Ce sera l’objectif de seancede remue-meninge. Si plusieurs concepts s’averent interessants, on peut meme les poursuivreen parallele jusqu’a ebaucher des maquettes qui permettront, dans un second, un choix pluseclaire quant a la solution qui apparaıt la plus favorable.

Des maquettes papier ou des prototypes connus sous le nom de “magicien d’Oz” per-mettent de tester initialement des solutions sans investir dans le prototypage fonctionnel.Elles sont tres utiles dans la mesure ou il est souvent utile de valider tres tot des pistes desolutions et de valider des exigences, plutot que de le faire apres un effort de developpementplus lourd. Comme on le mentionnait plus haut, les utilisateurs ont generalement de la dif-ficulte a imaginer une solution logicielle et c’est en leur presentant des maquettes concretesqu’ils peuvent alors se faire une idee plus precise de ce dont ils ont reellement besoin et dece que le concepteur a reellement en tete !

Dans des projets de plus grande envergure et qui peuvent impacter un grand nombred’employes dans une entreprise, on ira jusqu’a deployer un prototype d’application dans unepartie de l’entreprise afin de valider la solution envisagee. Cette approche est preconiseelorsque l’introduction d’une application comporte un risque de perturber les operations cri-tiques de l’entreprise.

(5) Evaluations

— Evaluation participative— Evaluation heuristique— Tests utilisateur controles— Questionnaires de satisfaction— Inspections cognitives— Incidents critiques— Feedback suite a un test ou une utilisation prolongee— Statistiques d’utilisation (ex. Web)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les solutions avancees doivent etre validees afin de determiner si elles satisfont aux exi-gences specifiees. Il existe plusieurs techniques dont l’utilite varie selon le type d’applicationest le stade d’avancement. Nous les mentionnons simplement ici et les reverrons dans lapartie dediee a l’evaluation (??).

16


Survol des methodes

*source : http://www.usabilitynet.org/tools/methods.htm

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Le tableau du syte http://www.usabilitynet.org/tools/methods.htm fournit uneliste de methodes et activites recomandes pour le developpement centre utilisateur. Cesactivites sont organisees en fonction des differentes phases.

Exemple

Le baladeur Sanyo revu et corrige

Supposons que l’on a effectue le processus ISO 13407 pour determiner les exigences uti-lisateur du baladeur Sanyo.

— Identification des enjeux d’utilisabilite quant aux objectifs et au contexte d’affaires ;on le fera entre autres avec les gens du marketing et de la conception materielle etlogicielle

— Analyse des produits concurrents— Sondage aupres de 100 consommateurs (echantillonnage selon des utilisateurs cibles,

p. ex. 4 × 25)— Interviews de 20 utilisateurs

— Definition de principes generaux de design et conception de quelques prototypes d’in-terfaces, par ex. :— definir le contexte d’utilisation— faire une ou plusieurs maquettes et effectuer une evaluation heuristique et

une inspection cognitive des maquettes de chacune (concepts qui seront vus dansla partie evaluation)

— iterer sur la base de ces evaluations

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Prenons l’exemple du baladeur Sanyo vu dans la premiere partie pour illustrer quelleforme le processus ISO 13407 pourrait prendre.

Premierement, il faut etablir le role que l’utilisabilite jouera dans le produit. Curieuse-ment, si l’on s’en fie a mon comportement de consommateur, on en conclurait que ce roleest minime par rapport au prix ! J’ai achete cet appareil sans preoccupation pour son uti-lisabilite, simplement sur la base qu’il offrait aussi la lecture de fichier MP3 et qu’il etaitbon marche. Mais mon comportement ne s’arrete pas la. Je suis maintenant plus craintif par

17

http://www.usabilitynet.org/tools/methods.htm

http://www.usabilitynet.org/tools/methods.htm


rapport a la marque Sanyo et j’en ai une image d’entreprise qui ne se soucie pas de ce qu’onnomme la “qualite totale”, ce que l’on peut associer a la qualite qui apparaıt apres que l’ons’est procure le produit ! J’y pense maintenant deux fois avant d’acheter la marque Sanyo.

De cette analyse tout a fait informelle et subjective, il est difficile de deriver, par exemple,quel est le budget et le niveau d’utilisabilite qu’on devrait viser avec le baladeur, mais disonssimplement que ca vaut au moins quelques jours de travail et qu’il faut pouvoir effectuer lestaches essentielles sans manuel utilisateur, comme celle de passer a l’album suivant pour unutilisateur “normal” !

Une fois le role de l’utilisabilite circonscrit dans le cadre du projet (nous sautons lesetapes ici car la specification de ce role necessiterait a lui seul quelques pages), on etablit unepremiere version des exigences utilisateurs et organisationnelles. Comme l’appareil s’adressea un usage individuel et qu’il est relativement independant d’autres produits de l’entreprised’une perspective d’utilisation (contrairement au iPod, par exemple, dont on vise a lierl’utilisation au site de vente en ligne de musique/video de Apple), alors on peut ignorer lesexigences organisationnelles pour cet exemple.

Un certain nombre d’activites peuvent etre entreprises pour faciliter la specification desexigences. La plus simple et probablement la plus efficace est celle d’analyser les produitsconcurrents lorsqu’ils existent. Lorsqu’ils n’existent pas et lorsqu’on veut offrir un produitoriginal qui se distingue des autres par son originalite et une interface mieux adaptee auxbesoins, d’autres activites sont indiquees. Si on possede peu ou pas d’information quant auxprofils utilisateur, on effectuera un sondage en prenant soin de le distribuer a tous les typesd’utilisateurs. Le taux de reponse aux sondages peut varier considerablement et le nombrede reponses que l’on espere recevoir doit donc etre determine en consequence. Le sondage estune activite qui permet surtout d’obtenir des donnees quantitatives quant aux profils socio-economique, aux attentes et preferences, aux taches et aux types d’utilisation auxquelleson peut s’attendre des utilisateurs. Les questions ouvertes, ou les gens inscrivent un texteou des termes selon leur choix, se pretent mal a une compilation avec un grand nombrede repondants. Ils sont donc peu indiques pour un sondage aupres de plusieurs personnes.Pour le baladeur Sanyo, on voudra savoir, par exemple, qui en possede deja un, a quellefrequence ils l’utilisent, qui a un ordinateur avec de la musique MP3, la fourchette de prixqu’ils s’attendent a debourser, etc.

Pour aller plus loin et obtenir des reponses plus ouvertes, on procedera avec un inter-view. Les interviews permettent entre autres d’obtenir des informations qui sont difficiles aobtenir par un sondage. On pourra poser des questions du style “qu’elle est la raison pourlaquelle vous n’avez pas de lecteur MP3 ?”, “avez-vous de la difficulte a creer des CD audio etnumeriques ? Quel est le principal probleme que vous rencontrez ?”. Bref, toute informationde nature difficilement quantifiable et ouverte se prete a l’utilisation de sondage pour lesobtenir.

L’analyse des taches courantes a effectuer avec un baladeur necessite, elle aussi, desactivites specifiques. Les interviews peuvent en indiquer plusieurs, mais certaines taches

18

Premiere partie 2 EXIGENCES UTILISATEUR

peuvent etre difficile a identifier de cette maniere et ont de meilleures chances d’etre trouveespar une observation de comment les individus gerent leurs CD musicaux audio et leurs fichiersMP3, et comment ils les ecoutent sur differents appareils. Cette analyse aurait certainementdu permettre d’identifier les besoins les plus evidents comme celui d’avoir des boutons “albumavant” et “album arriere” (en presumant que l’analyse des produits concurrents ne l’ait pasdeja releve).

Les exigences doivent etre validees. Ce n’est pas parce que 98% les repondants d’unsondage disent repondent positivement a une question comme “aimeriez-vous pouvoir effec-tuer une recherche dans vos fichiers MP3 ?” que l’on doit accorder une grande importancea l’exigence d’implanter la fonction correspondante ! Il faut que les utilisateurs puissentbien comprendre a quoi peut correspondre une exigence en pratique et qu’ils puissent fairel’experience de l’utilisation du produit afin de se faire une meilleure idee des fonctions qu’ilsdesireraient vraiment avoir.

Pour valider les exigences, l’analyse du contexte d’utilisation fournit souvent des donneesauxquelles il faut referer. Si, par exemple, seulement 5% des repondants au sondage affirmentconnaıtre ce qu’est un fichier MP3 (on se rapporte en 2000–2002 environ) et qu’encoremoins d’entre eux ont de tels fichiers sur leur ordinateur, les exigences autour des fichiersnumeriques deviennent moins prioritaires 6. Mais au-dela de ce qu’on peut obtenir de l’analysedu contexte d’utilisation et de la tache, il importe de valider les exigences en les soumettanta une mise en oeuvre concrete dans une maquette d’interface.

La maquette peut n’etre qu’une serie d’“ecrans” simules et plus ou moins fonctionnels,ou meme une serie de dessins sur du papier. L’important est de fournir a l’utilisateur unerepresentation concrete de ce qu’on envisage implanter pour satisfaire les exigences utilisa-teur.

Dans le cas du Sanyo, il est evident qu’une simple maquette papier, ou l’on aura demandea deux ou trois personnes les taches courantes, aurait mis en evidence que la fonction derecherche d’une chanson par mots-cles etait beaucoup trop complexe pour etre utilisee dansle contexte normal d’utilisation du baladeur.

2 Exigences utilisateur

Comme mentionne, les erreurs au niveau des exigences s’averent les plus couteuses, sur-tout lorsqu’on les decouvre tard dans le cycle de developpement. Les exigences utilisateursn’echappent pas a cette regle. On peut meme dire qu’elles sont peut-etre les plus susceptiblesd’etre sujettes a erreur, car, par exemple, les utilisateurs n’ont pas une idee claire de ce qu’ilsveulent, et aussi les plus susceptibles d’etre decouvertes au moment de la derniere phase du

6. C’est evidemment bien different si le produit vise a se differencier de la concurrence et s’adressespecifiquement a ce faible pourcentage de la population qui tient a l’utilisation de baladeur pour fichiersMP3.

19


cycle, le deploiement, puisque c’est a ce moment que les utilisateurs font l’experience concretede l’application est expriment leurs “veritables besoins” ! Tout developpeur experimente avecu une experience ou l’utilisateur client reviens sur une fonctionnalite du systeme qui n’est“pas tout a fait ce qu’il voulait dire” et qu’en realite c’est d’une autre facon qu’il faudraitimplanter la fonctionnalite en question... sans oublier qu’il lui faudrait aussi telles et tellesautres fonctionnalites !

Nous completons donc la partie des processus avec quelques remarques supplementairesquant aux exigences utilisateur.

2.1 Elaboration et validation

Exigences utilisateur et exigences d’utilisabilite

— Exigences utilisateur— fonctionnalite— profil, competences, preferences— toute autre exigence qui touche directement les utilisateurs

— Exigences d’utilisabilite— temps d’execution d’une tache, taux d’erreurs, temps d’apprentissage, etc., selon

des profils utilisateur specifiques, bien entendu !— determinees en fonction du contexte d’utilisation, d’applications concurrentes, ou

d’objectifs corporatifs.

Nous ouvrons une parenthese sur la distinction entre exigences utilisateur et exigencesd’utilisabilite, qui sont tres differentes l’une de l’autre.

La definition des exigences utilisateur n’est pas universelle. Nous definirons les exigencesutilisateurs comme les exigences qui ont un impact direct sur les utilisateurs ou les exigencesqui emanent des utilisateurs.

Ceci inclut en general toutes les exigences fonctionnelles d’une application interactive quise retrouve dans l’interface. On inclut aussi les profils des utilisateurs anticipes, a savoir leurexperience avec l’application, les ordinateurs en general et avec le domaine d’application, quisont des facteurs qui influencent grandement la conception de l’interface.

Les exigences d’utilisabilite portent, quant a elles, uniquement sur des facteurs d’utilisa-bilite. On peut par exemple referer au temps moyen d’execution d’une tache avec l’interface.Pour operationnaliser cette exigence, on referera a un temps moyen d’execution pour unechantillon de n utilisateurs avec un profil de competences donne, tel que mesure par x testsutilisateur. Dans des cas extremes, on pourrait meme specifier des ecarts types auxquels ons’attend.

20


Toute mesure d’utilisabilite est susceptible d’etre utilisee pour specifier une exigenced’utilisabilite. Ces exigences se definissent en general par rapport a des taches que l’on peuteffectuer avec l’application.

A propos des utilisateurs

— L’utilisateur moyen n’existe pas— Les utilisateurs ne sont pas des concepteurs

— Ils ont de la difficulte a se representer le systeme a partir de specifications tech-niques

— Ils sont tres bons pour reagir a des propositions concretes : Schemas, papier,maquettes, prototypes

— Ils ne connaissent pas les possibilites offertes par la technologie— Ils ne savent pas necessairement ce qu’ils veulent, ni ce dont ils ont besoin— Ils ont une connaissance qui evolue avec l’usage du systeme— Ils pensent en termes de logique d’utilisation alors que les concepteurs ont une logique

de fonctionnement du systeme

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Problemes frequents avec les exigences utilisateur

Selon McConnel (Rapid Development), les utilisateurs :— ne comprennent pas ce qu’ils veulent— refusent de se commettre sur des exigences ecrites et fixes— insistent pour de nouvelles exigences une fois le budget et l’echeancier determines— ne participent pas a des seances de revision ou sont incapable de contribuer de facon

productive et efficace— ne sont pas suffisamment outilles techniquement— ne comprennent pas le processus de developpement

et, de plus, la communication avec eux est fastidieuse.

Les problemes avec les exigences utilisateur releves ci-dessus par McConnel sont relati-vement universels et tout developpeur d’experience pourra en attester. Ces problemes sonta la source de la volatilite des exigences utilisateurs, volatilite est a son tour la source dedepassement de budget et d’echeancier de projet de developpement de logiciels interactifs.

L’elaboration des exigences

21


— Protypage des specifications floues— les utilisateurs comprennent mieux leurs propres besoins lorsqu’ils sont confrontes

avec une representation concrete de l’interface— Utilisation de scenarios pour “ eliciter ” les specifications

— a l’instar des utilisateurs, les concepteurs imaginent mieux les besoins lorsqu’ilssont confrontes a un scenario specifique d’utilisation

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Il existe, heureusement, bon nombre de principes et d’approches pour aider a elaborer etvalider les exigences utilisateurs.

En anglais, on refere au probleme d’elaboration des exigences utilisateur par le termeelicitation. Cette notion refere a l’art de soutirer les veritables besoins utilisateur, ces be-soins qu’il n’exprime jamais clairement lorsqu’on lui pose simplement la question de quellesfonctionnalites il a besoin !

Une des approches les plus efficaces est celle de fournir aux utilisateurs prospectifs unprototype semi-fonctionnel de l’application. Pensons par exemple aux premiers tableurs. Ilserait tres difficile pour un comptable des annees 1970 d’imaginer les fonctions d’un tableuret d’exprimer que c’est bien ce qu’il veut. A moins qu’il soit un veritable visionnaire, il estfort peu probable qu’il exprime ce besoin spontanement ! Puis, une description verbale desfonctions de tableur pourrait lui sembler totalement abstraite. Par contre, il est fort probablequ’un prototype semi-fonctionnel evoque immediatement le besoin d’une telle application !Il imaginera alors ce a quoi pourrait ressembler son travail pour telle ou telle autre tache, cequi en retour fournira le concepteur logiciel des informations supplementaires pour elaborerles fonctions a developper.

A l’inverse, si on se reporte maintenant en 2000 et qu’on demande a un utilisateurs’il desire acceder au Web a partir de son telephone, la reponse sera certainement un ouiconvaincu. Puis, si on lui donne un de ces telephones de 32 pixels par 24 pixels pour vi-sualiser une page Web et qu’on lui demande si c’est bien ce qu’il voulait, sa reponse peutfacilement etre anticipee, surtout si on complete l’experience en lui demandant de consulterses courriels ou les cotes de la bourse sur le site finance.yahoo.com... Il ne reussira pas acompleter efficacement aucune de ces taches a cause de l’ecran trop petit. Pourtant, uneserie de telephones avec ce type d’acces Web ont vu le jour autour de ces annees !

De la on peut en tirer l’importance de prototyper ce qu’on envisage comme applica-tion et d’obtenir un retour d’information de la part d’utilisateurs quant a l’utilite et auxameliorations de la solution prototypee.

En outre, le prototype est une excellente forme de specification logicelle. Bien que assezpeu acceptes dans les milieux academiques et dans les processus de genie logiciel repandus (al’exception peut-etre des processus dits agiles), les prototypes peuvent neanmoins representerune forme de specification precise de l’interactivite et de l’affichage d’une interface utilisateurqui s’avere souvent bien plus utile que des descriptions verbales ou schematiques.

22


Outre les prototypes, des scenarios ou l’on decrit un contexte precis d’un utilisateur quiinteragit avec l’application. Par exemple, Greg Cooper a introduit la notion de personnaqui represente un utilisateur et incarne une personnalite et un profil specifique. L’utilisa-tion d’un contexte tres specifique permet au concepteur de mieux envisager les besoins etexigences utilisateurs, a l’instar de l’utilisateur qui envisage mieux les fonctionnalites qu’ildesire lorsqu’il se trouve devant une representation concrete de l’interface de l’application.

La validation des exigences

— Coordonner des inspections formelles des specifications— Recours a des equipes interdisciplinaires— Definir des listes de validation ( “ checklist ”)— Valider la conformite des specifications aux normes

— Recours au prototypage pour ameliorer les specifications— Ecriture d’une esquisse du manuel de l’utilisateur— Elaboration d’une batterie de tests utilisateur— Paraphrasage des modeles systemes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Une fois le processus d’“ elicitation ” effectue, differentes activites peuvent etre mises enoeuvre pour valider si les exigences utilisateurs obtenues sont adequates.

Les inspections, ou revues, des exigences par les intervenants sont une etape incontour-nable du processus de validation. Cette etape est, en fait, souvent prescrite par les processusde gestion de projet qui exigent que les utilisateurs, le client, le chef de projet et certainsautres intervenants acceptent les specifications telles que decrites.

2.2 Exigences d’utilisabilite

Les specifications propres a l’utilisabilite

— Efficacite et efficience— Temps, nb. d’actions, ratio de taches reussies, erreurs

— Facilite d’apprentissage— Temps, ratio de taches reussies, erreurs

— Flexibilite— Methodes alternatives, adaptation a d’autres contextes

— Attitude

23


— Questionnaire qualitatif, commentaires— Differences individuelles

— Variance par rapport a differents criteres

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les criteres d’evaluation propres a l’utilisabilite

— Temps pour accomplir une tache— Pourcentage des taches reussies— Taux d’erreur— Temps de recuperation des erreurs— Commentaires positifs/negatifs des utilisateurs— Evaluation du domaine

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les exigences d’utilisabilite se definissent selon un ensemble de criteres propres a l’uti-lisabilite. Ces criteres sont listes ci-dessus. Ils se definissent selon l’ensemble des taches quel’on doit effectuer avec l’application et peuvent aussi etre ponderes tout comme les tachespeuvent l’etre.

On peut determiner les exigences quant a l’utilisabilite en se basant sur differentes ap-proches, par exemple :

— les applications concurrentes : en particulier lorsque le produit est en vente libre ;— les objectifs d’affaires : lorsque l’entreprise paye pour un developpement et vise un

gain de productivite ; un calcul couts-benefices permettra de fixer des objectifs detemps d’execution, par exemple ;

— les contraintes de securite : pour les systemes critiques— comparaison avec d’autres versions : permet de valider si l’utilisabilite s’ameliore ou

non.

Exercice

— Emilie de Bell— Tablette pour commander au restaurant— Refonte de l’interface de vente de livres a Poly

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

Documents

LOG2420 | Analyse et conception d’interfaces utilisateur ... · attentes. Un processus adapt e au d eveloppement d’application interactive doit investir bien ... 1.Les exigences,