Rechercher
  • Des usages à la conception et autres
  • digressions autour de l'expérience utilisateur.
Rechercher Menu

10 maximes pour la conception d’IHM.

Une petite série de maximes à appliquer lors des projets et de la conception d’IHM.

  • L’enfer est pavé de bonnes intentions. En tant que concepteur, il nous est difficile d’avoir le même point de vue que l’utilisateur. C’est en voulant bien faire, qu’on en fait trop et que les plus grosses erreurs sont commises.
  • L’utilisateur a toujours raison. L’utilisateur connaît le domaine et le contexte opérationnel dans lequel il se servira de l’application. Ses souhaits sont généralement justifiés car ils répondent à des besoins opérationnels.
  • L’utilisateur n’a pas toujours raison. Pourtant dans certains cas, ce que l’utilisateur pense être bon pour lui n’est pas ce qui lui permettra d’être plus performant. Un test d’utilisabilité permet généralement de lui montrer qu’il fait fausse route.
  • L’utilisateur n’est pas le développeur. Dans un projet, chacun se partage le travail selon ses compétences ; c’est aux équipes de développement de prendre les décisions relatives au logiciel.
  • Le développeur n’est pas l’utilisateur. L’équipe de développement ne connaît pas suffisamment le domaine applicatif et la tâche pour se mettre à la place de l’utilisateur. Lorsque le concepteur pense à la place de l’utilisateur, il a de fortes chances de se tromper.
  • Le chef n’est pas l’utilisateur. Bien qu’il soit le client, le PDG n’utilise généralement pas le logiciel. Son point de vue n’a pas le même poids que celui de l’utilisateur final.
  • Le mieux est l’ennemi du bien. En voulant bien faire, on a tendance à en faire trop, à offrir beaucoup plus de fonctionnalités que l’utilisateur n’en a réellement besoin. Cette profusion rend le logiciel complexe et difficile à utiliser. Il est préférable de faire simple et pertinent.
  • Le détail est essentiel. Un détail n’est jamais à négliger en terme d’utilisabilité car ce sont souvent de petits détails, se répétant à chaque utilisation, qui empoisonnent la vie de l’utilisateur.
  • L’aide n’en est pas une. L’utilisateur se sert de l’aide parce qu’il ne comprend pas le fonctionnement du logiciel. Pour véritablement aider l’utilisateur, il faut qu’il puisse se servir du logiciel sans utiliser l’aide.

Une dernière que je vous laisse méditer :

  • Le plaisir commence par l’absence de déplaisir.

Auteur :

Lead UX designer en Freelance depuis le dernier millénaire ! J'aide à concevoir des services, des applications en étant centré sur l'utilisateur et ses usages.

2 commentaires

  1. Au sujet de l’aide, attention tout de même. Je renvoie à la métaphore de la bicyclette et du tricycle d’Engelbart (en gros le tricycle n’a pas besoin d’apprentissage mais n’est pas aussi performant que le vélo). Dès lors que le logiciel vise la performance dans un usage qui dure, il est évident que certaines fonctionnalités nécessiteront un apprentissage et donc une aide.

    Sinon, la dernière est intéressante 😉 Il est bon de citer les maîtres :
    « offer usability plus reliability to prevent frustration from undermining the fun »
    Ben Shneiderman, Designing for fun: how can we design user interfaces to be more fun?, interactions, v.11 n.5, September + October 2004

    • D’ailleurs les maximes ont pour origine le livre de Nielsen :

      Usability Engineering
      Book by Jakob Nielsen, published by Morgan Kaufmann, San Francisco, 1993.
      ISBN 0-12-518406-9.

      On les retrouves notamment dans le livre de J.F. Nogier

Les commentaires sont clos.


Warning: Undefined array key "share-pages" in /home/clients/8d92eb93db207cb7c6158a9c725c2336/web/blocnotes/wp-content/themes/dorayakichild/footer.php on line 77