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).

Analyser les tâches de l'utilisateur (User and Task Analysis)

Le premier principe de la rédaction minimaliste est de "choisir une approche orientée tâche"

Mais alors, comment se focaliser uniquement sur les tâches et les actions de l'utilisateur ?  Où les trouver, ces tâches-actions ?

En effet, le minimalisme nous demande de "respecter l'activité de l'utilisateur".

Mais comment analyser les tâches de l'utilisateur ?

Dans leur manuel User and Task Analysis for Interface Design, JoAnn Hackos  et Janice Redish nous guident pas à pas dans notre quête des activités de l'utilisateur, 
sachant que nous, rédacteurs, n'avons pas vocation à obliger l'utilisateur à 
suivre nos indications. 

L'essentiel est d'établir un lien étroit entre les concepteurs du produit (dans le cas présent, les rédacteurs) et les utilisateurs.

On définit l'analyse des tâches comme les processus d'interaction entre les concepteurs et les utilisateurs.

• Pour les rédacteurs, il s'agit de se familiariser avec l'ensemble des actions des utilisateurs de base en les OBSERVANT pendant le déroulement de leurs activités.

Il n'est pas question ici d'interroger un groupe d'utilisateurs, en dehors de leur contexte, ni de se contenter d'interroger les managers (qui  eux n'ont qu'une vague idée des tâches quotidiennes des utilisateurs).


D'ailleurs, très souvent, l'utilisateur n'a pas vraiment eu l'occasion de prendre du recul et s'interroger sur les actions qu'il accomplit.
.

Il faut donc OBSERVER les utilisateurs dans leur contexte et repérer :

• quels sont les buts de l'utilisateur (terminer aujourd'hui, à 17 heures, les feuilles de paie de l'ensemble du personnel)
• quelles sont les tâches que l'utilisateur va exécuter pour atteindre son but (compléter un fichier Excel, se connecter au logiciel de paie ou sortir papier, crayon et calculette ?)
• quelles sont les caractéristiques professionnelles et culturelles de l'utilisateur (son âge, son expérience, son ancienneté dans l'entreprise...)
• quel est son environnement physique (bureau paysager bruyant, bureau sombre au fond du couloir, etc.)
• quelle est l'influence de ses expériences professionnelles précédentes (facon de penser et d'aborder le travail, réminiscences...)
• quelles sont les attentes de l'utilisateur  vis-à-vis du nouvel outil (encore quelque chose de nouveau, encore quelque chose à apprendre, le système actuel est très bon, pourquoi changer, ou alors : enfin un logiciel performant !) ?

En observant et écoutant, le rédacteur peut faire la liste des tâches que l'utilisateur doit accomplir et comprendre ses contraintes.

C'est déjà le bon début pour un manuel minimaliste et utile !