Yu Centrik

Lors de l’évaluation d’interfaces graphiques, de type site web, j’applique entre autre, les heuristiques de Bastien/Scapin et Nielsen et j’analyse la structure du système au travers d’une architecture de l’information. Une page du site visualisée à l’écran a donc son équivalent schématique dans l’architecture.

Il y a une correspondance entre le produit et sa modélisation. Tous deux sont bidimensionnels et la navigation est similaire entre l’application et sa représentation ; les actions de l’utilisateur peuvent ne pas être successives les unes aux autres ni liées entre elles.

Récemment, nous avons été amenés à poser un diagnostic sur une interface vocale. Il s’agissait d’un service téléphonique de renseignements automatisés.

Par opposition au support visuel persistant des applications graphiques, l’information recueillie lors de l’écoute des segments vocaux d’un système téléphonique ne permet pas d’être retenue en totalité. Le recours à la représentation graphique devient donc indispensable. Une schématisation de la structure, de la navigation et du contenu des messages a ainsi permis de comprendre l’expérience utilisateur au sein du processus.

Cela dit, il peut se créer, à ce moment de l’évaluation, un conflit.
Il n’y a, en effet, plus de correspondance entre le produit et sa modélisation puisque l’étude de l’application vocale se fait principalement au travers du support de travail visuel.

Or, ce que l’on voit schématiquement est entendu par l’utilisateur et ce, de façon séquentielle ; chaque instruction en suit une autre et l’appelant ne peut naviguer dans l’application comme il le fait sur un site web.

La schématisation a alors, en quelque sorte, tendance à minimiser l’ampleur de l’effort auditif, mnésique et attentionnel fourni par l’usager et la contrainte pas-à-pas de l’application.

C’est pourquoi, j’ai toujours dû garder à l’esprit qu’étant donné la seule exploitation du mode auditif, chaque message ou option proposé demanderait un traitement cognitif plus important à l’utilisateur pour être entendu, écouté, assimilé et compris.

Il en est de même à l’étape du design ; chaque modification au sein de l’application devrait être testée auprès d’utilisateurs pour juger de sa pertinence « auditive ».

Ainsi, nous devons toujours faire attention au support utilisé pour nos évaluations et adapter notre analyse en fonction du type d’interface étudiée et des exigences cognitives qu’elle demande à l’utilisateur.

Tous les professionnels, qu’importe leur domaine, cherchent des moments de bonheur. Ce sont ces moments qui nous font rappeler les raisons pour lesquelles on a choisi un certain métier.

J’ai réalisé, il n’y a pas longtemps, qu’il y a deux de ces moments pour moi, qui font le bonheur de l’ergonome des interfaces que je suis.

Le premier, c’est lorsqu’on conçoit un objet ou un élément dans une interface qui est tout de suite compris et apprécié par les utilisateurs lors des tests d’utilisabilité. C’est très gratifiant de voir qu’on a été capable de comprendre le modèle mental des utilisateurs.

Le deuxième, c’est exactement la situation inverse. Lorsqu’on fait un test et que les utilisateurs trouvent que ce qu’on a conçu ne fait pas de sens et nous suggèrent des bonnes solutions, ça nous allume et nous rappelle que nous sommes les concepteurs et non les utilisateurs finaux du produit.

Et ça c’est la leçon la plus importante pour ceux qui envisagent travailler dans ce domaine.

À titre de praticien dans le domaine des interfaces, je me bute souvent à un problème de vocabulaire quand vient le temps de parler, justement, des interfaces.

Une partie du problème s’explique par le fait que les meilleurs guides d’interfaces ne sont disponibles qu’en anglais, ainsi nous devons la plupart du temps traduire, des fois maladroitement, les termes liés aux composantes de l’interface, ou s’en tenir à des exemples visuels. Quand vient le temps de rédiger un rapport, ou de communiquer avec un collègue, je me bute fréquemment à l’absence d’un équivalent français, ce qui peut occasionner des discussions de la sorte : « Le drop-down, il devrait être ici, sinon ton header va être désorganisé. Puis, ça… pourquoi t’utilise ce widget là ? ». Pour l’élégance on, repassera. Parfois, le problème est plus existentiel. Pour une composante d’interface plus obscure - et il y en a! -, il m’arrive de chercher simplement le mot, anglais, français ou chinois, peu importe, pour le désigner, mais je n’y arrive pas. Le réflexe de l’exemple visuel revient alors vite au galop.

