Articles taggés Principe de design

L’effet d’attente

2

L’effet d’attente (expectation effect) fait référence aux façons auxquelles les attentes affectent la perception et le comportement. En général, quand les personnes sont conscientes d’un résultat probable ou désiré, leur perception et leur comportement sont affectés d’une certaine façon. Quelques exemples de ce phénomène sont :

  • l’effet d’halo : les employés notent mieux les performances de certains employés que d’autres en fonction de l’impression globale positive de ces employés.
  • L’effet d’hawthorne : les employés sont plus productifs en fonction de leur croyance que les changements faits sur leur environnement vont améliorer leur productivité.
  • L’effet pygmalion : les étudiants sont plus ou moins performants en fonction des attentes de leur professeur.
  • L’effet placebo : les patients ressentent l’effet d’un traitement différemment en fonction de leur croyance que le traitement va fonctionner.
  • L’effet rosenthal : les professeurs traitent leurs étudiants différemment en fonction de leur attentes sur la manière dont ces étudiants vont réaliser la tâche.
  • Les caractéristiques de la demande : les participants à une expérience ou une interview fournissent des réponses et agissent de la façon dont ils pensent être attendus par l’expérimentateur ou l’intervieweur.

L’effet d’attente démontre que les attentes peuvent grandement influencer les perceptions et le comportement. Cet effet peut avoir un impact négatif sur la capacité à mesurer précisément le succès d’un design. Comme les designers sont naturellement biaisés vers leur design, ils influencent souvent de façon non intentionnelle les sujets de test à travers leurs mots et leurs actions ou peuvent omettre certains résultats afin de confirmer  leurs attentes.

Il faut considérer les effets d’attente quand on introduit et fait la promotion d’un design. Quand on essaye de persuader, il faut fixer les attentes d’une façon crédible pour que l’audience ciblée plutôt que de les laisser se faire leurs propres conclusions non biaisées. Quand on évalue un design, il faut utiliser les bonnes procédures de test pour éviter les biais résultant de l’effet d’expectation.

Le design par comité

6

“a camel is a horse designed by committee”
D’après Wikipedia, la conception par comité est un terme faisant référence à un style de design où un groupe d’entités ou de personnes se réunissent pour produire quelque chose (souvent la conception de systèmes technologiques ou des normes), en particulier en la présence d’un mauvais leadership. Les caractéristiques déterminantes du «design par comité» sont une complexité inutile, l’incohérence interne, failles logiques, la banalité et l’absence d’une vision unificatrice. Le terme est particulièrement présent dans le jargon technique, et il légitime la nécessité et l’acceptation générale d’un unique architecte des systèmes. Souvent, lorsque le logiciel est conçu par un comité, la motivation initiale, les spécifications et les critères techniques se retrouvent en arrière plan et des mauvais choix peuvent être faits simplement pour apaiser l’ego de plusieurs membres du comité. Ces produits et les normes finissent par faire trop de choses ou avoir des pièces qui s’emboîtent mal (parce que les entités qui ont produites ces pièces n’étaient pas au courant les unes des autres des conditions requises pour un bon ajustement).

En clair, le design par comité n’a pas une bonne réputation. Il est communément qualifié qu’un bon design est le résultat d’un projet mené par un leader autocratique et les mauvais designs sont menés par des groupes démocratiques. Beaucoup pensent qu’un super design nécessite un tyrannique « Steve Jobs » à la tête du succès.

On peut trouver facilement d’autres articles qui confirment que le design par comité est une erreur :
http://www.bingenuity.com/design-by-committee-vs-design-by-dictator
http://www.smashingmagazine.com/2010/06/29/why-design-by-commitee-should-die/
http://www.codinghorror.com/blog/2005/06/the-pontiac-aztek-and-the-perils-of-design-by-committee.html
http://boagworld.com/business-strategy/design-by-committee/

