Utilisateurs stupides et rédacteurs idiots ?

Les utilisateurs sont stupides ? 

Dans son article, Stephen Turbek pense surtout qu'il sont

 "Stressed, Tired, Untrained, Passive, Independent, Distracted".

Oui, mais comment concevoir une documentation pour ce genre d'utilisateurs ?________________________
La documentation du 21e siècle ?

Dans son article "The power of free manuals", Kyle Wiens conclut en recommandant : 

"Rethinking documentation - ...Manual and guides can accomplish amazing things... But our experience has taught us that in order to be really effective, documentation has to be drastically rethought.

Guides and manuals have to be designed to be effective in the world we live today - not the world that we lived in 40 years ago. 

It's the only way that documentation will ever get the respect and the attention it deserves".

Non, mais je vous le demande, de quoi se mêle-t-il, ce Californien ?

La documentation produite en ce 21e siècle est excellente, faite par des professionnels, qu'on se le dise !
____________________________________
Les rédacteurs d'instructions sont des IDIOTS !

C'est ce qu'indique un twitt récent... 

Alors qu'un autre utilisateur se permet de twitter que "Google analytics help is so impossible to understand!"

 

 Ce n'est pas vrai !

La preuve : un rédacteur technique est capable d'expliquer à un conducteur de chariot-élévateur comment freiner :

Parce qu'il est évident qu'un cariste ne sait pas comment freiner... il ne l'a jamais appris.

 

 

____________________________________

La mauvaise documentation peut coûter 13,8 milliards de dollars par an ! 

Des esprits chagrins -en l'espèce, les consultants de chez Accenture- prétendent que la documentation de mauvaise qualité a coûté, aux USA et en 2007, 13,8 milliards de USD aux fabricants de matériel électronique :

" American consumers returned $13.8 billion in electronics in 2007.
Between 60 percent and 85 percent of this equipment was perfectly functional, but the purchasers returned it because of confusing interfaces,  features that were difficult to access, a lack of customer education and weak documentation.

These were all factors that excellent written communication could have solved—yet in its absence, many electronics companies found that they were frustrating customers to the point of initiating a product return, and their credibility was taking a hit."

Mais ça, je vous dis, c'est parce que toute l'électronique, maintenant, est faite dans des pays exotiques, là où l'on n'a jamais entendu parler de véritable documentation technique...

_____________________________________

Le "P" de point mort et la ceinture de sécurité unipersonnelle

  Et pourtant une équipe canadienne vient de mettre en ligne un recueil de perles issues de la documentation pour automobiles. Exemple :

"2013 Chevrolet Volt

Page 9-19: "It can be dangerous to leave the vehicle with the propulsion system running. It could overheat and catch fire. It is dangerous to get out of the vehicle if the shift lever is not fully in P (Park) with the parking brake firmly set. The vehicle can roll.

Do not leave the vehicle when the propulsion system is running. If you have left the propulsion system running, the vehicle can move suddenly. You or others could be  injured. To be sure the vehicle will not move, even when you are on fairly level ground, always set the parking brake and move the shift lever  to P (Park).
See Shifting Into Park on page 9-19."

A ce stade, je crois que le conducteur a compris qu'il faut mettre le levier de vitesse sur "P" quand il se gare...
 
ou alors, chez les Suédois :

" 2009 Saab 9-3 -Page 13: "Only one person per safety belt!"

This kind of limited thinking is probably why Saab went out of business."

____________________________________

Comment en sommes-nous arrivés là ?

A l'évidence, parce que le rédacteur a oublié de se mettre à la place de l'utilisateur final ; il n'a pas voulu le prendre en compte, avec son savoir-faire et son environnement.

 ("Comment ça, l'automobiliste sait déjà qu'à l'arrêt du véhicule, il faut positionner le levier sur P ? il le sait depuis sa première leçon de conduite accompagnée ? vous êtes sûr ?...")

