Objectifs, parcours, guide de style, composants, journal des décisions : ce que contient une documentation design utile. Et comment la doser et la garder à jour selon la taille du projet.
La documentation design est l’ensemble des documents qui expliquent ce que l’on conçoit, pour qui, pourquoi et comment : objectifs du projet, public cible, parcours utilisateurs, règles visuelles, composants et consignes de développement. Elle évite de refaire les mêmes débats, facilite le passage du design au développement et garde le produit cohérent dans le temps. Elle doit rester vivante : mise à jour au fil du projet, pas rédigée à la fin.
Sur beaucoup de projets web, on se lance dans les maquettes sans avoir écrit ce qu’on cherche à obtenir. Tant que l’équipe est petite et le projet court, cela tient. Dès que le projet grandit, que des développeurs arrivent ou que le client change d’interlocuteur, les décisions se perdent et l’on tourne en rond. Voici ce que contient une bonne documentation design, comment la doser selon la taille du projet et comment la faire vivre.
- Qu’est-ce que la documentation design ?
- Pourquoi documenter le design d’un projet ?
- Quels documents la composent ?
- Quelle différence avec un design system ou une charte graphique ?
- Avec quels outils la tenir ?
- Quelles bonnes pratiques pour une documentation utile ?
- Faut-il tout documenter sur un petit projet ?
- Questions fréquentes
- Sources
Qu’est-ce que la documentation design ?
La documentation design (ou documentation de conception) rassemble les documents et ressources qui décrivent les aspects importants de la conception d’un produit numérique : site, application, logiciel. Elle répond à trois questions : que construit-on, pour qui, et selon quelles règles ?
Elle se place entre le cahier des charges et la réalisation. Le cahier des charges exprime le besoin ; la documentation design traduit ce besoin en décisions de conception (parcours, écrans, composants, règles visuelles) et garde la trace de ces décisions. Elle sert ensuite de référence commune au designer, aux développeurs et au client.
Dans un article du blog Adobe XD Ideas, le designer Nick Babich résume l’erreur la plus courante : beaucoup d’équipes repoussent la documentation à la fin du projet, faute de temps, alors que ce manque crée de la confusion au moment de la réalisation. Mieux vaut documenter au fil de l’eau.
Pourquoi documenter le design d’un projet ?
Être obligé de décrire un choix de conception par écrit est l’un des meilleurs moyens de vérifier qu’il tient la route. Au-delà de cet effet, la documentation permet de :
- définir et suivre les objectifs du projet, et y ramener les débats quand ils s’égarent ;
- fluidifier le passage au développement : les développeurs trouvent les espacements, les états des boutons ou les comportements sans devoir deviner ni relancer le designer ;
- garder une trace des décisions et de leurs raisons, pour ne pas rouvrir les mêmes questions trois mois plus tard ;
- intégrer rapidement une nouvelle personne, côté agence comme côté client ;
- préserver la cohérence quand le site ou l’application évolue, parfois avec d’autres prestataires ;
- servir de support au client, qui sait ce qu’il valide et peut le transmettre en interne.
Quels documents la composent ?
Le contenu varie d’un projet à l’autre. Ces éléments peuvent tenir dans un seul document ou être répartis en plusieurs, selon la complexité.
| Document | Ce qu’il contient | Pour qui |
|---|---|---|
| Aperçu du projet | Buts, objectifs mesurables, périmètre, principes de conception clés | Tout le monde |
| Exigences produit | Besoins métier et techniques validés avec les parties prenantes, livrables attendus | Équipe projet, client |
| Public cible | Recherche utilisateur, personas, scénarios d’usage | Design, contenu, marketing |
| Parcours utilisateurs | Chemins suivis pour atteindre un objectif, arborescence, wireframes | Design, développement |
| Guide de style | Couleurs, typographies, grille, iconographie, ton éditorial | Design, développement, contenu |
| Bibliothèque de composants | Boutons, formulaires, cartes, avec leurs états et règles d’usage | Design, développement |
| Spécifications de réalisation | Comportements, points de rupture responsive, animations, exigences d’accessibilité | Développement |
| Plan de tests | Tests utilisateurs, critères de validation, recette | Équipe projet, client |
| Journal des décisions | Chaque décision importante, sa date, ses raisons, les options écartées | Tout le monde |
| Consignes d’exploitation | Comment faire évoluer le design après la mise en ligne, qui valide quoi | Client, équipe de maintenance |
Le journal des décisions est souvent absent, et c’est pourtant l’élément qui fait gagner le plus de temps : quand quelqu’un demande « pourquoi le menu est-il fait comme ça ? », la réponse est écrite. Pour les exigences d’accessibilité, appuyez-vous sur un référentiel reconnu comme les WCAG, détaillé dans notre guide pratique de l’accessibilité web.
Quelle différence avec un design system ou une charte graphique ?
Les trois notions se recoupent, mais n’ont pas la même portée :
- La charte graphique fixe l’identité de la marque : logo, couleurs, typographies, règles d’usage sur tous les supports, imprimés compris.
- Le design system est, selon la définition du Nielsen Norman Group, un ensemble de standards pour gérer le design à grande échelle, réduire les doublons et créer un langage commun et une cohérence visuelle entre les canaux. Il contient généralement un guide de style, une bibliothèque de composants et une bibliothèque de modèles (patterns), et il faut des personnes pour le maintenir.
- La documentation design est propre à un projet : elle en décrit les objectifs, les utilisateurs, les parcours et les décisions, et s’appuie sur la charte et, s’il existe, sur le design system.
Pour voir à quoi ressemble une documentation de composants aboutie, les design systems publics sont une excellente source : le GOV.UK Design System du gouvernement britannique, Material Design de Google, ou le Système de Design de l’État français (DSFR), publié en open source. Chaque composant y est présenté avec son usage, ses variantes, ses règles d’accessibilité et son code.
Côté technique, les design tokens gagnent du terrain : ce sont les valeurs de base du design (couleurs, tailles, espacements) stockées dans un format lisible par les outils, pour que la maquette et le code partagent exactement les mêmes valeurs. Le groupe communautaire du W3C consacré aux design tokens a publié la première version stable de sa spécification de format (version 2025.10).
Avec quels outils la tenir ?
L’outil compte moins que l’habitude de mettre à jour. Quelques combinaisons courantes :
- L’outil de maquettage lui-même : Figma permet de documenter les composants dans le fichier et propose un mode développeur (Dev Mode) pour inspecter les maquettes, comparer les versions et relier les écrans à la documentation et au code. Il est disponible sur les offres payantes avec un siège Full ou Dev. Notre comparatif Adobe XD vs Figma revient sur ces outils.
- Un wiki ou un espace de documentation partagé (Notion, Confluence, un simple dossier partagé bien rangé) pour les objectifs, les personas, les parcours et le journal des décisions.
- Un catalogue de composants côté code (Storybook par exemple) quand le projet a une vraie bibliothèque de composants développés.
La règle : un seul endroit fait foi pour chaque type d’information, et tout le monde sait où il se trouve.
Quelles bonnes pratiques pour une documentation utile ?
Écrire pour un lecteur précis
Trois publics lisent la documentation : l’équipe produit (designers, développeurs), les parties prenantes (client, direction) et parfois les utilisateurs finaux. Chacun a ses besoins. Un développeur veut des valeurs exactes et des comportements ; un dirigeant veut comprendre les choix et leurs conséquences. Indiquez en tête de chaque document à qui il s’adresse.
Bannir le jargon, ou l’expliquer
Les abréviations des développeurs ne sont pas toujours claires pour le client, et les designers citent des principes que les développeurs ne connaissent pas. Écrivez simplement et ajoutez un glossaire pour les termes inévitables.
Montrer plutôt que décrire
Une capture annotée, un exemple « à faire / à ne pas faire », un extrait de code valent mieux qu’un long paragraphe. Pour chaque composant, montrez ses états (normal, survol, désactivé, erreur) et un exemple d’usage correct.
La garder vivante
La documentation doit être mise à jour au fil de la conception, pas en fin de projet. Prévoyez une revue régulière (par exemple à chaque fin de sprint ou de phase), datez les documents, indiquez qui en est responsable, et supprimez ce qui est obsolète : une documentation fausse est pire qu’une documentation absente.
La rendre facile à trouver et à parcourir
Tous les intervenants doivent y accéder à tout moment. Une structure claire, des titres explicites, un nommage cohérent entre les maquettes, la documentation et le code évitent de perdre du temps à chercher la bonne ressource.
La tester
Comme tout livrable, la documentation se teste auprès de ceux qui l’utilisent. Demandez à un développeur d’intégrer un écran à partir de la seule documentation : chaque question qu’il pose révèle un manque. Un moyen simple de recueillir les retours (un commentaire, un formulaire) permet de l’améliorer en continu.
Faut-il tout documenter sur un petit projet ?
Non. La documentation doit être proportionnée au projet, sinon elle devient un projet à part entière que personne ne lit.
- Site vitrine de quelques pages : une page suffit souvent. Objectifs, cible, arborescence, rappel de la charte graphique, liste des composants utilisés et décisions notables.
- Site e-commerce ou refonte importante : un document par grand thème (parcours d’achat, fiches produits, composants, règles de contenu), plus le journal des décisions.
- Application métier ou produit qui évolue en continu : là, un vrai design system documenté, avec une personne responsable de sa maintenance, devient rentable.
Le bon réflexe, quelle que soit la taille : commencer la documentation dès le cadrage, en même temps que le brief, et la compléter à chaque étape. Si vous préparez une création de site ou une nouvelle identité visuelle, demandez à votre prestataire quels documents il vous remettra et sous quelle forme : c’est ce qui vous permettra de faire évoluer votre site plus tard, avec lui ou avec un autre.
Questions fréquentes
Qui rédige la documentation design ?
Le designer en est généralement le principal auteur, mais les développeurs complètent les spécifications techniques et le chef de projet tient le journal des décisions. Le client valide les objectifs et les exigences.
À quel moment commencer la documentation ?
Dès le cadrage, juste après le cahier des charges. Les objectifs et le public cible se documentent avant la première maquette ; les composants et spécifications s’ajoutent au fil de la conception.
Quelle différence entre documentation design et guide de style ?
Le guide de style n’est qu’une partie de la documentation : il fixe les règles visuelles et éditoriales. La documentation design couvre en plus les objectifs, les utilisateurs, les parcours, les composants et les décisions.
Le client doit-il recevoir la documentation à la fin du projet ?
C’est souhaitable. Elle lui permet de faire évoluer son site de manière cohérente, de briefer d’autres intervenants et de ne pas dépendre d’une seule personne pour comprendre les choix faits.
Combien de temps faut-il y consacrer ?
Cela dépend de la taille du projet. Documenter au fil de l’eau prend peu de temps à chaque étape ; tout reconstituer à la fin coûte beaucoup plus cher, et le résultat est moins fiable.