C’est pour cette raison que je me suis proposé : pour le bien de mes collègues et clients - et bien sûr, égoïstement, pour ma propre personne -, j’ai décidé de documenter une liste de termes que nous utiliserons tous chez Yu Centrik. Finis, donc, ces ambiguïtés et ces anglicismes émanant d’une terminologie dont l’évolution échappe même au linguiste le plus « workaholic » !

Bien entendu, le travail s’annonce ardu (dans quoi me suis-je embarqué encore !). En attendant la complétion de l’ouvrage, voici quelques suggestions de ressources, officielles ou non, pour ceux qui, comme moi, sont parfois à court de mots. N’hésitez pas à nous faire parvenir les vôtres !

Ressources francophones

Grand dictionnaire terminologique (Office québécois de la langue française)
Pratique pour trouver le mot français « officiel ».

Le Signet informatique
Outil spécifique aux TI et dont les données sont issues du dictionnaire terminologique de l’OLFQ.

À L’aide
Dictionnaire généraliste comportant une partie dédiée aux interfaces.

Lexique des néologismes Internet
Équivalents français du jargon de l’Internet.

Le jargon français (Linux France)
Quelques termes liés aux interfaces, mais pas toujours traduits.

L’ergonomie à la DSI (CNRS – France)
Plusieurs ressources intéressantes sur l’ergonomie, dont un guide en format PDF intitulé « La terminologie de l’ergonomie et des interfaces hommes-machines ». Bien que daté de 1998, le document demeure d’actualité malgré l’absence de termes plus récents.

RIFF News
10 pages de termes allant de l’évident (« menu ») au plus obscur (« OSF/Motif »). Certains aspects historiques intéressants.

Ressources anglophones

Glossaire des normes d’interface Apple
Bonne liste de mots importants, et plusieurs nouveautés. Certains termes sont spécifiques aux Macs seulement.

Glossaire – lignes directrices pour la conception d’interfaces – NASA
Une liste fiable de termes généraux. Un peu daté (1996).

Livre : Designing Interfaces (Jennifer Tidwell)
L’auteur décrit et donne un nom à certains « patterns » d’interfaces, dont plusieurs sont plus récents.

Depuis quelques années, on observe une présence grandissante de la fonction qui permet de changer la taille du texte d’une page Web. Elle est surtout présente dans les sites de nouvelles, où la quantité de texte est importante et où la lecture est le but principal de l’utilisateur.

Malgré l’existence de cette même fonction dans les fureteurs les plus populaires, le fait de la placer visuellement en évidence dans les pages est très apprécié, parce qu’elle accommode grandement les personnes ayant une difficulté de lecture.

Aujourd’hui, il n’existe pas de standard en tant que tel quant au format à suivre pour la représentation d’une telle fonction. Un tour rapide d’une dizaine de pages Web en différentes langues nous donne un aperçu de la variété des formats existants.

Au moment de choisir la représentation graphique et d’établir le comportement de cette fonctionnalité, le concepteur doit considérer quatre éléments
essentiels :

1) La nature, les besoins et les caractéristiques du public cible auquel cette fonctionnalité s’adresse :
Une fonctionnalité de changement de taille du texte a pour but d’offrir un confort de lecture aux utilisateurs. La lecture à l’écran devient difficile lorsque la personne n’a pas une vue parfaite. Les pathologies sont variées, allant de la presbytie commune et due au vieillissement, à des troubles de vision plus graves comme par exemple la vision périphérique ou la vision en tunnel. Pour quel niveau de lecture cette fonctionnalité sera-t-elle utile? Pour une vision en tunnel, il faudra permettre une diminution de la taille du texte équivalant à une police de caractères 5 ou 6, alors que pour un problème de vision périphérique, on peut parler d’une augmentation possible de 500% de la taille du texte. Sur les sites réellement destinés aux personnes ayant une déficience visuelle, il est possible d’augmenter et de diminuer le texte à l’infini et de changer la couleur du fond de l’écran et du texte. Dans la majorité des sites Web, la fonctionnalité d’augmentation ou de diminution du texte s’adresse aux utilisateurs ayant besoin de grossir un peu les caractères à l’écran et non aux personnes vivant avec une déficience visuelle. On comprend donc l’importance de bien prendre en considération les caractéristiques des utilisateurs du site.

