Archives par étiquette : methodologie

Interview de Raphaël Yharrassarry – psychologue, ergonome

Pour changer un peu, et peut être parce que je n’ai pas assez de temps pour faire plus d’articles, je change un peu d’exercice pour présenter une première interview, celle de Raphaël Yharrassarry que j’ai eu le plaisir de rencontrer à une réunion du UX Book Club parisien (prochaine évolution, un podcast ou une video ?)

– Bonjour Raphaël, peux-tu te présenter rapidement ?
Raphaël Yharrassarry, 38 ans. Je travaille en Freelance depuis 12 ans environ dans le domaine de l’ergonomie des IHM. J’ai donc réalisé de nombreuses missions de conseils, de conceptions et d’évaluations sur des sujets variés allant des applications professionnelles aux services grand public sur la télévision en passant par le Web et les tablettes.

– Quelles études as tu fais ?
J’ai une formation initiale en psychologie sociale et cognitive, un DESS d’ergonomie à Paris 5. J’ai aussi fait mastère Marketing et Distribution au CNAM en 2008, pour mieux comprendre les problématiques liées à la vente, à la gestion de la relation avec les clients. En dehors des études, je suis autodidacte tous les aspects liés à l’informatique. En effet, j’ai eu la chance de grandir avec l’informatique. Mon père avait ramené à la maison un Mac. J’ai rapidement compris l’avantage que l’on pouvait en tirer en termes de productivité.

– Te considères-tu comme un ergonome ? Un designer ? Un spécialiste UX ?
La dure question du titre ! Sur ma carte de visite, il y a marqué « psychologue, ergonome ». « Psychologue » car c’est un titre protégé, il faut un bac +5 en psychologie pour pouvoir l’utiliser ce qui est mon cas. Ça évite les confusions sur le niveau de formation. « Ergonome » car toute mon activité est basée sur une connaissance la plus fine possible des usages et des utilisateurs. Designer, pas vraiment car je n’ai pas une formation de design « industriel », et je ne vais pas « dessiner » un service, je vais le concevoir de manière très scientifique, un peu froide. « UX » c’est le terme à la mode actuellement. Je l’utilise effectivement, le problème c’est que c’est un titre « fourre-tout » recouvrant bien des compétences et des incompétences.

– D’où vient cette passion ? Pourquoi avoir choisi cette voie ?
Au début de mes études, je pensais travailler dans les ressources humaines. Puis en maîtrise j’ai eu un cours sur l’ergonomie de M. Spérandio. Là, j’ai rapidement compris que c’est cela que je voulais faire, de la conception avec une préoccupation constante pour les utilisateurs et la nécessité d’avoir des connaissances approfondies en facteur humain.

– A quoi correspond ton métier de tous les jours ? Pourrais-tu décrire rapidement la journée d’un ergonome ?
Fais-tu beaucoup de prototypage ? Si oui quels outils utilises-tu ?
Il n’y a pas vraiment de journée type, surtout en Freelance ! Donc oui, je fais beaucoup de prototypage, soit directement en HTML/CSS avec Dreamweaver, soit avec Balsamiq pour un premier brouillon. Le papier/crayon reste une valeur sûre pour échanger autour d’une table. J’utilise Illustrator pour faire des interfaces sur la TV, car les logiciels classiques (Axure, Balsamiq,…) ne proposent pas de gabarit pour la TV.

– As-tu un processus ou une méthodologie précise ?
Oui, mais c’est un peu compliqué à expliquer en deux lignes. Ce qu’il faut retenir, je pars du plus large pour arriver au plus précis. En quelques étapes :
– Analyse de l’activité, connaissance des usages, des utilisateurs
– Modélisation du service : quels sont les objets manipulés ? Quelles actions sur ces objets ?
– Application du Guidelines de la plateforme : iOS, Windows, Web, etc. Et quand il n’y en pas comme sur la Tv, il faut le créer.
– Structure du service : Menu, Ecrans principaux, Dialogue, …
– Spécifications détaillées.

Je te renvoie à cet article sur mon blog pour plus détails : http://blocnotes.iergo.fr/concevoir/concevoir-une-application-wimp-le-processus/

Ça, c’est la méthodologie, différents outils interviennent suivant les besoins, le temps ou les contraintes (Test utilisateurs, Personnas, expérimentation, audit, maquette, etc.)

– Quelles sont les principales difficultés que tu rencontres dans ton métier ?
Le management des entreprises est généralement issu des écoles de commerce ou d’ingénieurs. Le facteur humain, les IHM, l’expérience utilisateurs sont des domaines qui leur sont complètement inconnus. Il y a donc rarement une volonté profonde de mettre l’utilisateur au centre de la conception. Il suffit de regarder l’organisation des entreprises, combien d’entre elles ont une direction « UX, Design, Facteur humain » ? La montée en puissance d’Apple depuis 10 ans, commence à faire évoluer les choses, mais c’est long, très long.

– As-tu des conseils à partager pour les ergonomes actuels ou futurs ?

Des conseils ? Personnellement, je tiens beaucoup à l’aspect logique, scientifique de la conception d’IHM et aux méthodes liées facteurs humains. Ça permet de tenir le cap pendant que les modes passent. Aujourd’hui on parle d’UX, hier d’architecture de l’information, demain sans doute d’autres choses, mais les théories de la Gestalt seront toujours vraies !

– Comment évolue le métier d’ergonome ? Comment vois-tu ton métier dans 10 ans ?
Les deux questions vont ensemble. Depuis 10 ans, le niveau des demandes c’est peu à peu élevé, passant de « la couleur de la moquette » à des problématiques réelles d’ergonomie. La demande a souvent pour origine les utilisateurs eux-mêmes qui se rendent compte que l’on peut faire mieux ! Pour les 10 ans avenirs, j’aurai du mal à faire des prédictions, mais il me semble que cette progression va continuer. Ça implique aussi des changements en termes de marché de l’ergonomie et de l’expérience utilisateur qui passe d’un marché de niche à un marché plus large.