Trop souvent, le rédacteur, une fois qu'il a  à peu près compris à quoi servait

le produit qu'il est supposé documenter, se prend pour Dieu-le-Père, ou même pire, pour Tarzan :

 "Moi, Tarzan-Rédacteur, expliquer que le bouton "ON" sert à mettre en marche. Toi, Jane-Utilisateur, appuyer sur le bouton"

______________________________________

Comment éviter ce travers ?

Un seul mot d'ordre : le minimalisme !

Pourquoi ? Parce que, parmi les principes du minimalisme, on trouve : "Adoptez l'écriture orientée tâches"  et surtout : "Analysez les tâches  de l'utilisateur dans son environnement" .

Par exemple, se souvenir que l'utilisateur peut être stressé, fatigué ou distrait (cf. l'article de Stephen Turbek ci-dessus).

Ah bon... Pourquoi ? 

Parce que l'utilisateur ne va pas ouvrir le manuel pour y trouver la rubrique : Le levier de vitesse au point 'P' (sur une voiture automatique), mais plutôt :

"Le témoin 'petit bonhomme' s'affiche en orange et clignote. Que faire ?"

Minimalisme : les Dix Commandements

A mon humble avis, ceci est à mettre au-dessus de tout 
poste de travail d'un rédacteur technique :

1. Minimalist writing means including the least amount of content that is necessary for user success.

2. New users aren't interested in concepts.They want to jump in and try the product.

3. Minimalist writing means not offending the user's intelligence


________________________________________

4. Remove text about text.Must you tell the reader what the chapter contains, or can you get to the point?

5. Choose an action-oriented approach. Ensure that tasks follow an actual user workflow (a day in the life of...)

6. Include information that is more useful, well-suited to the task, and more action-oriented.

7. To slash verbiage, include fewer words, less description, and no useless information.


 ______________________________________

8. Give users a chance to be successful: get started quickly - jump into a task. 

9. Pay attention to what the user is perceiving,
 what is in their environment.


10. Don't focus on product specs and features; focus on what users need to do to be successful.