2) Le comportement et la représentation visuelle :
Tout dépendant du but à atteindre, l’outil doit permettre d’agrandir et de diminuer la taille du texte avec la plus grande flexibilité possible. Si les changements sont limités à un nombre de tailles prédéterminées, nous recommandons de ne pas utiliser les boutons (+) et (-) mais plutôt les lettres qui représentent mieux le nombre d’agrandissements ou de diminutions possibles. Comme toute autre fonctionnalité offerte, il faut que l’effet résultant de l’utilisation de cette fonctionnalité ainsi que ses limites soient sans ambiguïté.

Voici quelques exemples :

On constate ici une forme de rétroaction lorsqu’un des items a été sélectionné.

Ici l’expression de la rétroaction peut être ambiguë : est-ce que c’est le petit A qui a été sélectionné (avec le fond bleu) ou le grand A (en gras) ?

Quel A est sélectionné ? Ce n’est pas assez évident.

Ici on se demande où on doit cliquer et quel élément a été sélectionné.

Ce type de représentation doit être utilisé lorsqu’on permet aux utilisateurs de modifier la taille sans limite. On doit favoriser l’utilisation du symbole (+) à droite, comme un rappel de dispositifs du monde réel où on peut augmenter et diminuer le volume, par exemple.

Ces modèles sont les moins compréhensibles.

3) « L’affordance » et la rétroaction :
Qu’importe le modèle choisi, l’utilisateur doit savoir où cliquer. Il faut aussi que les pictogrammes/lettres/images aient suffisamment d’incitation ou « d’affordance » comme c’est le cas des boutons cliquables. Certaines représentations offrent une seule possibilité (une augmentation, une diminution), d’autres offrent plusieurs variantes de tailles, d’où l’importance d’avoir une bonne rétroaction de l’état présent et une bonne incitation pour le rétablissement de la valeur par défaut.

4) La localisation :
Comme cette fonctionnalité est une aide à la lecture, il ne faut pas la cacher dans la page. Elle doit être évidente et visible afin de permettre un repérage immédiat par l’utilisateur.

Il est vrai que de façon générale une personne vivant avec une déficience visuelle aura déjà installé sur son ordinateur une suite de logiciels d’aide à la vision. Est-ce une raison pour ne pas s’en préoccuper ?

En conclusion, même s’il n’y a pas de standard, nous recommandons aux concepteurs de ne pas faire un choix arbitraire sur le type de modèle à appliquer. Chaque situation est différente et les choix de conception doivent toujours être justifiés.

PS : merci à Joëlle et à Chrystel pour la contribution à l’écriture de cet article.

Le concept des personas semble de plus en plus populaire auprès des spécialistes en stratégie d’affaires électroniques, comme en témoigne l’article récent paru dans la version électronique du journal Les Affaires: Personas … Grata.

Rédigé par M. Renaud d’Adviso Conseil, cet article démontre l’intérêt de cette méthode lors de la mise sur pied d’une stratégie de e-commerce.
Il est intéressant de souligner ici que cette entreprise, qui n’est spécialisée ni en ergonomie ni en utilisabilité, est assez sensible à la chose pour en faire la promotion, ce qui n’est pas pour nous déplaire : ) …

Yu Centrik applique la méthode des Personas quasi systématiquement chez ses clients depuis plus de deux ans. Il y a belle lurette que j’ai entendu un client référer à un “segment de clientèle”, ou à “son internaute moyen” pour parler des besoins et attentes de ses consommateurs. La référence aux utilisateurs en tant que consommateurs a très nettement évolué; tellement, que nos clients parlent plus de Gérard ou Suzanne que du “segment de population active 35-44 ans” ou encore de Brian ou Julia plutôt que des “adolescents 12-17 ans”.

De plus, nous observons que l’autoréférencement est presque révolu en ce sens que nos clients ne se prennent plus eux-mêmes pour leurs utilisateurs, ce qui était fréquent autrefois, et qu’ils adhèrent avec un bonheur quasi palpable à ce concept.

