Category : Ergonomie logicielle

En discutant avec des collègues à propos du développement de logiciels utilisables, je me suis rendu compte que le terme “logiciel utilisable” porte à confusion. Le fait de dire qu’un logiciel est utilisable n’implique pas nécessairement qu’il respecte des critères d’utilisabilité. Du moins, pas pour tout le monde. Pour moi, c’est ce que ça implique. Mais je baigne dans le domaine de l’ergonomie logicielle et pour moi un logiciel dit utilisable fait référence à son utilisabilité, selon le sens donné dans la norme ISO 9241, soit :

Degré selon lequel un produit peut être utilisé, par des utilisateurs identifiés, pour atteindre des buts définis avec efficacité, efficience et satisfaction, dans un contexte d’utilisation spécifié.

Lors de la discussion qui m’a inspiré ce billet, mes collègues comprenaient plutôt le terme comme étant simplement la possibilité de se servir, voire utiliser, un logiciel pour remplir une tâche. Ceci, en soi, n’est pas faux. Incomplet, mais pas faux! Le fait de pouvoir remplir une tâche avec un logiciel est un critère de base de l’utilisabilité. Qu’il soit intuitif, simple ou agréable à utiliser, si le logiciel ne permet pas à l’utilisateur d’arriver à ses fins, il n’est pas utile et encore moins utilisable.

Si je reprends la définition de la norme ISO, je distingue quelques éléments qui permettent d’établir des critères d’utilisabilité. En effet, on ne peut pas déclarer un logiciel comme utilisable seulement parce qu’un utilisateur atteint son objectif. Il est plutôt utile de voir cette définition de l’utilisabilité comme un ensemble de critères qu’on applique à un logiciel lors de l’évaluation de sa qualité ergonomique.

Parfois, certains choix sont difficiles. Plutôt, certains choix nous confirment nos priorités.

Dans l’amélioration du site internet de Pyxis, il y a des choix à faire; prioriser l’utilisabilité et l’accessibilité du site ou prioriser le référencement et le marketing web. De façon générale, je pense que les deux vont très bien de paire. Mais, il arrive des moments où un choix s’impose. Pour moi, le choix est clair. L’utilisabilité et accessibilité ont priorité. Je trouve plus utile que les visiteurs du site internet de Pyxis comprennent le contenu, qu’ils ne se perdent pas dans la navigation et que le contenu soit accessible à tous les visiteurs que de faire quelques pirouettes pour avoir un meilleur référencement.

Comme exemple, dernièrement on me suggérait de modifier les attributs alt des images des pages pour y ajouter des keywords ayant un lien à la page en cours. Ceci pourrait aider le référencement. Pourrait, certes, mais à quel prix? Pour moi le prix de diminuer l’accessibilité de notre site internet ne vaut pas le léger avantage que pourrait ajouter la modification aux attributs alt. L’utilité de cet attribut est de présenter un texte alternatif pour les situations où l’image en question ne peut être affichée. Le texte alternatif devient, dans ces situations, le contenu et c’est pour cette raison qu’il doit être significatif.

Alors, en suivant la suggestion faite, l’image de notre logo d’entreprise aurait eu comme texte alternatif “Pyxis Technologies agile accompagnement formation développement logiciel “. Pour moi cette suggestion ne fait pas de sens et je préfère conserver le texte alternatif pour notre logo comme étant “Pyxis Technologies”.

Un choix qui semblait initialement difficile est devenu par la suite plutôt simple. Il faut respecter ses priorités!

Charte des droits des utilisateurs

• L’utilisateur a toujours raison. S’il existe un problème avec l’utilisation du système, il provient du système, pas de l’utilisateur.
• L’utilisateur a droit à la facilité lors de l’installation de logiciels et d’équipement informatique.
• L’utilisateur a droit à des systèmes faisant exactement ce qu’ils sont censés faire.
• L’utilisateur a droit à des instructions claires, simples et précises lui permettant de comprendre et d’utiliser un système assurant l’atteinte de ses objectifs.
• L’utilisateur a droit au contrôle absolu du système, de même qu’à être capable d’obtenir l’attention du système sur demande.
• L’utilisateur a le droit d’être informé par le système sur son état par rapport à la tâche qu’il effectue et par rapport au progrès accompli vers la complétion de la tâche, de façon claire, compréhensible et précise.
• L’utilisateur a le droit d’être informé clairement quant aux spécifications requises pour utiliser pleinement tout système informatique.
• L’utilisateur a le droit de connaître les limites des capacités du système.
• L’utilisateur a le droit de communiquer avec les fournisseurs de technologies et de recevoir des réponses utiles et intelligentes à toutes ses questions.
• L’utilisateur doit être le maître de la technologie, non l’inverse. Tout système doit être intuitif et naturel lors de son utilisation.

