UDOD, User documentation oriented design

Allez, je me lance ! Ce soir, j’invente un nouveau concept : le UDOD (User documentation oriented design).

Après tout, chaque jour, les acteurs du web inventent de nouveaux « concepts », toujours révolutionnaires, avec leurs centaines de termes et abréviations à connaître par cœur pour rester « in » ! On recherche, on découvre, on apprend, on applique, on oublie et on recommence. C’est tout le charme d’internet ! En regardant de près (ou plutôt de loin si on veut prendre du recul), il y a peu de concepts réellement nouveaux, mais ça fait monter le « buzz » ! Le « web 2.0 » en est une caricature…

« Et UDOD, ça apporte quoi de neuf ? »

Évidemment, après avoir dit tout ce que je pense des « révolutionnaires du web », je vais avoir un peu de mal à vous convaincre d’utiliser UDOD… Mais comme je l’applique avec de bons résultats, je me dis qu’il y aura bien quelques intéressés !

Le principe de UDOD est simple : après avoir fait un brief rapide et fixer des objectifs assez larges pour votre nouvelle application (méthodologie Paper prototyping), vous commencez par écrire la documentation de l’utilisateur débutant (« User guide for beginners »). L’intérêt est de poser une fois pour toute une description claire, synthétique et compréhensible de votre application. On devrait donc y trouver au moins :

• une définition de l’application ;
• une présentation des notions fondamentales ;
• une description des fonctions principales et de leur utilisation ;
• une description de l’architecture et de son interaction avec d’autres systèmes ;
• des annexes pour les détails techniques ;
• un glossaire ;
• un index.

Une architecture claire, des notions définies

Certes, cela a un coût. La rédaction est longue et doit être faite par un spécialiste. Cependant, on découvre vite l’intérêt de cette méthode :

• La définition de l’application facilite la compréhension des objectifs pour l’équipe de développement.
• Les notions fondamentales sont exhaustives et définies.
• La description des fonctions donnent l’étendue du travail (orienté tâches) de développement et de conception de l’interface.
• La description de l’architecture pose les bases du noyau de l’application.
• Les annexes précisent les contraintes pour les développeurs.
• Le glossaire définit tous les éléments de l’application.
• L’index permet de valider la cohérence des termes utilisés.

Entendons-nous bien, je n’ai pas dit qu’il fallait finir la documentation avant de faire autre chose, mais bien de commencer par elle. Les autres méthodes de conception viendront compléter UDOD sans accroc :

• Design participatif ;
• Méthodes agiles ;
• User task oriented design pour la conception de l’interfaces ;
• UML pour la modélisation de l’application ;
• Object oriented programming et Aspect oriented programming pour le développement du code ;
• Unit tests pour valider chaque brique fonctionnelle définie par UDOD ;
• et j’en passe…

Des utilisateurs impliqués

L’équipe interne a maintenant de quoi travailler sereinement. Mais il y a mieux encore : UDOD implique très vite les futurs utilisateurs de votre application. Ils peuvent la découvrir avant même qu’elle ne soit codée. Et bien sûr y apporter rapidement des remarques, des contraintes, de nouveaux besoins. Dans le cadre d’une application métier, la qualité des échanges est nettement améliorée. On applique au mieux les méthodes de design participatif !

Une documentation de qualité

Au bout du compte, vous aurez optimisé tous les cycles de développement. Et je garde le meilleur pour la fin : vous avez une documentation utilisateur claire et complète au lancement de l’application ! C’est tellement rare…