Donc, en complément à l’article écrit par M. Renaud, je voudrais apporter une petite précision: il ne suffit pas de colliger des données sur sa clientèle, d’en extraire trois ou quatre profils et de leur donner un nom pour dire qu’on a appliqué la méthode des personas. Les personas sont l’une des activités clés d’une méthode globale de conception centrée sur l’utilisateur, c’est-à-dire qu’ils n’assureront le succès de votre produit que si vous concevez en vous centrant sur les buts et les tâches de vos personas et que vous vivez avec eux tout au long du projet.

Pour ce faire vous devez procéder à une série d’activités inhérentes au processus de design centré sur l’utilisateur (DCU) et surtout ne pas perdre de vue que les données que vous allez recueillir lors de l’analyse ethnographique doivent vous permettre de définir trois choses essentielles comme le suggère M. Robert Reimann, interviewé dans un livre de Dan Saffer, Designing for Interaction (paru en juillet 2006) :

1) les buts d’expérience, qui décrivent l’expérience que souhaite ressentir (ou pas) un utilisateur donné lorsqu’il utilise le produit;

2) les buts finaux, qui décrivent ce que ces utilisateurs veulent réellement accomplir avec le produit et les résultats qu’ils s’attendent à obtenir;

3) enfin, les “buts dans la vie“, qui décrivent les aspirations à un sens plus large du persona en relation avec le produit, et donc nous aide a décrire ce que représente le produit pour le persona.

C’est en se penchant sur les buts et les patterns de comportements, et en combinant cette approche avec la méthode des scénarios qui permet de traduire ces buts sous forme de fonctions et de solutions de design que l’approche des personas de Cooper est si puissante.

Si la chose vous intéresse, nous offrons une formation sur les Personas au Centre de Recherche en Informatique de Montréal (CRIM), à Montréal et à Québec.

Voici un commentaire capté sur la liste des abonnés à CHI-CONSULTANTS le 25 janvier 2006:
Don Norman (Norman-Nielsen Group) nous dit qu’Agile et les autres méthodologies extrêmes (Extreme Programming) sont là pour rester et qu’il vaut donc mieux nous y adapter… au risque de rater le train de la nouvelle génération d’applications. En fait, le phénomène d’adaptation n’est pas nouveau: les ingénieurs de l’utilisabilité sont par essence même des professionnels qui s’adaptent aux méthodologies appliquées sur les nombreux projets sur lesquels ils interviennent. Chaque ergonome est appelé à adapter ses activités et ses outils aux processus de conception et développement des clients qui font appel à lui.

En ce qui concerne les méthodologies extrêmes, je pense, à l’instar de Don Norman, que nous assistons à un nouveau changement de paradigme. Ce changement est comparable aux autres changements que furent la programmation structurée durant les années 70 et la programmation orientée objet qui, à la fin des années 90 nous imposa le Rational Unified Process (RUP). Le design centré utilisateur (DCU) peut s’adapter à ce changement de paradigme comme il l’a fait avec RUP, mais comme le dit Norman, encore faut-il que la communauté des ergonomes fasse les efforts en ce sens. Nous sommes outillés pour le faire, et surtout habitués à de telles évolutions.

Agile semble contredire les principes du DCU parce qu’il n’y a pas ou très peu d’analyse avant de passer au développement comme tel et que la conception est très intimement liée au développement, ce qui pour nous, ingénieurs de l’utilisabilité, peut donner l’impression qu’on escamote des étapes. En fait, la littérature sur Agile recommande plutôt de procéder à l’analyse contextuelle avant de commencer le projet, en reconnaissant une valeur au recueil d’information sur le terrain, auprès des utilisateurs. Les tenants du développement Agile sont, par exemple, partisans de l’approche Personas de Cooper, et l’accueillent volontiers dans leur méthode.

En conclusion, Agile est-elle une grosse perturbation pour nous autres, praticiens de l’utilisabilité ? Je dis non, et par expérience, il vaut mieux être impliqué sur un projet qui applique une méthodologie, fut-elle extrême, plutôt que sur un qui n’en applique pas. Et encore en 2006, nous l’observons …