– As-tu des livres, sites ou blogs à conseiller ?
Blog :

http://www.interaction-design.org/ Des articles de références.
http://www.measuringusability.com/ Beaucoup d’articles sur la validité des questionnaires, tests utilisateurs et les statistiques
http://www.gargarismes-ergonomiques.com quelques ressources intéressantes.

Livres :
Card sorting de Gautier Barrère et Éric Mazzone qui est sorti récemment :
http://www.editions-eyrolles.com/Livre/9782212134483/card-sorting
Search Analytics for Your Site, Louis Rosenfeld
http://rosenfeldmedia.com/books/searchanalytics/

 

Principes de design d’une interface graphique

Enfin ! Cette article aura eu du mal à sortir du mode brouillon et d’ailleurs certaines parties sont encore à retravailler (n’hésitez pas à laisser des commentaires).

L’année dernière, alors que je demandais des conseils de lecture à un ami Ergonome, celui-ci me conseille fortement GUI Bloppers. Je me le commande et je reçois un livre très sommaire dans sa mise en page et pas très sexy.

La grande majorité du livre concerne des « meilleurs pratiques » très précises pour la réalisation d’une interface graphique (jusqu’au nom de la barre de titre des fenêtres !). Si l’ensemble regorge de détails pratiques très intéressants, c’est surtout l’introduction qui m’attire le plus et que j’ai décidé de résumer ici !

Jeff Johnson y présente 9 principes de design d’une interface graphique. Travaillant actuellement sur l’expérience utilisateur d’un des plus gros site d’eCommerce français, ces principes à la fois simple, très pragmatique et tellement efficace révèlent une importance toute particulière. Je pense sincérement qu’ils meritent d’etre connus et appliqués pour créer une meilleure expérience utilisateur et pour faciliter la réalisation d’une interface graphique.

1er principe : Se concentrer sur l’utilisateur et sur ses tâches non sur la technologie
Pour pouvoir appréhender l’utilisateur et ses tâches, il faut d’abord se poser les questions suivantes :
– Quels sont les utilisateurs ?
– Quel est l’intérêt du programme ? Quels problèmes va-t-il résoudre ?
– Quels sont les problèmes de l’utilisateur ? Qu’aime-t-il ou pas dans sa façon de travailler actuellement ?
– Quels sont les compétences de l’utilisateur ? Sont-ils prêts à apprendre ? Y a-t-il différents types d’utilisateurs ?
– comment les utilisateurs se représentent les données que le programme va gérer ?
– Quelles sont les façons préférées de travailler ? Comment le programme va s’adapter ou les changer ?

Le but de ces questions est d’abord de comprendre l’utilisateur. La réponse se construit autour de trois composants : décisions d’entreprise, investigation empirique et collaboration.

Décisions d’entreprise : l’entreprise doit décider quels seront les principaux utilisateurs pour son produit. On parle de choisir une cible primaire. Attention le client (département des ventes ou marketing) ne représente pas toujours les utilisateurs.

Investigation empirique : il faut connaître les caractéristiques de cette cible primaire.. Comment ? En parlant avec eux, en les observant, avec mettant en place des groupes de travail, en parlant avec leur managers.
En ce qui concerne les utilisateurs, il faut savoir qu’il n’y pas une séparation nette entre débutants et experts. Il faut plutôt considérer 3 dimensions :

  • la personne calée en informatique de façon générale
  • l’expert de la tâche
  • la connaissance du système ou du produit

Il faut aussi se poser la question pourquoi l’utilisateur veut utiliser votre produit ? travail ? personnel ?

Collaboration : amener les utilisateurs cibles dans votre équipe pour mieux les connaître, traiter les comme des experts.

Créer des Personnas

Le but de ces trois étapes est de créer un ou des profils avec des informations plus générales. On peut aller plus loin en créant des “personnas”.

Comprendre la tâche s’articule aussi autour de trois composantes.


Décision business : décider l’ensemble des tâches que l’on souhaite gérer dans le produit. Cette décision est influencée par les buts stratégiques de l’entreprise, l’expertise de ces employés, son influence passée, son histoire, ses processus, son infrastructure, sa perception des opportunités du marché, des niches ou encore les nouvelles technologies venant de la recherche.
Investigation empirique : analyser les tâches visées. Cette analyse des tâches a pour but d’apprendre comment les utilisateurs réalisent les tâches que le programme va gérer. La meilleure façon de faire cette analyse est d’observer les utilisateurs, faire des interviews, comprendre avant l’introduction du nouveau produit, faire des spéculations sur l’utilisation future.
L’interview et l’observation sont complémentaires. L’interview peut introduire une désinformation en mettant en avant comment le produit pourrait marcher. Lors de l’observation, on interprète ce que l’on voit.
Collaboration : discuter avec l’utilisateur de vos premières analyses et conclusion permet d’aller plus loin. Le retour d’information est dans les deux sens : les utilisateurs apprennent aussi comment il travaille et découvre les technologies qui pourraient les aider.
L’ensemble de ce processus permet de répondre à des questions précises :

  • Quelles tâches concernent la zone d’application du programme ?
  • Quelles sont les tâches communes et les rares ?
  • Quelles sont les étapes de chaque tâche ?
  • Quel est le résultat et la sorte de chaque tâche ?
  • D’où proviennent les informations pour chaque tâche et comment l’information résultant de chaque tâche est utilisée ?
  • Quelles personnes font quelles tâches ?
  • Quels sont les problèmes rencontrés lors de la réalisation de la tâche ? Quelles sont les erreurs les plus communes ? Quelles en sont les causes ? Quelles sont les conséquences ?
  • Quelles sont les terminologies utilisées ?
  • Comment sont reliées entre elles les différentes tâches ?
  • Quelle communication est nécessaire entre les personnes pour réaliser les tâches ?

