Ah, le grand problème que rencontre un jour tout rédacteur technique : vous avez travaillé dur, chassé au lasso les développeurs pour récupérer la liste de features à documenter, attaché les experts à une chaise jusqu’à ce qu’ils répondent à vos question, amoureusement rédigé une aide utilisateur claire et concise, hanté le bureau du product owner jusqu’à ce qu’il donne son feu vert, et maintenant votre magnifique documentation est disponible dans le produit.
Et personne ne s’en sert !
Pourquoi ?
A en croire cette étude, les trois quarts des gens ne lisent simplement pas les manuels d’utilisation.
Deux raisons principales expliquent ce phénomène :
1 – Pour faire court, les utilisateurs sont des gens, et les gens sont naturellement paresseux.
Ce n’est pas un mal en soi.
Les gens utilisent un logiciel pour accomplir une tâche précise.
Cette tâche leur demande du temps et de l’énergie, et le monde actuel étant ce qu’il est, réclamer plus d’attention que strictement nécessaire est déjà en demander trop.
2 – Paradoxalement, les utilisateurs sont actifs.
Ils préfèrent apprendre par la pratique plutôt qu’en lisant un texte dense et plein de jargon.
Si, comme moi, vous avez un parent/conjoint qui insiste toujours qu’il sait parfaitement programmer l’enregistrement de la box télé tout seul, vous savez que les utilisateurs préfèrent toujours apprendre par eux-mêmes.
Les novices auront toujours tendance à ignorer les instructions pour faire leurs propres erreurs.
Les utilisateurs chevronnés partent du principe qu’ils savent déjà tout ce qu’il y a à savoir.
Dans tous les cas, ils partent du principe que le bon sens suffit.
Malheureusement, ce raisonnement ne fonctionne que si votre logiciel a été développé avec un parfait bon sens, ce qui n’est pas toujours le cas.
Comment serait-ce possible alors que personne n’arrive même à se mettre d’accord sur ce qui constitue le bon sens ?
Si votre application est simple et extrêmement bien conçue, vos utilisateurs peuvent être capables de se débrouiller seuls. Si votre application est plus proche de la box, vos utilisateurs vont avoir besoin d’un petit coup de pouce qu’ils le veuillent ou non.
Mais de quoi les utilisateurs ont-ils besoin, en fin de compte ?
Les gens ont tendance à fuir l’aide utilisateur des logiciels comme la peste. La plupart du temps, leurs problèmes sont simples, et le stéréotype veut que l’aide logicielle soit un manuel épais comme la cuisse ou un wiki impénétrable et farci de concepts velus et de diagrammes accessibles seulement à un astrophysicien armé d’une loupe.
Cette perception ne sort pas de nulle part, même si elle peut être exagérée. Pendant longtemps, l’aide utilisateur a été trop longue et trop dense pour être abordable, et elle l’est parfois toujours, mais ce n’est pas une fatalité.
Quitte à me répéter, les utilisateurs se tournent vers un produit pour accomplir une tâche spécifique. Ils ont besoin de l’information nécessaire à cette tâche et rien de plus. Ils n’ont ni le temps ni la patience de filtrer un gros bloc de texte pour trouver la minuscule pépite d’information qui leur sera utile. Ils sont en revanche prêts à interagir avec l’aide pour peu qu’elle soit facile d’accès, réellement pratique et demande peu d’effort.
La question devient donc de savoir comment leur fournir une documentation qui répond à ces critères.
Aide utilisateur contextuelle embarquée : de grands mots, de grands remèdes
L’aide embarquée est disponible directement dans votre logiciel, plutôt que dans une fenêtre séparée ou sur un portail.
Le contenu contextuel est basé sur des scénarii utilisateurs. Il est court et direct, et ne présente que l’information pertinente dans le contexte. Dans un logiciel, le contexte est souvent la fenêtre, l’onglet ou le panel en cours d’utilisation.
Voici un exemple d’aide contextuelle embarquée :
Cet exemple provient d’un outil de création d’aide utilisateur développé par l’entreprise pour laquelle je travaille, edc.
Nous l’avons précisément développé pour répondre à ces problématiques.
Comme vous pouvez le voir, l’aide logicielle s’ouvre à partir d’un icône discret mais reconnaissable placé directement dans l’interface. Ces icônes sont présents à tous les endroits de la fenêtre qui ont été jugés utiles par le rédacteur technique (ou dans ce cas précis, la rédactrice) (moi, donc).
Lorsque l’utilisateur clique sur l’icône, un panel temporaire contenant de l’information s’ouvre. Cette information est ciblée pour répondre aux questions les plus communes lors de l’utilisation du morceau d’interface concerné. Dans ce cas précis, les questions sont “Pourquoi y a t-il plusieurs types de documentation ? Lequel choisir ?” (ceci reflète mon expérience générale, la plupart des questions de base sont une variation de “Qu’est-ce que ça fait ?” ou de “Comment faire X ?”, peu importe le logiciel).
Les liens mènent vers une aide logicielle plus longue, appropriée pour les cas d’utilisation plus complexes.
Le panel d’aide montre l’information nécessaire pour utiliser le panel Documentation Types et rien de plus. L’utilisateur n’a pas besoin d’analyser ou filtrer l’information, puisqu’elle est pré-filtrée pour lui.
L’aide étant pour ainsi dire en self-service, il peut n’utiliser que les morceaux qui lui sont utiles et n’a pas besoin de s’arrêter en plein élan pour lire.
Consommer l’aide utilisateur fait partie du workflow !
Qu’en pensez-vous ?
Est-ce que vos logiciels préférés bénéficieraient d’une aide logicielle embarquée ?
Utilisez-vous déjà cette méthode pour vos propres contenus ?
