Bibliothèques partagées Adobe : mode d’emploi
Le fait de pouvoir partager nos ressources quand on est plusieurs UX/UI travaillant sur différents fichiers est devenu essentiel. C’est ce qui permet de respecter la charte et de garantir la cohérence d’un produit.
La solution la plus courante est de regrouper tous les composants du projet dans un gros fichier qu’il faut télécharger. Il faut donc prévenir tout le monde et renvoyer le document à chaque mise à jour ou modification de composant… Pas très évolutif non ?
Pour palier à cela (et toujours dans ma quête de mieux concevoir en atomic design) je me suis donc penchée sur les bibliothèques partagées et on peut même dire que je suis carrément tombée dedans ;)
Intro sur les bibliothèques partagées Adobe
Les bibliothèques Adobe permettent à plusieurs personnes travaillant sur un projet d’utiliser les mêmes composants. Ces composants agissent comme des symboles (ou des objets dynamiques externes) et une fois drag&droper dans le document ils restent liés à la bibliothèque. Une mise à jour du composant dans la bibliothèque mettra à jour toutes les occurrences de ce composant.
La bibliothèque s’affiche en se rendant dans l’onglet “fenêtre/bibliothèques”. Elle peut accueillir des couleurs, des styles de textes, des styles de paragraphes et des composants.
La bibliothèque partagée devient le point de référence unique, toujours le plus à jour et partagé entre tous les designers.
Créer un nouveau composant
Ce qui est fabuleux avec ces bibliothèques, c’est qu’on peut y mettre toute sorte de composants : des plus simples (atomes, molécules) aux plus complexes (organismes, templates et pages).
Avant d’intégrer un composant dans la bibliothèque il faut toujours se demander comment il va être utilisé dans les maquettes. Avec déjà plusieurs bibliothèques partagées à mon actif, j’ai appris quelques astuces bien utiles qui pourront sûrement servir à d’autres…
Prévoir les zones de touch
Prévoir la zone de touch d’un composant permettra de ne pas le “coller” à d’autres composants et de respecter sa “zone de touch” lors de la conception. Par exemple, on intégrera un bouton de 27 px dans un carré transparent de 44 px :
Astuce : si le composant est dans un groupe nommé avant d’être ajouté dans la bibliothèque, il prendra alors directement le nom de ce groupe.
Penser les composants en “bloc”
Le but premier de ces composants va être d’accélérer la construction des écrans. Il est donc intéressant de les penser directement comme des blocs, des briques de lego qu’on va pouvoir empiler les unes en dessous des autres.
Astuce : le fait d’intégrer le composant dans un cadre un peu plus grand permet également d’anticiper des évolutions (puisque pour le moment, les composant Adobe ne vivent pas très bien les changements de taille…).
Découper les composants en sous-composants
Au départ, j’avais tendance à faire directement des composants trop complexes. Pour un menu et ses états de survol par exemple, ma première idée était de faire un organisme par déclinaison… Mauvais idée ! Car si l’icône “Votre profil” venait à changer, je devais alors répercuter la modification sur 7 composants différents :
En re-découpant le composant en molécules je n’ai plus que 2 composants à modifier si cette icône change ;)
Utiliser des composants existants
Pour retrouver un composant (dans mes bibliothèques qui en contiennent parfois plus de 200), j’utilise principalement la recherche. Attention toutefois de bien cocher “bibliothèque active” pour rechercher uniquement dans cette bibliothèque.
Il y a ensuite deux façons d’utiliser les composants de la bibliothèque :
importer l’élément lié ou importer la copie.
Importer l’élément lié
Cela veut dire qu’on importe une occurrence du composant qui devient donc un symbole. Si ce symbole est modifié dans la bibliothèque, cette modification s’appliquera partout où il a été utilisé.
Il est intéressant d’utiliser cette importation pour des composants récurrents dont la modification devra être répercutée partout et qui n’ont pas besoin d’une personnalisation de texte (icônes, switch natifs…).
Astuce : on peut revenir à la version vectorisée du composant (et donc rompre le lien au symbole) en allant dans les options du panneau “liens” et en cliquant sur “image(s) incorporée(s)”.
Importer la copie
Cet élément n’est donc plus lié à la bibliothèque.
Cet import est obligatoire dès lors qu’on veut retravailler le composant et non pas l’utiliser tel quel (Par exemple s’il contient du texte que l’on veut pouvoir éditer).
Modifier un composant existant
Avoir une bibliothèque partagée dont une modification va potentiellement affectée une vingtaine de fichiers différents peut vite devenir dangereux si elle n’est pas correctement gérée.
Adobe permet donc de définir des “garants” de cette bibliothèque, qui seront les seuls à avoir les droits de modifications. Pour cela, il suffit de se rendre dans les options de partage de la bibliothèque.
Pour modifier un composant, on peut :
- Faire un “ALT+double-clic” directement sur le composant
- Double-cliquer sur son image dans la bibliothèque
- Passer par le panneau «lien» / «modifier l’original»
Cela permet de se rendre compte que l’on va modifier un “master” et qu’on va donc impacter toutes les occurrences liées.
Il faut anticiper, mesurer et prévoir tous les impacts de la modification d’un composant avant de la faire.
Attention : le changement de taille d’un composant est aujourd’hui mal (voire pas) géré. Il faut donc éviter, autant que possible de modifier la taille d’un composant une fois qu’il a été utilisé à plusieurs endroit. Si vous devez le faire quand même, il vous faudra repasser à la main sur tous les fichiers utilisant ce composant pour le remettre au bon format.
Et Sketch dans tout ça ?
Je travaille encore sur Illustrator pour certains projets, mais Sketch devient peu à peu mon petit favori. Et les bibliothèques Adobe, bien qu’elles soient déjà très intéressantes ne sont pas encore assez “dynamiques” à mon goût.
J’ai donc testé ce principe de bibliothèques partagées sur Sketch, grâce au plugin Craft.
Voici une liste des principaux avantages et inconvénients que j‘en retiens :
Les plus
- pouvoir utiliser un serveur autre que le cloud d’Adobe pour stocker les composants (Drive, Dropbox, Box)
- pouvoir du coup avoir un versioning des composants
- pouvoir trier les composants et les classer dans des “dossiers”
Les moins
- le plugin Craft est très peu ergonomique (on ne sait pas vraiment ce qu’on va modifier, ce que ça va impacter…)
- c’est un plugin et donc ses évolutions ne sont pas toujours liées aux évolutions de sketch (difficile du coup de baser tout un workflow sur ça…)
- pas de système de droit d’écriture/lecture
- le côté “overrides” des symboles ne marche pas avec les composants partagés, ce qui est vraiment très dommage car cela ajouterait un vrai plus par rapport aux bibliothèques Adobe.
En savoir plus sur le plugin Craft
Ceci étant dit…
Finalement, ni Adobe ni Craft ne sont totalement satisfaisants pour moi aujourd’hui lorsqu’il s’agit de travailler en atomic design. Les composants devraient être plus dynamiques (symboles avec textes éditables et taille modifiable, couleurs et styles de textes liés…).
Mais on assiste tout-de-même à une petite révolution de nos métiers et du travail en équipe. Et avec de nouveaux logiciels de co-création comme Figma, on imagine facilement que le partage de composants n’en est encore qu’à ces premiers balbutiements…
Si vous aussi vous êtes passionnés par les bibliothèques partagées et/ou que vous avez expérimenté Adobe, Sketch ou même d’autres solutions, n’hésitez pas à partager votre point de vue dans les commentaires !