Enfin il faut prendre en compte le contexte, par exemple que les données peuvent venir d’un autre programme, et ne pas avoir une vision centrée sur la technologie .

Principe 2 : Considérer la fonction en premier, la présentation ensuite.

L’erreur est souvent de décider à quoi va ressembler l’interface avant de définir ces fonctionnalités. Certains utilisent des outils de maquettage, d’autres des outils de création de GUI interactif, certains se lancent directement dans l’implémentation. Le point commun est de commencer par travailler sur la présentation directement. Cependant l’interface utilisateur d’un programme n’est pas seulement une question de présentation. Une décision de design concerne l’ensemble de l’architecture : Quels concepts montrer aux utilisateurs ? Comment structurer l’information ? Quels traitement en arrière plan ? Quelle customisation possible ?
Considérer la fonction en premier signifie que le designer doit clairement définir les concepts du logiciel et les relations entre ces concepts. On ne peut sauter directement sur la disposition de l’interface sans d’abord répondre aux questions liées aux tâches.

Le modèle conceptuel.


A partir des questions ci-dessus, il est important d’enregistrer et d’organiser la connaissance qui en résulte de façon à aider le design d’une interface graphique. La plus utile est de développer un modèle conceptuel : le modèle que le designer veut que les utilisateurs comprennent.

En utilisant le logiciel ou en lisant la documentation, les utilisateur se construisent un modèle de son fonctionnement ou modèle d’interaction. Si le modèle du designer et de l’utilisateur sont les mêmes alors le design est bon. Un modèle n’est pas exprimé en terme de concepts d’interface graphique mais autour :

  • des données que l’utilisateur manipule
  • de l’organisation de ces données
  • de ce que l’utilisateur fait avec ces données

Développer un modèle conceptuel est difficile car on est tenté de le définir directement en terme d’interface utilisateur notamment à cause de la tendance du marketing de voir les besoins fonctionnels en terme de disposition de l’interface et de clics de souris.
L’idée est en qu’en construisant avec attention un modèle conceptuel explicite et ensuite en créant l’interface graphique à partir de ce modèle, le logiciel en résultant sera plus propre, plus simple et plus facile à comprendre.
“As simple as possible, but no simpler” Albert Einstein

Se concentrer sur la tâche.
Le modèle conceptuel doit être aussi simple que possible. Il faut se concentrer sur les tâches avec des concepts familiers pour l’utilisateur. Par exemple, pour designer un logiciel de création et de management d’organigramme d’entreprise, il faut mieux utiliser un ensemble d’organisations, sous-organisations et employés plutôt qu’un ensemble de boites, labels et de connecteurs.
Il faut résister à la tentation d’ajouter de nouveaux concepts (“less is more” – Mies van der Rohe). L’ajout d’un nouveau concept est couteux pour deux raisons :
– l’expert de la tâche ne le reconnaîtra pas et devra donc l’apprendre
– il interagit potentiellement avec tous les autres concepts du système. L’ajout d’un concept ne fait pas augmenter la complexité globale de façon linéaire mais de façon exponentielle.

Faire une analyse des objets et des actions.
L’élément le plus important d’un modèle conceptuel est l’analyse des objets / actions. C’est à dire spécifier tous les objets conceptuels qu’une application va exposer à ces utilisateurs, les actions possibles sur chaque objet, les actions possibles sur chaque type d’objets et leurs relations. L’application peut introduire d’autres objets mais ils ne doivent pas être visible. L’analyse des objets / actions est donc une déclaration des concepts exposés à l’utilisateur.
Exemple pour la fonctionnalité “gérer un compte” les objets sont “virement” et “compte” et les actions possibles : écriture, déposer ou retirer de l’argent.

Relation entre objets.
Un des rôles importants de l’analyse des objets / actions est de définir et représenter les relations entre les objets. Les objets du domaine forment habituellement une hiérarchie de type par exemple un compte courant est un type de compte bancaire. Faire en sorte que cette hiérarchie soit claire dans le modèle conceptuel permet de mieux la comprendre et de mieux la présenter aux utilisateurs. Cela permet aussi de déterminer des actions génériques et donc de rendre l’interface plus facile à apprendre. Plutôt que d’avoir une longue liste de commandes spécifiques, on peut avoir un petit nombre de commandes qu’on peut appliquer à travers les objets. Suivant les applications, les objets peuvent être aussi mis en relation par des hiérarchies d’éléments et d’ensemble : par un exemple un document possède un en-tête ou un album photos contient des photos. Enfin les objets peuvent être mis en relation en fonction de leur importance.
Plus la relation entre les opérations du système et la tâche qu’ils servent est directe, plus votre modèle conceptuel à des chances d’être adopté par les utilisateurs.

Développer un lexique.
Après l’analyse des objets / actions, le plus important dans un modèle conceptuel est le lexique qui nomme chaque concept que l’utilisateur peut rencontrer. Une fois que l’équipe est d’accord sur les concepts visibles, il faut se mettre d’accord sur la dénomination de ces concepts afin de maintenir la cohérence.

Écrire des scénarios de taches.
Il est utile de définir des scénarios de tâche ou cas d’utilisation. Ces scénarios peuvent être utilisés dans la documentation du produit, dans les revues fonctionnelles ou pour les tests.

Une fois le modèle conceptuel défini, on peut alors construire le design graphique de l’interface utilisateur. Les concepts abstraits sont alors traduits par une présentation concrète et des actions utilisateurs.
On peut aussi remarquer la similarité flagrante entre l’analyse des objets/actions et l’analyse orientée objet en programmation. Le modèle conceptuel défini lors du design de l’interface peut donc tout à fait servir pour le développement du logiciel. Ce n’est donc pas un coût supplémentaire pour le projet … au contraire !

