Comment faire une documentation pour des utilisateurs alors que ce sont des machines qui en exploitent le contenu ?

« La mauvaise qualité des interfaces et des aides tire son origine pour une large part dans la non‐prise en compte de l’utilisateur au stade de la conception »

« Nous avons vu que les professionnels préféraient les explications obscures, mais qui respectent les habitudes de style et de vocabulaire du métier, à un texte clair s’éloignant des canons rédactionnels de la profession »

« L’incapacité des producteurs d’information ordinaire à se mettre à la place des récepteurs est souvent extraordinaire. Quand nous lisons certains modes d’emploi,…nous ne pouvons que nous demander si les autres comprennent eux‐mêmes ce qu’ils écrivent. »

« L’enfer de l’information ordinaire », Christian Morel, ed. Gallimard.

En effet, dans un contexte professionnel, le problème n’est pas bien souvent que la réponse à la question de l’utilisateur n’existe pas. C’est bien plus que l’information est noyée au milieu d’un magma informationnel qui lui donne peu de chance d’être retrouvée.

Pourquoi ?

  • parce que l’utilisateur ne lit pas la documentation mais cherche quelque chose. Il va donc, comme il le fait dans Google, entrer un mot-clé qui lui semblera pertinent. Encore faut-il que le rédacteur ait utilisé les mêmes termes que lui et non un vocabulaire jargonneux.
    • Rappelez-vous la dernière fois que vous avez voulu chercher comment incruster dans Word un texte afin d’indiquer que votre document était confidentiel… avant de vous rappeler que cela s’appelait un « watermark » (ou filigrane pour la version française).
  • parce que le rédacteur aura placé l’information dans un paragraphe qui ne traite pas du sujet, à la manière d’une digression comme on peut en lire dans les romans ou comme on peut en faire lorsque l’on parle.
    • Qui n’a jamais trouvé finalement l’information qu’il cherchait dans une note de bas de page ?
  • parce que la documentation n’aura pas été pensée en fonction de l’utilisateur. Elle aura été calquée sur l’outil (documentation exhaustive de tous les menus, de toutes les fonctionnalités) et non sur les besoins réels (on m’explique comment basculer en mode machin-truc, mais ça va me servir à quoi ? Moi je veux juste créer un document…)
  • parce que l’information n’est pas adaptée pour être comprise par un ordinateur, alors que c’est aujourd’hui le principal outil pour chercher (Google comptabilise 6 milliards de recherches par jour ! On se demande comment on faisait avant). L’ordinateur ne comprend pas, il interprète des balises qui lui disent que telle information est un titre, un résumé, une procédure, une référence.

Il va donc falloir, comme nous l’expliquions, structurer le texte et le baliser pour distinguer les informations qui relèvent du concept, de la tâche, de la référence.

Prenons un exemple pour être plus clair :

L’ensemble des questions de l’utilisateur trouve une réponse qui est catégorisée et identifiée de sorte de pouvoir être retrouvée facilement.

L’utilisateur aura besoin de l’une ou l’autre information selon son degré de maturité et le contexte dans lequel il se trouve : lecture du manuel « à froid » lorsqu’on lui remet le véhicule, ou « à chaud » lorsqu’il est arrêté sur la bande d’arrêt d’urgence et qu’il doit faire une manipulation ou identifier ce voyant rouge qui clignote.

Le langage de structuration DITA  permettra de créer ces modules d’information et de les emboîter dans un ordre ou un autre selon le contexte, le support, le public auquel on s’adresse.

Les maps pourront donc être différentes selon les supports mais réutiliser les mêmes modules d’information.

Structurer sa documentation utilisateur est la seule réponse possible à l’infobésité qui guette.

Source : www.precisioncontent.com

by Carole Brochard, responsable Touch of Content.