_____________________________________________________________
Ces règles sont extraites du webinar du 18 aout 2010, mené par JoAnn Hackos, sur le minimalisme et sponsorisé par Acrolinx [http://www.acrolinx.com/]

Minimalisme : action et réaction ...

Dans son excellente présentation "Designing instructions that work, using the 4 Components Model", Dr. Hans van der Meij  -un des pères du minimalisme- nous rappelle d'emblée, que les instructions doivent être :

Effective  –  enable the user to successfully complete a task
Efficient  –  consume as little time and effort as possible
Satisficing  –  stimulate the user to act and help keep up a positive mood

    

En prenant l' exemple de la carte électronique, Dr. van der Meij démontre la transformation qu'il opère après avoir appliqué ses principes d'efficacité, efficience et de satisfaction.

AVANT_____________________________

 APRES_____________________

L'auteur lui-même nous donne la liste des modifications :

Main differences

• Construction of sub-goals
• Distinction between action and reaction
• Numbered each action step
• Removed alternative method
• Removed conjunctions

Au-delà de la numérotation des étapes et l'élimination des conjonctions -deux règles
bien connues maintenant des rédacteurs professionnels-, ce qui retient vraiment
 l'attention ici, c'est la

"distinction entre l'action et la réaction"




 Mais que vient faire cette loi de la physique dans notre modèle d'instruction ?...

Ce qu'entend Dr. van der Meij, c'est la différence essentielle entre l'action que doit effectuer l'utilisateur et la réaction de l'outil (du produit).

Grosso modo, lorsque l'on donne une instruction de type :

•  Pour démarrer, appuyez sur le bouton vert

on peut indiquer (souvent pour rassurer l'utilisateur)  le résultat de cette action :

      Le logo Coucher-de-soleil-sur-Maubeuge s'affiche.

Nous sommes d'accord qu'il faut bien distinguer

• les tâches -c'est-à-dire les actions que doit effectuer l'utilisateur pour atteindre l'objectif qu'il s'est fixé-

          des

• informations qui n'impliquent aucune action de sa part.                                                                                                                                                                                                                     En général, on fait la distinction entre  :

- l'action de l'utilisateur: numérotation ---> verbe d'action

- l'information : absence de numérotation--> verbe descriptif

-

 Le distingo de Dr. van der Meij est nettement plus expressif, plus précis (et passera certainement mieux dans l'esprit des novices) : toute action d'utilisateur doit amener une réaction du produit (outil).

Ainsi, pour bien marquer la différence, l'exemple de la carte électronique, non seulement numérote les étapes, mais présente les _réactions_ en italique.

 L'utilisateur va s'habituer à cette variante et immédiatement assimiler le processus.

Brillant,  n'est-il pas ?

... comme tout l'ensemble de l'intervention de Dr. Hans van der Meij lors de la conférence Intelligent Energy 2013 à Utrecht (Pays-Bas).

Les idées fausses sur le minimalisme

Documentation figée ?

Dans un article bien détaillé, Joe Pairman reprend les points avancés par Mark Baker qui, lui, prétend que le minimalisme conduit à une documentation inerte ou figée.

La discussion se déroule sous forme de duel très, très webien qui vaut vraiment plusieurs minutes de notre attention.

Première salve : le rédacteur ajoute-t-il une quelconque valeur à la documentation ?

"When technical communicators ask how to get more respect for the profession, Baker replies with another question: In a world where
information is freely available from many sources, how can you add
most value to your organization?"

Mark Baker avance l'idée selon laquelle le minimalisme n'ajoute  aucune valeur à notre production. Pour lui, la documentation est gelée, fixée éternellement : elle n'est pas mise à jour pour tenir
compte de l'évolution du savoir-faire de l'utilisateur.

De plus, il prétend que le minimalisme ne pose pas la question du "pourquoi" et qu'il n'est question que de tâches...

A l'évidence, Mark Baker n'a pas suivi de cours sur le minimalisme et
n'a certainement pas lu le bouquin de Carroll et Hans van der Meij.

Riposte de J. Pairman : le rédacteur n'est pas un chien d'aveugle

Concernant le reproche de la documentation figée (la documentation
ne s'intéresse pas aux besoins de l'utilisateur ni à ses connaissances précédemment acquises),
J. Pairman rappelle que le minimalisme, dans son premier principe, recommande de se focaliser sur les "véritables objectifs de l'utilisateur".

Selon le minimalisme, il n'est plus question de _description_ du produit (l'utilisateur l'a devant les yeux, le produit ; il voit bien son interface).

Seul le rédacteur inexpérimenté commence par décrire les menus, les boutons, et autres futilités.

Au lieu de se mettre à la place de l'utilisateur et s'imprégner de ses besoins, il se comporte en chien d'aveugle :

"Tu vois, là, c'est le bouton OK. Dessus, c'est écrit "OK" et ca veut dire
que tu es d'accord et que tu peux valider".

Le rédacteur dûment formé aux règles du minimalisme se concentre sur les besoins et les tâches que doit accomplir l'utilisateur. Programmer le lave-vaisselle ? Préparer une opération à coeur ouvert ? Moissonner son champ ?... et bien on ne va pas lui décrire les 26 boutons du menu du lave-vaisselle, mais seulement lui donner les 2 ou 3 étapes pour programmer l'appareil. C'est tout... parce que c'est tout ce que veut savoir l'utilisateur.

C'est bien la preuve que le minimalisme tient compte des besoins de l'utilisateur et de son savoir-faire.

Le rédacteur ne va pas indiquer, sur un ton péremptoire, "il faut aiguiser la lame de la moissonneuse" (l'agriculteur le sait depuis sa première faucille), mais rédigera une section sur la procédure recommandée pour enlever les lames (avant de les aiguiser).