Retour d'expérience d'un designer sur l'utilisation des bibliothèques de composants
20/06/2024
20/06/2024
Un peu de contexte : pour la création d'un nouveau produit, je suis arrivé sur un projet pour lequel la brand était encore très loin d'être validée et créée. Alors on m'a dit : "tiens on utilise une bibliothèque de composants avec une UI est déjà intégrée, tu vas utiliser ça, comme ça tu te concentres sur l'UX et on verra pour adapter ça plus tard. BON CHANCE".
Quelques semaines plus tard, voici mon retour d'expérience.
Une bibliothèque de composants permet aux développeurs d’avoir des composants déjà tout prêt (en gros) et aux designers d’avoir une base de travail rapide car tout le design est déjà prêt. Et si je voulais un peu pousser plus loin, l'idée derrière est de se passer des designers qui sont de vraies divas. Comme pour des Lego, vous avez déjà les briques, il n'y a plus qu'à les assembler pour faire le produit que vous avez en tête.
Et comme pour les lego, les couleurs sont déjà définies, les briques existent déjà... ce qui implique souvent que si le design veut en créer de nouvelles la tech va râler et vous dire “promis promis avec des briques existantes on va réussir à faire ce que tu veux la vie de moi”.
[Spoiler Alert] AHAHAHAH
Source : Ravage via Unsplash
On choisit tous ensemble de manière collégiale la bibliothèque la plus adaptée au projet bien sûr !
Enfin ça, c’est dans le monde de oui-oui et le monde de l’entreprise c’est rarement oui-oui. Parce qu’on a :
- d’un côté la tech qui va pousser la bibliothèque basée sur la stack technique qu’ils maîtrisent en jurant que c’est simple d'en modifier le design
- le design qui veut une bibliothèque car le fichier figma de composants existe déjà et est propre en pensant que c’est pas si difficile d’adapter une stack technique
- à un moment quelqu’un va bien finir par se rendre compte que telle bibliothèque est plus accessible que telle autre et ça fera un bon argument d’un côté ou de l’autre
- et pour finir un dirigeant lira un post LinkedIn expliquant que telle boîte a fait une super levée de fonds en utilisant telle bibliothèque donc on doit utiliser celle-là.
Bref, des heures de discussions passionnantes s’offrent donc à nous avant même que le projet débute.
Mon point de vue design c’est donc de ne pas trop s’attacher à la bibliothèque et à son design dans le cadre d’un POC, si derrière vous avez l’assurance de poser votre propre design system.
Mais rappelez cette évidence à la fin de chaque réunion ou de chaque échange. Histoire qu’on ne puisse pas vous dire à la fin “mais on n’avait pas prévu de changer le design pour la livraison finale” ou encore “ah non on ne peut pas adapter cette bibliothèque ça casse tout”.
L’un des avantages principaux à utiliser une bibliothèque de composants, c’est que tout le travail d’UI est déjà fait (plus ou moins) ! Les typos sont posées, les couleurs existent, les boutons sont prêts, les patterns des design system existent déjà.
Vous n’avez qu’à vous concentrer sur l’UX. C’est quand même un sacré avantage dans le cadre d’un POC.
Vous êtes aussi assurés que votre design sera globalement respecté, puisque tout est déjà défini dans la bibliothèque, sauf à travailler avec des devs très mauvais vous ne devriez pas avoir de mauvaises surprises.
Il existe pour la plupart des bibliothèques des fichiers Figma, sketch ou autre (pas encore penpot, mais un jour) tout prêt. Vous n’aurez donc pas à créer le design system de 0 et c’est un sacré avantage.
Tout le travail d’UI est déjà fait ! Oui c’est un peu le revers de la médaille, mais comme tout le travail d’UI basique est déjà fait, vous risquez de vous retrouver avec une application déjà vue ailleurs ou des animations que l’on reconnaît comme venant de tel ou tel courant (le comportement des boutons au clic sur Vuetify par exemple qui est symptomatique de material design).
Il y a donc un vrai échange à avoir avec la partie technique sur ce que vous voulez enlever ou non dès le début des maquettes et de leur intégration.
Les fichiers de travail Figma ou Sketch existants qui reprennent l'ensemble des éléments sont souvent très très lourds et sont assez peu personnalisables.
Vous n'avez sûrement pas besoin de tous les composants et il faudra faire un peu de tri dans le fichier d'origine pour éviter de tout devoir charger à chaque fois, soyez malin et prenez le temps de nettoyer ce fichier de base. Devoir attendre 5 minutes une fois le temps qu'il charge c'est marrant au début, mais après 10 fois c'est exaspérant.
Il faut aussi faire très attention à ne pas trop se laisser influencer par ce que cette librairie pousse et avoir toujours un regard critique aussi bien sur l’usage que sur l’accessibilité. Ce n’est pas parce qu’un usage est poussé par une librairie qu’il ne faut pas le questionner.
Sur Ant, par exemple, les textes sont plutôt petit, ce qui est problématique d’un point de vue accessibilité, et si on agrandit la typo, les marges ne sont plus bonnes, il faut donc les modifier aussi, et ainsi de suite ce qui risque d’aboutir à beaucoup de travail d’intégration qui devra en plus être refait avec une brand et un design system plus définitif.
L’influence peut même aller au-delà, si la bibliothèque qui a été choisie a des boutons plus ou moins gros, vous les organiserez différemment sur votre page. Et si ensuite en réalisant votre UI définitive vous avec une typo différente, avec plus ou moins d'interlettrage par exemple, votre disposition va encore changer. Ne vous laissez pas influencer par une bibliothèque de composants !
Pour moi, d'un point de vue design, les bibliothèques de composants sont très utiles pour réaliser un POC rapide afin de tester des hypothèses si votre maturité d'identité de marque et votre design system ne sont pas encore prêts. C'est dispo, c'est assez propre et c'est souvent flatteur et rassurant car c'est ce qu'on retrouve un peu partout.
Mais, si votre brand est déjà posée, éloignez vous-en rapidement ! Le risque d'être influencé dans les usages est trop grand. Vous allez au final passer beaucoup de temps à essayer de faire rentrer des ronds dans des carrés.