Principe 3 : se conformer à la vision de la tâche par l’utilisateur.

Les interfaces utilisateurs devraient être désignées suivant le point de vue de l’utilisateur. Pour connaître celui-ci le mieux est justement de discuter avec l’utilisateur, de l’observer et de collaborer (comme expliqué dans le 1er principe). Se conformer à la vision de l’utilisateur a plusieurs sous principes.

Faire en sorte que ce soit naturel.
Les actes non naturels sont des étapes que l’utilisateur doit réaliser alors qu’elles n’ont pas de connexion directe avec sa tâche. Ces actions sont considérées difficiles à apprendre, facile à oublier, consommatrice en temps et ennuyeuses.
On peut prendre l’exemple d’un jeu d’échec. L’utilisateur n’a besoin que de sélectionner la pièce et indiquer la destination. Les actes non naturels pouvant s’intercaler sont nombreux : passer à un mode de mouvement, donner un nom ou une raison à ce mouvement dans le cadre d’un historique ou une analyse à posteriori, spécifier quel jeu dans le cadre de plusieurs plateaux. Déplacer une pièce au échec est une tâche simple mais un logiciel peut facilement la rendre complexe en y ajoutant des étapes supplémentaires non naturelles.

Ne pas imposer des restrictions arbitraires.
se conformer à la vision de la tâche par l’utilisateur implique de ne pas imposer des restrictions arbitraires comme limiter le nom d’une personne, limiter le trie des lignes d’une table à maximum trois colonnes ou encore fournir un retour en arrière pour seulement trois opérations.

Utiliser le vocabulaire de l’utilisateur non le sien.
Il faut garder les concepts relatifs au fonctionnement du programme à l’intérieur de celui-ci et ne pas les exposer à l’utilisateur. L’utilisateur n’est pas intéressé par le fonctionnement du programme.

Il faut aussi trouver le bon point entre complexité et puissance.
L’erreur est de penser que plus il y a d’options, des contrôles, de puissance mieux c’est ! Les utilisateurs se concentrent sur les fonctions utiles pour atteindre leur objectif. Plus il y a des fonctionnalités avec une faible importance, plus les fonctionnalités réellement importantes ont moins de chance d’être apprises et utilisées.
Les solutions sont d’utiliser :

  • des valeurs par défaut
  • des modèles ou des solutions clé en main
  • des wizards avec un chemin
  • une divulgation progressive afin de cacher les détails tant que l’utilisateur n’en a pas besoin
  • des commandes génériques
  • un design spécifique au tâche (supporter un petit nombre de tâche extrêmement bien)
  • customisation

Principe de base 4 : gérer l’accès et la visibilité des fonctions.
Quelque soit le domaine de la tâche, les utilisateurs ont des buts allant du commun au rare. Il faut faire en sorte que les buts communs soient faciles à atteindre. La somme de travail nécessaire à une tâche ne doit pas être proportionnel à la complexité de celle ci. Celle ci doit être proportionnel au fait quelle soit commune ou non, par exemple dans un restaurant on peut demander d’être servi “comme d’habitude”. L’objectif est donc de réduire la complexité pour les tâches communes (en utilisant les solutions évoqués dans le troisième principe).
Il y a deux aspects définissant une tâche commune : le nombre d’utilisateurs contre la fréquence d’utilisation.
Plus une fonction est utilisée, moins elle doit nécessiter de clic. Par exemple, l’installation peut se permettre d’avoir beaucoup d’étapes. Plus il y a d’utilisateurs, plus la fonction doit être visible. Une fonction peu utilisée par peu de personnes ne doit prendre du temps à la conception.

Fréquence d’utilisation / nombre d’utilisateurs Par la majorité Par quelques uns
Fréquemment Hautement visible et peu de clics A peine visible et peu de clics
Rarement A peine visible et plus de clics OK Caché / plus de clics Ok

Principe de base 5 : Ne pas distraire les utilisateurs de leur tâche.

Notre capacité a être multitâche est limitée. Une activité complexe et surtout qu’on ne maîtrise pas nécessite concentration et attention. C’est pour cette raison qu’il ne faut pas contraindre l’utilisateur à s’occuper du logiciel. Ce dernier doit se trouver en arrière plan derrière la tâche fonctionnelle. Il faut aider à l’exécution de la tâche ou la résolution de problèmes liés à celle ci tout en minimisant le temps que l’utilisateur passe à résoudre des problèmes liés à l’informatique.
Il ne faut pas forcer l’utilisateur à résonner par élimination. Par exemple un service bancaire demandant un PIN alors que l’utilisateur a un mot de passe.

Principe de Base 6 : faciliter l’apprentissage.


La pensée classique est “inside-out” : le designer pense que l’utilisateur va obligatoirement comprendre qu’elle est le but d’une fonction. La plupart des designers assument que les utilisateurs perçoivent et comprennent tout de l’intention du designer (exemple du do it bouton sur les stations de travail Lisp ou le verre de martini / antenne).
La bonne façon est de penser “outside-in”. Il faut designer en faisant en sorte que l’interface utilisateur est un sens pour la personne qui ne connaît pas tout.
L’utilisateur ne connaît pas vos intentions, ne connaît pas les différentes significations de chaque élément de l’interface. L’interface utilisateur doit avoir un sens pour l’utilisateur, non pour le designer.
Le designer doit favoriser la cohérence. Les incohérences forcent l’utilisateur à penser au système et le détourne de sa tâche. Il faut essayer de mettre en place des commandes génériques ou développer une interface utilisateur similaire en réutilisant des éléments pour différentes fonctions (notamment grâce au développement du modèle conceptuel).

La cohérence est un sujet difficile, plus qu’on ne le pense :

  • difficile à définir
  • multidimensionnel : un élément cohérent dans une dimension (ex. la fonction) peut être incohérent dans une dimension (ex. la localisation)
  • sujette à interprétation : l’idée de la cohérence peut être différente suivant les utilisateurs.

