Design Decision Record
24/05/2023
24/05/2023
L'évolution d'un produit se fait par une succession de choix, pris par les designers·euses qui se succèdent au sein de l'équipe, ce qui fait qu'au bout d'un moment la réponse à "pourquoi on a fait comme ça" est "c'est comme ça depuis le début, on ne sait plus trop".
Et si le design se mettait aussi à la documentation ? (brrrrrrr n'est-ce pas ?)
Quand tu es désigné·e volontaire pour écrire la doc. Source : Nathan Dumlao via Unsplash
Écrire de la doc n'est jamais la partie la plus fun d'un projet (en tous cas si ça l'est, c'est que le projet était vraiment pas ouf) mais c'est une partie importante du processus.
L'une des raisons est de garder une trace de ce qui a été décidé. C'est sûrement un peu idiot dit comme ça, mais combien de fois quelques jours / semaines / mois / minutes après avoir pris une décision un membre éminent de la direction est venu vous dire "mais pourquoi on fait ça comme ça" et là... le blanc.
On sait que la décision a été prise, que ça a été validé, mais impossible de se souvenir du moment ou du contexte. Si seulement il y avait de la doc !
Une autre raison est l'onboarding de nouvelles personnes dans l'équipe. Elle aura la chance de trouver de la documentation sur les choix design qui ont été réalisés, elle pourra se plonger dans les réflexions qui ont eu lieu, comprendre comment le produit a été conçu.
Une autre raison est d'éviter de réfléchir cinquante fois sur le même sujet. Par exemple, si vous avez pris une bonne fois pour toute de ne pas utiliser de modale, la prochaine fois que vous vous poserez la question de la modale, vous trouverez directement la réponse dans une DDR avec des ressources etc.
Oui, écrire de la doc ce n'est pas marrant, mais un jour ça te sera utile.
Une DDR - pour Design Decision Record -, directement inspirée des ADR (Architecture Decision Record), est une façon de documenter chaque prise de décision design.
Une décision prise, une fiche DDR créé. C'est un réflexe à avoir. C'est après à vous de voir quel degré de décision doit être conservé.
Quand tu viens d'arriver et qu'on t'explique où trouver la doc.
Les entreprises sont aujourd'hui de plus en plus équipées d'outils de documentation interne, que ça soit tettra, trello,... et pourquoi en ajouter une nouvelle propre au design ?
En créant vos DDR sur Figma (je précise Figma car le template que j'ai créé et disponible un peu plus bas est sur figma), vous êtes dans un environnement que vous maîtrisez et que vous utilisez déjà quotidiennement.
Rien ne vous empêche (et je vous y encourage même) à créer une entrée dans votre wiki interne renvoyant vers le doc Figma de DDR pour qu'ainsi tout le monde puisse avoir accès à ce répertoire de prises de décision.
En premier lieu quelle page est concernée, une sorte de fil d'Ariane sur lequel on peut même mettre le lien direct de la page.
Il existe plusieurs statuts pour les DDR.
En cours : Fiche en cours de réflexion, les maquettes sont en train d’être réalisée mais nous avons connaissance du problème.
En users tests : Les solutions ont été proposées, les tests utilisateurs sont en cours si il y a lieu d’être.
En attente de décision : Les solutions sont identifiées, les tests utilisateurs sont réalisés, on programme la réunion de décision.
Validée : Une piste a été validée, la fiche DDR peut être archivée pour le futur.
En gros, il s'agit de votre problématique en quelques mots. Histoire de pouvoir voir d'un seul coup d'oeil de quoi parle la fiche. La problématique détaillée se retrouve dans contexte.
C'est là qu'on définit le plus précisément possible la problématique. C'est presque là qu'on retrouve au final le brief de départ mais pas forcément. Parfois la création d'une DDR peut aussi venir d'une question survenue plus tard.
C'est aussi ce genre de contexte que l'on va essayer de donner ici.
Toutes les solutions envisagées sont à documenter ici. Il peut s'agir soit simplement de liens vers des maquettes Figma, soit de lien vers des articles, des discussions slack, bref tout ce qui aura été présenté comme une solution possible et envisageable.
L'avantage de faire ça sur Figma est justement de pouvoir ajouter des images, des liens vers des maquettes interactives etc.
On ne va pas se mentir, cette partie sert aussi à couvrir le fameux "mais vous avez envisagé telle ou telle solution" qui arrive en fin de projet par une personne totalement extérieure au projet pour pouvoir le renvoyer vers cette fiche qu'il voit que des solutions vous en avez essayé pas mal.
Le graal de la fiche DDR, la solution retenue et surtout POURQUOI est-ce qu'elle a été retenue.
Est-ce que c'est parce qu'un test utilisateurs a mis cette solution en avant (mettre le lien vers le CR et les résultats) ? Est-ce que c'est parce que l'on cherchait une solution rapide à mettre en place par les équipes de dev ? C'est ici que vous trouverez la réponse à "Pourquoi on a fait comme ça au fait ?"
Une fois la documentation rédigée, il faut aussi la ranger correctement.
De mon côté j'ai pris le parti de mettre toutes mes DDR dans le même fichier et de les trier en fonction de leur statut d'avancement. Ça me permet aussi de suivre l'avancement des différentes tâches et de relancer pour une prise de décision par exemple quand je vois que la fiche est en zone orange.
Travailler sur Figma a aussi l'avantage de pouvoir créer des composants, un composant peut donc être créé par fiche pour ensuite l'utiliser directement dans le projet auquel elle est rattachée. Ainsi la DDR est dupliquée dans la base de DDR mais aussi à l'ouverture du projet. Ce qui permet de voir directement à quelle phase on en est.
J'ai eu l'occasion de mettre en place les DDR lors de la construction du produit d'Invenis. Les DDR sont assez complexes à maintenir mais ça a été une source importante d'informations et elles ont permis de formaliser des prises de décision pour ne pas avoir à justifier les mêmes choses à chaque fois et ne pas revenir sur des décisions prises (en tous cas moins facilement).
La documentation n'est pas dans l'habitude des designers, mais avec l'émergence du métier de design Ops elle va, à mon sens, devenir indispensable.
Si vous êtes intéressés·es par les DDR je vous invite déjà à télécharger et à partager le template, puis à me contacter pour voir comment onboarder vos équipes sur ce nouvel outil.