Bien concevoir, bien suivre : ce qui fait tenir un design dans la durée

Tout commence par les enjeux stratégiques

Avant de parler de composants, il faut parler de ce que le produit doit accomplir. C'est la stratégie qui dicte la méthode, pas l'inverse.

Un produit qui doit s'ouvrir à de nouveaux clients a besoin d'un système très modulaire. Un produit destiné à des utilisateurs non spécialistes a besoin d'une interface qui guide et qui explique. Un produit développé par une équipe à distance a besoin d'une documentation irréprochable.

Chez Adcleek, l'enjeu était de permettre à des personnes qui ne sont pas des spécialistes du marketing digital de commander des campagnes en toute autonomie. Cette contrainte a orienté tout le reste : le niveau de guidage, la place donnée à la pédagogie, la cohérence exigée d'un écran à l'autre.

Un designer qui ne comprend pas ces enjeux produit de belles maquettes qui répondent à la mauvaise question. Je commence donc chaque projet par là, et j'y reviens à chaque arbitrage.

Un design system avant les écrans

Un design system est l'ensemble des règles et des éléments réutilisables d'un produit : ses couleurs, ses styles de texte, ses espacements, ses composants. Je le construis avant de dessiner la première page, pour trois raisons.

La cohérence. Quand chaque bouton est une instance du même composant, il ne peut pas exister deux boutons presque identiques. Le produit paraît plus soigné parce qu'il l'est réellement.

La vitesse. Une nouvelle page s'assemble à partir de ce qui existe. On ne redessine pas, on compose.

La maintenance. Modifier un composant met à jour toutes les pages qui l'utilisent. C'est la seule façon de faire évoluer un produit sans le dégrader.

Chez Adcleek, le design system a été intégré dans Storybook, l'outil où les développeurs documentent et testent leurs composants. Le résultat a été mesurable dans le quotidien de l'équipe : moins d'erreurs d'incohérence, et un développement plus rapide. Chez Nanotera, c'est le design system qui a permis à une plateforme regroupant des fonctions très différentes de rester lisible comme un seul produit.

Des composants pensés avec leurs états

Un composant ne se limite pas à son apparence par défaut. Je le conçois d'emblée avec tout ce qu'il vivra en production :

• ses variantes : un bouton principal, secondaire, en lien ;
• ses états : normal, survolé, désactivé, en erreur ;
• ses cas limites : que se passe-t-il quand le texte est deux fois plus long, quand l'image manque, quand la liste est vide ;
• sa version mobile, quand la structure change et pas seulement la taille.

Ces questions finissent toujours par se poser. Si le designer n'y a pas répondu, c'est le développeur qui tranche seul, au moment où il code, sans avoir la vue d'ensemble.

Des variables plutôt que des valeurs

Je ne saisis jamais une couleur ou une taille de texte à la main. Chaque valeur passe par une variable.

Je garde ces variables peu nombreuses : une palette courte, une échelle de tailles de texte, une échelle d'espacements. Elles portent aussi les déclinaisons du produit. Avec un mode mobile et un mode ordinateur pour les tailles et les espacements, un même composant s'adapte seul en changeant de mode. Avec un mode clair et un mode sombre pour les couleurs, un thème sombre se règle en modifiant quelques valeurs, sans retoucher un seul écran.

L'intérêt dépasse le confort du designer. Ces variables sont exactement celles que les développeurs utilisent dans le code. Quand le design et le code partagent les mêmes noms et les mêmes valeurs, il n'y a plus de traduction à faire, donc plus d'erreurs de traduction.

Prototyper pour décider

Une maquette fixe montre à quoi ressemble un écran. Un prototype montre ce qui se passe entre deux écrans, et c'est là que se trouvent la plupart des problèmes.

Je prototype les parcours clés avant le développement, pour deux usages. Faire tester de vrais utilisateurs, et observer où ils hésitent. Et aligner l'équipe : un prototype met fin aux débats d'interprétation, parce que tout le monde regarde la même chose.

Sur Xola, le tunnel de réservation devait gérer plusieurs personnes et plusieurs moyens de paiement, sur ordinateur, mobile, tablette et bornes en magasin. Ce genre de parcours ne se valide pas sur des images fixes.

Une documentation claire pour les développeurs

C'est la pratique la plus négligée, et celle qui a le plus d'effet sur le résultat final.

Une bonne documentation répond aux questions que le développeur se posera quand je ne serai pas là :

• À quoi sert ce composant, et quand faut-il en utiliser un autre ?
• Quels sont ses paramètres, et quelles valeurs sont permises ?
• Comment se comporte-t-il quand l'écran rétrécit ou que le contenu varie ?
• Quelles règles ne souffrent pas d'exception ?