Cependant elle ne doit pas être laissé de coté. Les utilisateurs sont prêt à dépenser de l’energie physique afin de réserver l’effort mental pour leur tâche (“j’étais pressé donc j’ai pris la méthode la plus longue”).
Il faut que la cohérence soit centrée sur l’utilisateur (interview, observation, prototypage).
Il faut fournir un environnement avec peu de risques afin de favoriser l’exploration et l’apprentissage. les erreurs doivent être difficile à faire et facile à corriger afin de réduire le stress.

Principe 7 : fournir de l’information, pas simplement de la donnée.


L’important est de se concentrer sur les données importantes et en extraire l’information (ex. si on veut savoir si le collègue est dans le bureau d’à coté .. la seul information importante est le oui ou non quelque soit la méthode utilisée).
Il faut aussi designer l’écran avec attention et précaution (et si besoin avoir recours à une aide extérieure). Les points importants sont :

  • l’ordre visuel et aider à la concentration de l’utilisateur
  • la possibilité de parcourir des yeux
  • correspondre au média utilisé
  • faire attention aux détails

L’écran appartient à l’utilisateur. Quand le logiciel change trop tout seul, les utilisateurs sont perdus et ennuyés. Il faut préserver l’inertie de l’affichage. Quand le logiciel change l’affichage pour montrer les effets d’un action, il faut essayer de minimiser ce qu’il change.

Principe 8 : Designer pour la réactivité
Depuis plusieurs décennies, les études ont prouvées que la réactivité – la capacité de suivre l’utilisateur et de ne pas le faire attendre – est le facteur le plus important déterminant la satisfaction de l’utilisateur. Lors de l’utilisation d’un ordinateur, les utilisateurs détestent attendre. Cependant on parle de vitesse perçue et non de vitesse réelle. Par exemple, un programme de rendu 3D n’affichant pas la progression pour gagner en vitesse sera perçu comme moins rapide qu’un autre affichant l’image petit à petit. Une interface réactive reste en contact avec l’utilisateur même si elle ne peut répondre immédiatement à sa demande. Elle fournit alors un retour d’information sur ce que le logiciel est en train de faire.
Quelques exemples d’une mauvaise réactivité :

  • un retour d’information en retard lors du clic sur un bouton, de l’utilisation des ascenseurs ou de la manipulation d’objets
  • Une opération longue qui bloque l’interface et ne peut être arrêtée
  • Ne fournir aucun indice sur le temps d’une opération longue
  • Des animations saccadées et dures à suivre
  • Ignorer une entrée utilisateur en effectuant des tâches de maintenance que l’utilisateur n’a pas demandé.

Ces problèmes affectent la productivité des utilisateurs et les frustrent.
L’arrivée du web a été un retour en arrière au niveau de la réactivité en particulier à cause des temps de communication entre les serveurs et le navigateur web ainsi que la limitation de la norme HTML de ne gérer qu’une page. L’arrivée du javascript « asynchrone » ou AJAX ainsi que l’amélioration des performances du coté serveur mais surtout du coté navigateur ont permis de grandement améliorer les choses.

Pour être perçu comme réactif, un logiciel interactif doit :

  • reconnaître une action de l’utilisateur directement même si la réponse prend du temps
  • faire savoir à l’utilisateur si le programme est en cours de travail ou non
  • permettre à l’utilisateur de faire autre chose en attendant qu’une fonction se termine
  • animer un mouvement clairement et de façon fluide
  • permettre à un utilisateur d’arrêter une opération longue qu’il ne veut pas
  • permettre à un utilisateur de juger combien de temps prend une opération
  • faire en sorte que l’utilisateur puisse mettre en place son propre environnement de travail

Principe 9 : Essayer avec l’utilisateur et corriger ensuite !
Il faut tester un produit ou un service avec les personnes qui sont susceptibles de l’utiliser le plus rapidement et le plus fréquemment possible. Ces tests d’utilisabilité sont extrêmement importants pour savoir si le design est réussi, si l’interface aide plus l’utilisateur qu’elle ne le gêne. Les résultats peuvent surprendre même les designers expérimentés et révèlent souvent des problèmes d’utilisabilité non anticipés. Il faut bien sur réserver du temps pour corriger les problèmes remontés par ces tests.
Les tests d’utilisabilité ont en fait deux buts :

– un but d’information qui permet de trouver les aspects de l’interface qui causent des problèmes à l’utilisateur et utiliser la nature exacte de ces problèmes pour suggérer des améliorations.

– Un but social afin de convaincre les développeurs qu’il y a un problème dans le design qui doit être corrigé. Les développeurs résistent souvent au changement en partie du au temps et à l’effort requis mais aussi parce que cela suggère que le design a été mal fait. C’est pour cette raison qu’il est intéressant qu’ils assistent aux tests mais il faut aussi les contraindre à observer passivement et ne pas interférer dans le processus.
Beaucoup pense que les tests d’utilisabilité sont fait juste avant que le produit soit livré. En fait il y a des tests pour chaque étape du développement d’un produit. Ils peuvent être catégorisés en fonction de deux dimensions :
1 l’étape du développement à laquelle le test se produit
2 l’aspect formel de la méthode de tests
Les tests peuvent être effectués avant l’écriture d’une ligne de code, pendant l’implémentation ou quand le produit est pratiquement finalisé. Les tests peuvent être informel comme les sondages, les interviews ou l’observation, quasi-formel quand l’utilisateur doit effectuer une tâche et qu’on collecte des données qualitatives et quantitatives ou formel lorsqu’il y a une étude mesurant principalement des données quantitatives et nécessitant une analyse statistique (en comparant très souvent deux designs).

Experience utilisateur et Agilité – Johanna Kollmann

Résumé de la vidéo suivante : L’importance de l’identité et de la vision pour les designers sur les projets Agile – Johanna Kollmann.

