Il y a 50 ans déjà, je commençais au département d’informatique de l’université de Montréal… Il y a 42 ans, j’écrivais un document préliminaire au projet qui allait financer les activités fondatrices de Logitech. Depuis longtemps à la retraite, j’ai passé à d’autres choses (par exemple, j’ai fait un M.A. en litérature anglaise), mais j’ai toujours gardé l’oeil pour un domaine qui n’est toujours pas enseigné en informatique: la usability et le user-centered design. Je voudrais simplement montrer des exemples, dans cet article et ceux qui suivront, de comment nous devrions, en tant qu’auteurs, designers, développeurs, et membres d’équipes de développement de produits, aller voir comment le vrai monde utilise nos produits, ou les produits des autres, ou travaille dans le domaine d’une application que l’on voudrait qu’elles adoptent.

Idée #1: Vous ne savez pas tout, et votre équipe non plus

Je me souviens de mon mémoire de maîtrise qui était centré autour d’un logiciel que j’avais écrit pour transformer des textes afin de les envoyer à un appareil de photocomposition. J’avais inventé un langage de description de texte (c’était un peu la mode, ayant étudié les compilateurs), et j’avais aussi été l’utilisateur qui devait prendre des textes (comme un programme en PASCAL) et les rendre plus jolis pour la publication dans un livre, ou bien un poème en caractères cyrilliques que l’on représentait (en translitération) avec un ensemble de caractères très limité (26 lettres et quelques ponctuations). L’utilisateur, c’était moi, alors mon système était vraiment pour me faciliter la tâche.

Lorsque, quelques années plus tard, j’avais refait COMPO sur un micro-ordinateur de traitement de texte, je constatai que les typographes étaient devenus programmeurs, et que leur intervention allait toujours être nécessaire pour adapter les textes entrés par des “secrétaires”: on gagnait peut-être sur la quantité, mais les typographes corrigeaient les textes et adaptaient les descriptions de texte, changeant leur expertise, mais rien n’était vraiment plus facile. Il a fallu plusieurs annés avant que l’imprimante au laser et plusieurs versions de Word pour que l’on écrive des textes comme dans les livres (j’ai d’ailleurs produit mon propre livre 20 ans plus tard en utilisant Word!).

C’est dans les années 1990, après avoir programmé des logiciels intéractifs plus ou moins en imitant les autres, que j’ai pris un cours (de l’éducation permanente de l’université de Berkeley) donné par Richard Anderson. Ce qu’il nous révélait bouleversait notre croyance que nous, developpeurs de logiciel, savions tout. Et Richard n’avait rien de dogmatique comme les experts qui venaient nous dire qu’ils allaient refaire notre logiciel pour le rendre user-friendly. À la place, il nous donnait des articles sur l’expérience d’équipes qui essayaient d’étudier les usagers, et aussi de comment on se frappait souvent contre les murs à l’intérieur de nos organisations.

En effet, dès que j’essayais de voir et d’étudier sans formalité les usagers à l’intérieur de notre compagnie, j’ai eu la visite de la personne du Marketing qui me dit que je n’avais pas le droit et que c’était une erreur parce que ces travailleurs n’étaient pas acheteurs de nos produits. D’un autre côté, j’avais des informaticiens qui me disaient toujours de prouver mes assertions, et qui allaient faire comme ils veulent de toutes façons. Les chefs de produits voulaient prendre le pouvoir en allant vers les designers industriel réputés (qui n’avaient pas accès aux usagers).

Ma conclusion dans tout ça: parlez à vos usagers, soyez humbles, et observez (le comportement des personnes n’est pas facile à formaliser). Mais aussi, joignez-vous à des équipes qui favorisent la collaboration et l’humilité. On ne sait jamais tout, et on apprend tous les jours.