Pourtant, d’après le livre Universal Principle of Design, ce jugement est au mieux une grosse simplification et dans la plupart des cas tout simplement incorrecte.
Le design par dictateur est préférable quand le projet est limité par le temps, les besoins sont relativement simples et directs, les conséquences des erreurs sont tolérables et l’engagement des intervenants n’est pas important. Il devrait être noté qu’à l’exception des inventeurs, des designers célèbres et des start-up virtuellement tous les designs modernes sont des designs par comité. La croyance que les supers designs viennent normalement des dictateurs est plus un mythe qu’une réalité.
Le design par comité est préférable quand le projet est mené par la qualité, que les besoins sont complexes, les conséquences des erreurs sont sérieuses ou l’engagement des intervenants est important. En pratique chaque aspect d’une mission technologique est un produit du design par comité (par exemple une mission de la Nasa).

Le design par comité est optimal quand :

  • Les membres du comité sont divers
  • Le biais et l’influence des membres du comité sont minimisés
  • L’autorité locale de prise de décisions est encouragée à opérer dans un accord sur la cadre global
  • Les entrées et les contributions des membres sont efficacement collectés et partagés
  • Des tailles de groupes idéals sont employés
  • Un modèle simple de gouvernance est adopté pour facilité la prise de décision et assurer que le processus de design ne peut être retardé ou bloqué

Le design par dictateur tend à manquer de la correction d’erreur et des filets de sécurité organisationnels des approches basées sur des comités. L’autocratie est linéaire et rapide mais risquée et sujette à l’erreur. La démocratie est itérative et lente mais prudente et résistante aux erreurs. Chaque modèle à sa raison en fonction des circonstances.

Cet article donne des astuces pour pouvoir sortir une bonne conception dans le cadre d’un design par comité.
« Malgré les nombreuses connotations négatives, quand on l’approche avec les outils appropriés et les bonnes stratégies, les comités de conception peuvent être une expérience satisfaisante pour toutes les personnes impliquées, la production de projets de qualité et des clients heureux. Cependant, la responsabilité est sur vous, le designer, pour créer un environnement qui produit des résultats. »
Il faut pour cela :

  1. Clarifiez les objectifs
  2. Utilisez les bons outils
  3. Défendez avec la raison
  4. Filtrez les retours
  5. Utilisez des tests dans le monde réel

Principes de design d’une interface graphique

8

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).

La visibilité

1

Selon le principe de visibilité, les systèmes sont plus utilisables quand ils indiquent clairement leur status, les actions qui peuvent être effectuées et les conséquences de chaque action. Par exemple, une lumière rouge peut indiquer si un dispositif reçoit ou non de l’électricité; des contrôles allumés pourraient indiquer que ceux ci sont disponibles; des retours d’information auditif ou tactile permettraient de reconnaître qu’une action a bien été accomplie. Le principe de visibilité est basé sur le fait que les utilisateurs ont des facilités pour reconnaitre les solutions en les sélectionnant d’un ensemble d’options plutôt que de s’en souvenir.

On peut prendre l’exemple de deux balladeurs CD affichant ou non le titre des chansons.

Quand on en vient au design de systèmes complexes, le principe de visibilité est peut être le plus important et le moins respecté.
L’accident nucléaire de Three Miles Island vient en partie d’un problème de visibilité du design.

Pour incorporer la visibilité dans un système complexe, on doit considérer le nombre de conditions, le nombre d’options par condition et le nombre de résultats – les combinaisons peuvent être écrasantes. Ainsi la plupart des designers essayent de rendre tout visible tout le temps. Cette approche peut sembler souhaitable mais elle rend les informations pertinentes et les contrôles plus difficiles à accéder à cause d’une surcharge d’information.

Une organisation hiérarchique et une prise en compte du contexte sont des bonnes solutions pour gérer la complexité tout en préservant la visibilité. L’organisation hiérarchique met les contrôles et l’information dans des catégories logiques puis les cache dans un contrôle parent comme les menus de logiciel. La prise en compte du contexte révèle ou cache des contrôles ou information en fonction du contexte du système.