La vidéo présente les résultats d’un sujet de recherche. La méthode Waterfall n’a pas marché pour Johanna Kollmann. Par contre Agilité et Expérience utilisateur semble s’associer parfaitement dus à leurs aspects itératifs et collaboratifs.

Le premier travail est d’intégrer les communautés. Ainsi les designers doivent être des participants actifs ce qui requiert de la flexibilité.

L’étude a été faite avec une approche qualitative autour de deux axes : interviews et observation contextuelle
Il a fallu s’attacher à la compréhension de l’Agilité, des outils utilisés, de l’implication du client ou encore de l’environnement de travail.

Analyse des interviews.

Identité.
Il faut un état d’esprit Agile (flexibilité, simple et efficace).
En Agilité, on part du principe que ce ne sera jamais bon / parfait ce qui n’est pas intuitif dans l’état d’esprit du design.
Malgré les difficultés, les participants pensent que l’approche Agile est la plus intelligente.
Il est important pour les designers de pouvoir parler, faire des retours et trouver des meilleurs moyens de travailler avec les développeurs parce que c’est le nœud du problème.
Il est intéressant d’utiliser esquisses et maquettes pour faciliter la communication
Du à cette collaboration, les rôles ont tendance à se mélanger.
Il est surtout important que chacun comprenne le langage de l’autre.
Le rôle le plus important pour le designer est d’être l’avocat de l’utilisateur final.

Vision
Pour créer une bonne expérience utilisateur, il faut une compréhension du besoin de l’utilisateur final. Cette vision peut être de haut niveau : les valeurs ou les taches principales.
Si cette vision n’est pas correcte, c’est dangereux pour le projet.
Les participants ont trouvé qu’il était difficile d’établir, d’évaluer et développer la vision de l’expérience utilisateur.
Il s’est révélé intéressant voir nécessaire de faire des « interim sprint zeros » afin de s’assurer que le projet est correct du point de vue de l’utilisateur, qu’il avance dans le bon sens et que la liste de priorité est bonne.
Le risque de perdre la vision de l’expérience utilisateur est un des grands désavantages. L’Agilité se concentre sur les livrables et les participants se retrouvent dépassés par manque de temps et perdent la vision d’ensemble au profit des détails. Le risque est de ne plus avoir un produit consistant.
L’Agilité a l’avantage de faciliter la communication et de protéger la vision.
Sous la pression, le plus dur est d’intégrer la perspective de l’utilisateur en faisant une recherche utilisateur.
Différentes stratégies pour inclure cette perspective:

  • travail en amont
  • externalisation avec un designer extérieur
  • faire une recherche légère : tester puis redesigner (ce qui est ressorti comme le plus intéressant)

Intuitions liées à l’observation.

L’identité.
L’importance de l’état d’esprit de l’équipe et de l’organisation à propos de l’agilité et de l’expérience utilisateur.
Les avantages (être un avocat de l’utilisateur) et défauts (beaucoup de temps pour communiquer et peu pour réaliser le travail) d’être un centre de communication

Vision.
L’importance d’une vision claire et partagée par l’équipe
L’Agilité favorise l’utilisation de bons outils de collaboration (par exemple le tableau de questions).

En conclusion, l’attitude des personnes s’occupant de l’expérience utilisateur envers l’Agilité est très important. La collaboration aide beaucoup. Si l’équipe est trop petite ou mal organisée, la partie orientée expérience utilisateur est la première à être compromise. Pour guider les décisions stratégiques et les activités, la recherche utilisateur doit se faire avant que le développement agile démarre.

L’expérience utilisateur de Google Instant

Pourquoi parler de Google Instant sur un blog sur l’expérience utilisateur ?
Finalement il n’y a pas de boutons partout, pas de superbes feuilles de style, pas d’interaction tactile révolutionnaire.

Et c’est pourtant un vrai travail sur l’expérience utilisateur qui a été fait comme le présente l’article du blog officiel de Google.

La principale question a bien été de trouver le bon design ! Bien sur il a fallu travailler la performance, la rapidité d’affichage et de recherche mais le défi de l’infrastructure est arrivé après avoir déterminé la bonne expérience utilisateur. Déterminer le besoin de l’utilisateur et la meilleur façon d’y répondre passe avant le défi technique.
Pour cela, l’équipe de Google Instant à utiliser les techniques classiques de prototypage et un grand nombre d’essais avec des gens de la communauté, avec les employés de Google et avec un petit pourcentage de utilisateurs de Google. L’ergonomie a été considéré comme abouti quand l’interaction et le changement est devenu presque invisible et naturel.

Autre remarque on voit dans un exemple une recherche sur la loi de Fitts. Simple clin d’œil ? 🙂

Mise à jour : Un contre avis sur la méthodologie de Google. Bien sur on est chez un concurrent (Apple) mais le point de vue est aussi intéressant : la vision du design plus que les chiffres et les tests utilisateurs.

Le prototypage

PrototypageLe prototypage est la création de maquettes simples et incomplètes d’un design pour explorer des idées, élaborer le besoin, affiner les spécifications et tester les fonctionnalités. Il y a trois types basiques de prototypage : concept, jetable et avec évolution.

Le prototypage de concept est utile pour explorer rapidement et à bas coût des idées préliminaires de design. Par exemple, les croquis et les storyboards sont utilisés pour développer l’apparence et la personnalité des personnages dans les films d’animation bien avant que les processus d’animation et de rendu soient mis en route. Cette approche permet de communiquer des concepts, révéler les besoins du design et les problèmes ou encore permettre une évaluation par le public visé. Un problème commun avec les croquis est le « problème de réalité artificielle » : la présentation plausible d’un design impossible. Un bon artiste ou modeleur peut faire en sorte que n’importe quel design puisse fonctionner.

