Design Systems : Designers, n’oubliez pas vos développeurs

Les Design Systems font sensation depuis quelques temps.
Il s’agit d’une bibliothèque de composants graphiques et en code conçus pour être réutilisables sur l’ensemble des produits d’une entreprise.

À l’heure où les interfaces numériques se complexifient et se multiplient de manière exponentielle, ceux-ci promettent une façon plus vertueuse de faire et maintenir les produits de l’entreprise.

Des grandes entreprises comme Oracle, Axa, Audi, Atlassian ou même le gouvernement des États-Unis se sont déjà lancés dedans, prouvant leur utilité.

Leurs avantages sont nombreux :

  • Cohérence dans l’ensemble des usages
  • Fluidité plus grande entre designers et développeurs
  • Maintenance facilitée
  • Possibilité pour les développeurs de s’appuyer dessus pour créer de nouveaux écrans
  • Endroit fédérateur pour les équipes

Cependant, à l’usage ces design systems présentent également des risques et peuvent même devenir source de surcoût ou de perte pour les entreprises s’ils ne sont pas correctement déployés.

Et ce déploiement, ce ne sont pas les designers qui le maîtrisent mais les développeurs !

Ce sont donc littéralement eux les utilisateurs du design system et eux qui feront le succès de celui-ci. Il est donc impératif de prendre en compte d’eux.
Pourquoi ? Car les risques sont grands si vous ne le faites pas !

Les risques

Un développeur à qui on ne facilite pas le travail agira comme tout autre individu. Il essaiera par tous les moyens de se simplifier la vie. Et ceci inclut donc qu’il préfèrera ne pas utiliser votre travail et directement adapter votre design.

Risque 1 : Faible utilisation

Quand je regarde si mes composants sont utilisés

Adapter votre design signifie qu’il s’inspirera librement de vos propositions et délivrera souvent des expériences dégradées par rapport à ce que vous avez imaginé. Et ce, sans que vous ayez forcément le contrôle ou la vision sur cela.

Et proposer directement le css déjà fait (comme certains logiciels le proposent désormais) ne changera rien. Il le copiera de façon plus ou moins heureuse et le surchargera en fonction de son besoin présent.

Suivant le fonctionnement de l’équipe, cela risque vite de virer au cauchemar…

Risque 2 : Surcharge

Si les développeurs n’utilisent que faiblement votre design system et qu’ils prennent l’habitude de le surcharger dès qu’un problème se présente, c’est l’absence de retours sur les cas que vous n’avez pas prévu graphiquement qui vous guette. Et si retour il n’y a pas, c’est la capacité à évoluer et s’adapter de votre design system qui va en prendre un coup.

Risque 3 : Absence de retours de la part des développeurs

Si votre design system est faiblement utilisé, qu’il est souvent surchargé et que vous n’arrivez pas à le faire évoluer puisque les développeurs ne vous font que peu de retours, c’est la survie même du design system qui se joue. Peut-être pas tout de suite, peut-être pas entièrement mais cela signera en tout cas l’échec de son déploiement.

Risque 4 : Abandon du design system

Les avantages à prendre en compte les développeurs

Cela fait peur ? Pas de panique ! Si vous associez les développeurs à la conception de votre design system, c’est la réussite assurée (ou presque) ! Il y a en effet de nombreux avantages.

Vous possédez l’oeil graphique, c’est vrai, mais n’oubliez pas que le développeur, s’il n’a pas forcément ce talent, possède, lui, la compétence d’évaluer la possibilité, la difficulté et donc le coût de la réalisation de ce que vous avez en tête.

Voyez-le comme un peu comme un chef de chantier à qui vous confiez en tant qu’architecte tous vos rêves les plus fous, sûr qu’il pourra tordre la réalité pour y répondre. Pensez-vous que cela marchera ?

De plus, il possède comme vous une expérience des interfaces numériques, des utilisateurs et cela reste après tout la 1ère personne qui utilisera ce que vous avez imaginé…

Ne négligez donc pas son expertise.

Avantage 1 : L’expertise qu’il vous apportera

Un développeur qui se sent écouté est un développeur qui se sent impliqué. Et s’il se sent impliqué, il aura d’autant plus de facilité à utiliser votre design system.

Avantage 2 : Sa plus forte implication

Qui dit impliqué dit aussi qu’il aura plus de facilité à motiver les autres développeurs à faire de même, à former correctement les nouveaux à votre design system, etc. Mais aussi qu’il en fera la promotion dans les autres équipes. Et cela accélèrera grandement le déploiement du design system à l’ensemble de l’entreprise si de nombreuses personnes expriment l’envie et le besoin de l’utiliser.

Avantage 3 : Il sera votre ambassadeur

Quand le développeur se met à faire la promotion de votre design system

Si les développeurs utilisent activement et massivement votre design system, vous aurez plus de chance d’obtenir des retours de qualité. Ces retours vous permettront alors de pouvoir améliorer et faire évoluer votre design system et donc d’assurer sa survie.

Avantage 4 : Les retours qu’il vous apportera

Créer un design system, c’est bien mais associer les développeurs pour assurer son succès et sa survie c’est mieux ! Les entreprises (tel que Ant Financial qui a créé grâce à cette méthode l’un des design systems les plus réemployés par les développeurs d’autres entreprises !) qui ont créé avec succès un design system l’ont bien compris et font travailler main dans la main leur équipe technique et graphique sur ces projets.

Au final, penser à l’utilisateur de ce que l’on crée n’est pas l’essence même de notre travail de designer ?