La réponse théorique à cette question est oui. Mais en pratique, ce n’est jamais vrai.

Le but d’une documentation n’est plus de tout décrire tout simplement car c’est impossible. Personne ne veut plus investir dans ce genre d’approche. La documentation doit être une valeur ajoutée au logiciel. Si ce n’est pas le cas, il faut probablement revoir sa conception.

Les objectifs de la documentation doivent être définis en tant que valeur ajoutée par les chefs de projet et les responsables produit :

  • Je veux réduire les coûts de formation.
  • Je veux que moins de personnes appellent le support pour de l’aide basique.
  • Je veux que les utilisateurs adhèrent à l’adaptation de leurs procédures techniques dans mon logiciel
  • Je dois expliquer en quoi mon produit sort des sentiers battus

Je veux impliquer mes utilisateurs facilement

Dois-je tout décrire ?

A nouveau, la réponse est non.

Si vous devez paraphraser l’interface ou décrire comment contourner les carences ergonomiques, vous devez repenser la terminologie et l’ergonomie de l’interface. Les rédacteurs techniques ont un rôle important à jouer dans la conception des interfaces. Très souvent, les éditeurs de logiciel ignorent cette phase clé de conception.

La plupart des éléments de l’interface devraient être explicites. Il s’agit ensuite d’écrire la documentation en tant que valeur ajoutée de procédures clairement décrites.

Une documentation contextuelle in-situ doit expliquer ce que l’interface ne peut pas décrire pour des raisons d’ergonomie. Elle doit proposer des blocs d’information expliquant les objectifs, les procédures et les concepts clés à comprendre.

Les informations complémentaires sont détachées d’une instance particulière de l’interface du logiciel (elles ne sont pas contextuelles). On les connecte à l’aide contextuelle au besoin. Déterminez ce qui est vraiment nécessaire en vous mettant çà la place de l’utilisateur – je me situe à cet endroit du logiciel, à quoi dois-je faire attention ? Sur quoi l’éditeur doit-il attirer l’attention ?

Par exemple, éviter la frustration de l’utilisateur, les erreurs dans les procédures, ou encore améliorer la courbe d’apprentissage.

La validation doit adopter une approche éditoriale. Cela signifie que le projet dans son ensemble doit être géré comme un projet éditorial, et afficher des buts précis.

Une interface explicite

Obtenir une interface explicite est souvent le fruit d’une conception réfléchie et de tests venant de tierces personnes. Par tierce personne nous voulons dire quelqu’un d’autre qu’un développeur. Les anciens logiciels ont tendance à s’adresser aux initiés tandis qu’une nouvelle tendance est d’en faire trop. Il est préférable d’arriver à un équilibre entre les deux, surtout lorsque l’on s’adresse à une base d’utilisateurs sectorielle connue.

Comment éviter de tout écrire ?

Ayez l’objectif d’écrire une documentation qui couvre un pourcentage prédéfini des procédures logicielles et de l’interface. Puis exploitez les retours utilisateurs venant des équipes support pour ajouter de l’information complémentaire. Ceci va améliorer la satisfaction des utilisateurs envers le cycle de vie du produit et montrer à la fois de la réactivité et de l’intérêt pour l’expérience utilisateur.

Puisque nous parlons aussi d’implication des utilisateurs, les personnes utilisant votre produit peuvent contribuer de manière importante à l’enrichissement du système d’information gravitant autour du logiciel. C’est ici que le paradigme change. Les utilisateurs savent généralement ce qu’ils souhaitent faire dans le logiciel et peuvent contribuer à l’information autour du produit si on leur donne le moyen de le faire au travers des services d’assistance ou des systèmes documentaires. Capter l’expérience utilisateur améliore la pertinence de l’information livrée avec un produit. Les nouvelles tendances vont s’orienter vers des bases de connaissances utilisateurs en lieu et place de la seule documentation, et vers le développement de communautés d’utilisateur pouvant enrichir une base de clients-utilisateurs.