Texte traduit provenant de Universal Principles of Design

Mauvais rapport signal - bruit

Le rapport Signal-Bruit

1

Toute communication implique la création, transmission et réception d’informations. Durant chaque étape de ce processus, la forme de l’information – le signal – est dégradée et des informations non pertinente – du bruit – sont ajoutées. La dégradation réduit la quantité d’information utile en modifiant sa forme. Le bruit réduit la clarté en diluant l’information utile avec de l’information inutile. La clarté de l’information peut être comprise comme le ratio de signal restant par rapport au bruit ajouté. Par exemple, un graphique élément inutile aura un ratio signal-bruit élevé.

Le but du design est donc de maximiser le signal et de diminuer le bruit, produisant ainsi un ratio signal-bruit élevé.

Mauvais rapport signal - bruit

Mauvais rapport signal - bruit

Bon rapport signal - bruit

Bon rapport signal - bruit

Maximiser le signal signifie clairement communiquer de l’information avec une dégradation minimale. La dégradation du signal apparait quand l’information est présentée de façon inefficace : écriture non claire, graphique inapproprié ou des labels et icônes ambigus. La clarté du signal est améliorée à travers une présentation simple et concise. Un design simple nécessite une charge de performance (voir article) minimale, permettant aux gens de se concentrer sur l’information. Par exemple, l’utilisation du mauvais type de graphique pour présenter certains types données peut modifier le sens de l’information. Mettre en avant les aspects clés de l’information peut aussi réduire la dégradation du signal : par exemple mettre en surbrilliance ou la répétition des éléments importants d’un design.

Minimiser le bruit signifie enlever les éléments non nécessaires. Il est important de réaliser que chaque élément non nécessaire (graphiques, textes, lignes, symboles …) détourne l’attention des éléments pertinents. Les éléments nécessaires devrait être eux aussi réduit au strict minimum tout en conservant leur fonction ou leur message pour accentuer leur efficacité. Par exemple, les lignes de séparation des cellules d’une table devraient être amoindries, éclaircies voir supprimées. L’excès crée du bruit.

En conclusion, il faut maximiser le ratio signal-bruit, augmenter le signal en gardant un design simple et sélectionner les stratégies de design avec soin. Il ne faut pas hésiter à utiliser des standards et des règles bien répandus pour créer un effet levier sur les conventions et promouvoir une implémentation cohérente.

Texte traduit provenant de Universal Principles of Design

La proximité

0

La proximité est un des nombreux principes Gestalt de perception. Les éléments proches sont considérés comme un seul groupe et étant plus liés entre eux que des éléments éloignés.

Principe Gestalt de proximité

Les groupes résultant de cette proximité réduisent la complexité du design et renforcent les relations entre éléments. Au contraire, un manque de proximité crée la perception de groupes multiples et disparates et renforcent les différences entre éléments. Certaines dispositions proches impliquent des types de relations spécifiques et devraient être prises en considération. Par exemple, des éléments connectés ou se super posant sont communément interprétés comme partageant un ou plusieurs attributs alors que des éléments proches mais non connectés sont considérés comme apparentés mais indépendant.

La proximité est un des moyens le plus puissant pour indiquer la parenté dans le design et surpasse généralement des indices visuels concurrents (ex. la similarité). Il faut donc faire en sorte d’organiser les éléments pour que leur proximité corresponde à leur parenté. Par exemple, il faut favoriser un étiquetage direct sur les graphes plutôt qu’une légende sur les cotés de celui-ci.

Texte traduit provenant de Universal Principles of Design

Prototypage

Le prototypage

1

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

La charge de la performance

2

Plus l’effort pour accomplir la tâche est grand, moins la tâche a une chance d’être accomplie avec succès.

La charge de la performance est le degré d’activité mentale et physique requis pour accomplir une tâche. Si la charge est importante, le temps et les erreurs de la performance augmentent et la probabilité d’accomplir la tâche avec succès diminue. La charge de la performance se divise en deux types : la charge cognitive et la charge cinétique.