Le prototypage jetable est utile pour collecter des données sur la fonctionnalité et la performance de certains aspects du système. Par exemple, les modèles de nouvelles voitures sont testées en soufflerie pour mieux comprendre et améliorer l’aérodynamisme de leur forme. Le prototype est ensuite jeté dés que les informations requises ont été obtenues. Le problème courant avec le prototypage jetable est l’hypothèse que la fonctionnalité va s’échelonner correctement ce qui bien sur arrive rarement.

Le prototypage avec évolution est utile quand beaucoup des spécifications du design sont incertaines ou changeantes. Avec un prototype avec évolution, celui-ci est développé, évalué et affiné continuellement jusqu’à obtenir le design final. Les besoins et spécifications du design ne définissent jamais le produit final mais seulement la prochaine itération. Par exemple, les développeurs de logiciels utilisent le prototypage avec évolution pour gérer les changements rapides et volatiles des besoins. Le problème commun du prototypage avec évolution est que les designers ont tendance à avoir une vision tunnel, se concentrant sur l’amélioration des spécifications existante, au lieu d’explorer des designs alternatifs.

Le prototypage est un sujet vaste qui sera approfondi mais pour commencer un article en anglais de l’excellent Smashing Magazine.

Texte traduit provenant de Universal Principles of Design

Performance contre préférence

Les designers et les managers associent souvent la maxime d’affaires : « le client a toujours raison » ou « l’utilisateur a toujours raison » avec les choix de design. C’est une confusion dangereuse parce que ce qui aide les gens à bien accomplir leur tâche et ce que les gens aiment ne sont pas toujours identiques. Par exemple, le clavier Dvorak inventé il y a plus de 50 ans est sensé améliorer l’efficacité de dactylographie de 30% mais n’a pas réussi à croitre en popularité car les gens préfèrent continuer à utiliser le clavier qwerty / azerty plus familier. Pourtant si on demandait aux gens s’ils voudraient utiliser un clavier permettant de taper 30% plus vite avec moins d’erreurs, la plupart répondrait par l’affirmative.

Clavier Dvorak

Cet échec est une leçon importante pour les designers : les raisons qui font que les gens préfèrent un design sur un autre est une combinaison de différents facteurs et peut n’avoir aucun rapport avec les performances. Est-ce que le design est plaisant à regarder ? Est-ce qu’il contribue au bien être ou à l’estime personnelle de l’utilisateur ? Le meilleur moyen de balancer performance et préférence est de déterminer précisement l’importance de la performance contre la préférence. Tandis que les sondages, les interviews et les groupes de travail essayent de trouver ce que les gens veulent ou aiment, ce sont des indicateurs peu fiables sur ce que les gens vont faire, en particulier sur les designs nouveaux ou non familiers. De plus, les gens ont des difficultés pour différencier ce qu’ils aiment et ce qui améliore en fait leur performance. Ils pensent même souvent que les designs familiers leur permettent d’avoir les meilleurs performances.

La meilleur méthode pour obtenir les besoins précis de performance vs préférence est d’observer les utilisateurs dans un contexte réel. Quand ce n’est pas possible, des tests utilisant des tâches structurées approchant les aspects clés de l’utilisation du nouveau design pourront être utilisés. C’est important d’obtenir les informations de préférence pendant que la tâche est effectuée et non après.

Texte traduit provenant de Universal Principles of Design

Le cycle de vie

Tous les produits progressent séquentiellement à travers quatre étapes d’existence : introduction, croissance, maturité et déclin. Par exemple, un nouveau type de dispositif electronique est envisagé et développé; sa popularité grandit; après un certain temps, il atteint ses ventes optimales; puis finalement les ventes déclinent.

Cycle de vie

L’étape d’introduction est la naissance officielle du produit. Elle va parfois chevaucher les dernières étapes de tests du cycle de développement. L’objectif premier est de surveiller l’utilisation précoce du dispositif pour s’assurer des performances correctes en travaillant étroitement avec les clients pour régler ou corriger le design si nécessaire.

L’étape de croissance est la plus délicate, celle où la plupart des produits échouent. L’objectif premier est d’échelonner la production et la performance du produit pour répondre à la demande croissante ainsi que de fournir le niveau de support nécessaire à maintenir la croissance des clients et leur satisfaction. Il faut aussi commencer à rassembler les besoins pour la prochaine génération du produit.

L’étape de maturité est le sommet de cycle de vie du produit. Les ventes du produit ont commencé à faiblir et la compétition des concurrents est forte. L’objectif premier est d’améliorer et d’affiner le produit pour maximiser la satisfaction et le maintient de la clientèle. A ce moment, le design et le développement du prochain produit devraient être en cours.

L’étape de déclin correspond à la fin du cycle de vie. Les ventes du produit continuent de décliner et le coeur du marché est en danger. Il faut faire en sorte de minimiser les coûts de maintenance et développer des stratégies de migration des clients vers le nouveau produit. Le nouveau produit doit alors commencer à être tester.

Il faut prendre en considération le cycle de vie du produit quand on planifie et prévoit le futur. Il faut aussi noter que le cycle de développement pour le prochain produit commence lors de l’étape de croissance de la génération courante du produit.

Texte traduit provenant de Universal Principles of Design

Itération

L’itération correspond au processus de répéter un ensemble d’opérations jusqu’à ce qu’un résultat spécifique soit atteint.

Dans la nature, les itérations permettent à des structures complexes de se former en se construisant progressivement sur des structures plus simples. Dans le design, les itérations permettent à des structures complexes de se former en explorant, testant et mettant au point différents designs. Par exemple, une interface utilisateur de qualité est développée grâce à une série d’itérations. Chaque version est revue et testée et le design subit alors une itération en fonction du retour d’information. A chaque itération, on en apprend plus à propos de l’interface et de son utilisation.
Les itérations apparaissent à chaque cycle de développement en deux formes basiques : itération du design et itération du développement.