Je la place là où elle sera lue : dans la description du composant lui-même, pas dans un document à part que personne n'ouvre. Et j'utilise les mêmes noms que le code. Si le composant s'appelle « Carte · Projet » dans Figma, il doit porter un nom équivalent dans le code. Deux vocabulaires différents produisent deux versions du produit.

Être proche des développeurs

La documentation ne remplace pas la relation. Les meilleurs projets sur lesquels j'ai travaillé sont ceux où le design et le développement avançaient ensemble.

Chez Adcleek, je participais aux sessions de planning poker et aux discussions techniques. J'y ai appris pourquoi certaines idées simples à dessiner sont coûteuses à construire, et comment trouver des solutions adaptées aux contraintes réelles.

Sur Xola, l'équipe était répartie entre la France, les États-Unis et l'Inde. La proximité ne pouvait pas reposer sur la présence. Elle reposait sur des échanges réguliers et sur des livrables qui ne laissaient rien à deviner.

Être proche des développeurs, c'est aussi accepter qu'une contrainte technique modifie le design. Un design qui ne peut pas être construit dans le temps imparti n'est pas un bon design.

Le suivi, en trois temps

Concevoir n'est que la moitié du travail. L'autre moitié, c'est le suivi, et il se déroule en trois temps.

1. Suivre jusqu'à la mise en production

Tant que le produit n'est pas en ligne, rien n'est terminé. Je fais la recette : je compare ce qui a été développé à ce qui a été conçu, écran par écran, état par état. Je relève les écarts, et je distingue ceux qu'il faut corriger de ceux qui sont de bons compromis.

Chez Nanotera, ce suivi faisait pleinement partie de mon rôle, de la spécification à la recette des développements. C'est ce qui garantit que l'intention de départ arrive intacte jusqu'à l'utilisateur.

2. Suivre après le lancement

Une fois le produit en ligne, les suppositions deviennent vérifiables. Je regarde comment il est réellement utilisé, et je recueille les retours.

Chez Adcleek, l'analyse des données de l'application a mis en lumière des axes d'amélioration précis, dans la navigation et dans l'accès aux fonctions clés. Des mécanismes de retour utilisateur ont ensuite été mis en place pour orienter les évolutions. Un produit qui n'écoute pas ses utilisateurs après son lancement vieillit très vite.

3. Entretenir le design system

Un design system n'est jamais fini. Sans entretien, chaque nouvelle page ajoute sa petite exception, et la bibliothèque devient un catalogue de cas particuliers.

Trois règles l'en protègent :

• un responsable identifié, qui a le droit de refuser une exception ;
• une règle d'entrée : un nouvel élément ne rejoint la bibliothèque que s'il sert à plusieurs endroits ;
• un audit régulier, pour repérer les couleurs saisies à la main, les composants détachés et les doublons avant qu'ils ne se multiplient.

Les erreurs que je vois le plus souvent

Ces pratiques paraissent évidentes une fois écrites. Dans les faits, quatre erreurs reviennent sans cesse.

Construire le design system à la fin. On dessine les écrans, puis on « range » en créant des composants après coup. Le système hérite alors de toutes les incohérences des écrans, au lieu de les empêcher.

Créer trop de variantes. Un design system avec quarante nuances de gris et douze tailles de bouton n'aide personne à choisir. La contrainte est une qualité : moins il y a d'options, plus le produit est cohérent. Quand j'hésite, je retire une couleur plutôt que d'en ajouter une.

Documenter pour soi. Une documentation rédigée avec le vocabulaire du designer, rangée dans un endroit que les développeurs ne consultent pas, ne sert à rien. Elle doit être écrite pour celui qui la lira.

Considérer la livraison comme la fin. C'est l'erreur la plus coûteuse. Les maquettes validées ne sont qu'une promesse. Ce que l'utilisateur voit, c'est ce qui a été développé, et l'écart entre les deux ne se réduit que si quelqu'un s'en occupe.

La liste que j'applique à chaque projet

• Les enjeux stratégiques sont formulés et partagés avant toute maquette.
• Les couleurs, les textes et les espacements passent tous par des variables.
• Chaque élément répété est un composant, avec ses variantes, ses états et ses cas limites.
• Les parcours clés ont été prototypés et testés.
• Chaque composant est documenté là où il est utilisé, avec les mêmes noms que dans le code.
• Les développeurs ont été associés avant la fin du design.
• La recette a été faite avant la mise en production.
• L'usage réel est observé après le lancement.
• Quelqu'un est responsable du design system.

Aucune de ces pratiques n'est spectaculaire. Ensemble, elles font la différence entre un design qui impressionne en réunion et un produit qui tient dans la durée.