Christophe Le Bot

Pratique de la conception numérique

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 coeur 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 ? »

Evidemment, 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 sytè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éfinion 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…

2 commentaires

Auteur
Daniel GUEYSSET
Date de publication
4 juin 2007 à 21h54

Je ne peux m’empêcher d’approuver cette idée de l’UDOD…
Commencer par la doc technique, oui. En tout cas, la développer en parallèle du produit à documenter est tout à fait judicieux pour ne pas dire primordial !
Ensuite, les méthodes à appliquer dépendent des environnements de conception : Grafcet, SADT… sans oublier TIM (Task-oriented Information Modeling) qui gagne à être connu.
L’utilisateur et son environnement au centre de toute conception : le challenge du XXIe siècle ?


Auteur
Christophe
Date de publication
5 juin 2007 à 10h45

Un designer expérimenté dirait qu’un outil bien fait se passe de documentation… Ce que permet en partie la conception centrée utilisateur, grâce à une analyse approfondie des processus métier.

Dans ce cas, la documentation ne sert plus à comprendre l’outil mais à l’utiliser.

Merci de m’avoir fait découvrir TIM. L’approche semble très intéressante, mais le site officiel est à l’abandon et les liens vers les documents
sont morts. Dommage, j’aurais bien voulu en savoir plus…


* Informations obligatoires