La charge cognitive est la quantité d’activité mentale – perception, mémoire, solution de problème – requise pour accomplir la tâche. Par exemple, les premiers systèmes informatiques demandaient aux utilisateurs de se souvenir d’un grand nombre de commandes et de les entrer dans le système de façon spécifique. Le nombre de commandes qui devaient être mémorisées était une charge cognitive pour la tâche. L’apparition des interfaces graphiques a permis aux utilisateurs de parcourir et sélectionner les commandes grâce aux menus plutôt que de s’en rappeler de mémoire. Cette réduction de la charge cognitive a grandement réduit l’effort mental pour utiliser les ordinateurs. Ces derniers ont ainsi pu devenir un marché de masse. Les stratégies générales pour réduire la charge cognitive incluent minimiser le bruit visuel, découper l’information qui doit être apprise, utiliser des aides mémoires ou encore automatiser les calculs et les tâches demandant beaucoup de mémorisation.

La charge cinétique est le degré d’activité physique – nombre de mouvements ou quantité de force – requis pour accomplir la tâche. Par exemple, le télégraphe permettait aux gens de communiquer des lettres à travers une série de frappes sur une armature métallique. Le nombre de frappes pour communiquer un message était la charge cinétique de la tâche. Samuel Morse a créé le code Morse pour minimiser la charge kinétique en assignant les codes les plus simples aux lettres les plus fréquentes. Cette approche a permis de réduire les temps de transmission et le taux d’erreur. Les stratégies générales pour réduire la charge cinétique incluent réduire le nombre d’étapes requises pour finaliser la tâche, minimiser la gamme de mouvements et les trajets ou encore optimiser les tâches répétitives.

De nombreux exemples peuvent se retrouver dans notre vie de tous les jours : du favoris de votre navigateur permettant d’éviter de vous souvenir ou de noter les sites qui vous intéressent (diminution de la charge cognitive) à la clé de voiture électronique (diminution de la charge cinétique) en passant par le code de barre qui permet d’éviter l’étiquetage manuel, d’entrer le prix à la main pour la caissière et l’inventaire automatique.

Texte traduit provenant de Universal Principles of Design

Performance contre préférence

1

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

La modularité dans un ordinateur

La modularité

0

La modularité est un principe structurel utilisé pour manager la complexité des systèmes. Cela implique d’identifier les ensembles fonctionnels similaires et ensuite transformer ces ensembles en systèmes autonomes interdépendants (modules). Par exemple, le design modulaire des barrettes de mémoire d’un ordinateur permet à son propriétaire de changer ou d’augmenter la mémoire sans changer d’ordinateur. La possibilité d’améliorer facilement et à moindre coût un système donne au design modulaire un avantage intrinsèque par rapport au design non modulaire.

Les modules devraient être désignés pour cacher leur complexité interne et interagir avec les autres modules grâce à des interfaces simples. Le résultat est une réduction globale de la complexité et une décentralisation de l’architecture système ce qui améliore la fiabilité, la flexibilité et permet une meilleure maintenance. De plus, un design modulaire encourage l’innovation sur chaque module ainsi que la compétition sur leur design et leur fabrication.

La modularité dans un ordinateur

La modularité du PC est un des facteurs de son succès

Le bénéfice d’un design modulaire n’est pas sans coût : celui-ci est plus complexe qu’un design non modulaire. Les designers doivent avoir une connaissance significative du fonctionnement interne du système et de son environnement pour décomposer en modules et faire que ceux-ci fonctionnent comme un tout. La plupart des systèmes modulaires existants n’ont pas commencé ainsi, mais se sont peu à peu transformer pour être modulaire comme la connaissance du système augmente.

En conclusion, il faut considérer la modularité quand on désigne ou modifie des systèmes complexes. Cependant, il ne faut pas tenter un système modulaire complexe sans designer expérimenté et une connaissance approfondie du système.

Texte traduit provenant de Universal Principles of Design

Haut de page