L’itération du design intervient lorsqu’on explore, teste et affine les concepts de design. Chaque cycle dans le design restreint la large gamme de possibilités jusqu’à ce que le design soit conforme aux besoins. Des prototypes d’une fidélité en progression sont utilisés pour tester les concepts et identifier les variables inconnues (qui servent aussi dans le coefficient de sécurité). Des membres du public visé devraient être mis à contribution sur différentes étapes des itérations pour participer aux tests et valider les besoins. Les échecs aussi bien que les succès fournissent d’importantes informations à propos de ce qui marche et ce qui ne marche pas. En fait, il y a même souvent plus de valeurs et de leçons intéressantes dans les zones d’échec. Le résultat des itérations de design est une spécification détaillée et bien testée qui peut être développée en un produit final.

L’itération du développement est l’itération non prévue qui intervient lors de la construction du produit. C’est une refonte ou encore un gaspillage dans le cycle de développement. Cette itération est couteuse, non désirée et très généralement la cause de spécifications incorrectes, non adéquates, ou encore de problème de management ou de planning.

Design itératif

Il faut prévoir et utiliser des itérations de design. Il faut établir des critères clairs définissant le degré auquel les besoins doivent être atteints pour que le design soit considéré comme finalisé. Une des méthodes les plus efficaces pour réduire l’itération de développement est d’assurer que tous les membres de l’équipe de développement ont une vision claire et de haut niveau du produit final. Ceci est souvent accompli grâce des spécifications bien écrites, accompagnées de modèles et prototypes de haute fidélité.

Une video du Paris Web 2009.

Pour compléter le sujet des articles en anglais :
http://en.wikipedia.org/wiki/Iterative_design
http://www.useit.com/papers/iterative_design/

En complèment, on peut aussi évoquer l’association naturelle entre le design itératif et l’agilité.

Texte traduit provenant de Universal Principles of Design

La hiérarchie des besoins

Le principe de hiérarchie de besoin précise que le design doit répondre au besoin de bas niveau (cela doit fonctionner) avant que les besoins de haut niveau, tel que la créativité, soient adressés. Un mauvais design va tenter de répondre à plusieurs niveaux de besoin sans construire en premier sur les besoins primordiaux. Les cinq niveaux clés de besoin sont les suivants :

  • Le besoin fonctionnel correspond aux exigences de base du design. Par exemple, un magnétoscope doit au minimum pouvoir enregistrer, jouer et rejouer une vidéo enregistrée.
  • Le besoin de fiabilité correspond au besoin d’établir une performance stable et consistante. Par exemple, le magnétoscope doit pouvoir rejouer les vidéos avec un niveau de qualité acceptable. Si le design a des performances variables ou de fréquents problèmes, le besoin de fiabilité n’est pas atteint.
  • Le besoin d’utilisabilité définit si le design est facile à utiliser et tolérant. Par exemple le magnétoscope doit rendre facile la programmation d’un enregistrement et doit être tolérant aux erreurs.
  • Le besoin de maîtrise qui permet aux utilisateurs de mieux faire les choses qu’avant. Par exemple, le magnétoscope peut aller chercher des programmes et les enregistrer en fonction de mots clés ce qui n’est pas possible avec un magnétoscope basique.
  • La créativité correspond au niveau où tous les besoins ont été satisfait et que les utilisateurs trouvent des nouvelles utilisations ! Les designs à ce niveau ont la plus forte valeur ajoutée et atteignent même une relation de culte par leurs utilisateurs.

La hiérarchie des besoins du design

Il faut prendre en compte cette hiérarchie de besoin dans le design et faire en sorte que les besoins de bas niveau sont satisfaisant avant de vouloir répondre aux besoins de plus haut niveau.


Article en anglais chez Smashing Magazine.

Texte traduit provenant de Universal Principles of Design

Coefficient de sécurité

Le coefficient de sécurité correspond à l’utilisation de plus d’éléments que nécessaire pour compenser les effets des variables inconnues et prévenir les défaillances du système.

Le design requiert de faire face à l’inconnu. Quelque soit le niveau de connaissance du designer et la qualité des spécifications, les hypothèses sont inévitables dans n’importe quel processus de design. Les facteurs de sécurité sont utilisé pour compenser les effets potentiels de ces inconnues. L’idée est de rajouter des matériaux et des composants au système afin de que le design dépasse les spécifications définies comme nécessaire pour atteindre les besoins.
Par exemple, designer un service internet pouvant supporter des milliers d’utilisateurs est direct et simple. Cependant, pour prendre en compte des besoins non anticipés par exemple le téléchargement de gros fichiers, les spécifications du besoin peuvent être multipliées (ici par trois). Dans ce cas, le coefficient de sécurité de trois signifie que le service est qualifié comme pouvant supporter 1000 utilisateurs mais est désigné pour en supporter réellement 3000.

Le niveau du coefficient de sécurité correspond directement au niveau d’ignorance des paramètres du design. Plus le niveau d’ignorance est grand, plus le coefficient de sécurité sera augmenté.
Plus d’éléments signifie un coût plus important. Les nouveautés nécessitent un coefficient de sécurité important. Si un design devient fiable au cours du temps, la confiance que les inconnus du systèmes disparaissent combiné à la pression pour réduire les coûts provoque un processus de réglage et de réduction du coefficient de sécurité. Malheureusement ce processus se poursuit généralement jusqu’à ce qu’un accident ou une défaillance se produisent.

Il faut utiliser le coefficient de sécurité pour minimiser les risques de défaillance d’un design. Lorsque le niveau de confiance dans le design augmente, on peut alors diminuer en conséquence le coefficient de sécurité mais il faut faire attention à ne pas aller trop loin. Il faut observer la capacité nominale d’un système pour prendre des décisions qui stressent les limites du système et non pas la capacité prévue

Wikipedia en parle avec des formules.