Ce n’est pas la première fois que je lis à propos de la “Charte des droits des utilisateurs” (A Computer User’s Manifesto traduit librement par Alain Robillard-Bastien). Initialement j’étais d’accord avec la charte et je tentais de la faire connaître à mes collègues. Maintenant, avec le recul apporté par une bonne année depuis ma précédente lecture, je dois avouer que je ne suis plus autant d’accord. Je pense même que certains éléments nuisent à l’adoption des pratiques d’utilisabilité par les équipes de développement.

D’abord, la charte parle de l’utilisateur. Pourtant “l’utilisateur” n’a pas de forme précise, “l’utilisateur” est malléable à la réalité désirée. Ainsi, au cours du développement d’un logiciel, l’équipe de développement pourrait s’imaginer que l’utilisateur est un expert du plus haut calibre et faire des choix de conception cohérent avec ceci. Ils respecteraient, en quelque sorte, la charte pour cet utilisateur, sans pour autant concevoir un système qui soit utilisable par l’ensemble des utilisateurs réellement ciblés. Ce qui manque à cette charte, c’est un préambule aidant les équipes à détailler qui sont les utilisateurs ciblés et à appliquer les concepts présentés avec discernement selon leur contexte.

Je comprends bien le fond des principes énoncés. Par contre, je pense qu’en mentionnant que l’utilisateur a toujours raison, l’auteur suppose que l’utilisateur comprend toujours ce qu’il fait, qu’il comprend toujours le système qu’il tente d’utiliser et qu’il n’est jamais distrait. Hors, pour avoir observé des utilisateurs dans l’utilisation de systèmes, j’ai pu constater qu’ils n’ont pas toujours raisons. Ils explorent parfois les possibilités offertes par le système, sans réellement comprendre ce qu’ils font. Je pense aussi que d’imaginer un utilisateur avec un contrôle absolu sur le système qu’il utilise n’est pas réellement souhaitable. Il y a généralement des limites sur le contrôle que l’utilisateur peut avoir sur le système. Ces limites sont mises en place pour empêcher l’utilisateur de se nuire à lui-même.

Enfin, je crois que les fondements de cette charte sont valides. Par contre, elle demande un peu de mise en contexte pour être bien comprise et ne pas effrayer les équipes de développement qui voudrait mettre en place des pratiques d’utilisabilité.

J’aime bien ce calendrier qui n’en est pas un. C’est un outil simple qui présente des concepts d’utilisabilité dans un format accessible à tous les auditoires.

Vous pouvez le télécharger à partir du site BadUsability.com. Imprimez-le et discutez en avec votre équipe autour du café. C’est une bonne façon d’intégrer ces principes à vos pratiques de développement logiciel.

Durant l’automne, j’ai accumulé un certain retard à lire les articles Alertbox sur le site useit.com. En tentant de rattraper mon retard, j’ai rapidement remarqué l’article Agile Development Projects and Usability. Je me suis empressé de le lire pour connaître les propos de Jakob Nielsen sur le sujet.

Après lecture, je peux dire que je suis globalement d’accord avec ce qu’il avance dans cet article, sauf pour la partie où il mentionne;

Another issue is that, with Agile, a product’s development is broken down into smaller parts that are completed one at a time. Such an approach risks undermining the concept of an integrated total user experience, where the different features work consistently and help users build a coherent conceptual model of the system. At worst, the user interface can end up resembling a patchwork.

Je pense qu’il y aurait un risque que l’expérience utilisateur ne soit pas cohérente pour toute l’application, s’il n’y avait pas de vision globale des fonctionnalités à développer. Un projet Agile a une vision globale. Le développement repose, entre autre, sur un backlog pour le produit, qui sert à alimenter le contenu des itérations. Alors, même si tous les éléments du backlog de produit ne sont pas développés, l’équipe de développement voit, dans le backlog de produit, les éléments qui sont souhaités par le product owner. C’est à partir de ces éléments qu’on peut dégager un modèle du système et ainsi tenter de conserver une cohérence dans l’interface utilisateur.