Inutile de créer de beaux didacticiels pour vos produits, seuls vos power users les consulteront. Comme évoqué dans le compte-rendu de Designer L’Invisible, tout ce que nous faisons avec un média digital fait intervenir bien plus de connaissance acquise que l’action originale effectuée avec nos outils quotidiens [1].

Écrire avec un crayon sur une feuille de papier ne fait entrer en jeu que la connaissance écriture. Écrire avec un traitement de texte implique des connaissances en dactylographie, typographie, archivage… dont l’acquisition relève plus pour la grande majorité d’entre-nous de l’intuition, du tâtonnement et de l’à peu près que d’un véritable apprentissage conscient. Je me rappelle très bien de mon premier contact avec un traitement de textes graphique – Word Junior sous DOS ne comptant pas. Grâce à Microsoft Works premier du nom sous Windows 3.0, ce qui ne nous rajeunit pas, j’effleurais l’édition et la mise en page à grands coups de titres en 48px ombrés et avec des effets 3D. Presque 20 ans plus tard, j’en frémis encore d’horreur.

Une partie non négligeable de la conception logicielle consiste à anticiper tous les cas limites d’utilisation que pourraient rencontrer nos utilisateur en ne suivant pas précisément le schémas d’utilisation théorique tracé lors de la conception du produit. Plus votre application grossit et gagne en complexité, et plus ces cas limites sont nombreux et tordus. Ils n’en deviennent que plus imprévisibles, et le temps nécessaire afin de corriger une fausse manipulation s’accroit parfois de façon exponentielle.

Si vous vivez avec des enfants en bas-âge, vous voyez certainement de quoi je veux parler. Garder une maison fonctionnelle, agréable et résistante aux bêtises – et accessoirement s’assurer que les enfants ne courent aucun risque – est un défi perpétuel. Avant d’en avoir, j’ai eu la chance – si l’on peut dire – d’encadrer des camps d’enfants et d’adolescents dont une partie venait contre leur gré. J’y ai acquis un certain “nez” pour détecter les bêtises à venir, mais rien n’y fait, et mon ainé de six ans me dame régulièrement le pion à ce petit jeu. Si celles des adolescents relèvent d’une volonté de transgresser les interdits, les bêtises des petits enfants, elles, sont le plus souvent innocentes.

C’est pour cette raison d’ailleurs que vous auriez tort de blâmer vos utilisateurs quand ils ne font qu’utiliser le produit que vous leur avez vendu. On se retrouve alors dans une de ces quatre situations :

  • Le produit est bien trop complexe pour être compris intuitivement de ses utilisateurs. Une phase d’expérimentation est nécessaire afin de pouvoir l’utiliser sans se référer à la documentation.
  • Votre produit ne fait pas ce que souhaite l’utilisateur qui cherche toutefois à l’y contraindre. Vous avez déjà vu ces enfants forcer sur leurs jouets pour faire rentrer le cylindre dans le trou prévu pour le prisme ? Pareil.
  • Vous n’avez pas posé de garde-fous à votre produit, ce qui rend les actions de vos utilisateurs hasardeuses, voir dangereuses. Le risque que vous ayez laissé des failles de sécurité n’en est que plus grand.
  • Vous connaissez le problème mais avez décidé qu’il était suffisamment mineur et bénin pour ne pas justifier une résolution en amont, plus coûteuse en temps ou en ressources. C’est un choix, celui de la solution de facilité, mais il est compréhensible. Jusqu’au moment où….

Une des raisons pour lesquelles je déteste Perl, en dehors de sa syntaxe imbitable, est son crédo there is more than one way to do it, qui ouvre la porte à toutes les fenêtres de l’abus. Je préfère des produits simples, qui font moins de choses que leurs concurrents, et qui ne me laissent qu’une manière évidente de le faire à des produits qui exigeront de moi de me demander si la meilleure manière d’aller d’un point A à un point B passe par C, D, E, ou tous à la fois.

À l’époque lointaine où j’enseignais la sécurité des systèmes d’information, je commençais tous mes cours par : la chose la plus importante que vous deviez savoir, c’est que 65% des dommages et des attaques affectant un système d’informations viennent de l’intérieur. Si je devais aujourd’hui animer un atelier sur l’utilisabilité, je crois que je commencerais par 65% des problèmes que rencontreront vos utilisateurs viennent de ce que vous avez pensé votre produit d’une manière, et qu’ils ont compris comment s’en servir d’une autre.

[1] Dont l’usage est beaucoup moins inné qu’on veut bien nous le faire croire. Le principe du marteau ou de la roue ont nécessité des milliers d’années d’expérimentation.

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: