Comment concevoir un système de composants en atomic design ?
Aujourd’hui, n’importe quel support peut potentiellement afficher des éléments d’interface avec lesquels nous pouvons interagir :
Pourquoi alors continuons-nous à concevoir nos produits par “page” ou par écran ?
Alors que finalement ce que l’on veut créer, ce sont bien des systèmes de composants vivants, évolutifs et qui s’affranchissent du support sur lequel ils seront affichés.
C’est en partant de ce principe et en s’inspirant du Modular Design que Brad Frost a imaginé cette méthode, l’Atomic design, dans laquelle tout part du plus petit élément de l’interface : l’atome. Et cette métaphore, ce schéma mental, nous permet de mieux comprendre ce que l’on souhaite créer et surtout comment on va le créer.
J’ai tout de suite été convaincue par cette approche qui permettait enfin de réfléchir au détail et à l’ensemble en même temps, d’avoir une vision globale d’un produit ou d’une marque et aussi de se rapprocher de la façon de travailler des développeurs.
Et je me suis dit :
“Mais bien sûr, c’est comme ça qu’il faut travailler !”
Hum… Facile à dire ;)
Sauf qu’il m’a quand-même fallu plusieurs mois et quelques projets concrets avant de me faire une idée de ce que signifiait vraiment “concevoir en atomic” et ce que ça impliquait dans mon quotidien de designer.
Je propose dans cet article de détailler un peu plus ce que j’ai appris et ce qu’il ne faut pas perdre de vue quand on veut concevoir un système de composants en s’inspirant de l’atomic design.
Pour quel types de projets ?
J’estime personnellement que tous les projets, petits ou gros peuvent être conçus de manière atomic.
Sur les gros projets, ça aide à organiser les équipes autour d’une vision communes. Et sur les petits projets, ça permet d’avoir tout de suite une vision plus globale et donc beaucoup plus évolutive. Les composants ainsi créés sont plus facilement modifiables, déclinables et réutilisables. Et finalement, tous les petits projets peuvent être amenés à devenir grands un jour, non ?
Et contrairement à ce qu’on pourrait croire, l’atomic design n’est pas réservé aux projets web… Bien au contraire ! J’ai pu initier une démarche atomic sur un projet personnel (une application iOS de gestion de contacts nommée TouchUp) et le développeur avec qui j’ai travaillé a vraiment apprécié la démarche. Cela nous a fait gagner beaucoup de temps quand nous avons rapidement voulu faire évoluer le produit.
Si vous souhaitez plus de détails sur la manière dont nous avons travaillé ensemble, allez jeter un oeil à l’article “TouchUp : concevoir une application à deux, de l’idée à la réalisation”
Et pour ceux qui n’ont pas fait spécialité physique/chimie au bac ou qui se demandent si on peut construire un système de composants tout en restant créatif, vous pouvez également lire “L’atomic design et la créativité”.
Comment on faisait avant ?
Alors, j’ai souvent des personnes qui me demandent :
“Mais c’est quoi la différence avec la façon dont on travaillait avant ?”
Moi je vois ça comme une manière légèrement différente de voir la conception et le design d’interface mais qui peut changer beaucoup de choses au final.
On part du plus petit pour construire le plus grand.
Hier, on faisait tous nos écrans, puis on les découpait en petits composants pour en dégager des spécifications et en faire des UI Kits :
Un des soucis avec ça c’est que la bibliothèque de composants ainsi créée n’avait pas été pensée ni de manière atomic, ni de manière générique. La ré-utilisation des composants était donc très limitée : on était sur un système restreint.
Aujourd’hui l’idée avec l’atomic design, c’est bien de commencer par créer notre matière première (les atomes) qui servira à tous les designers qui vont travailler sur le projet :
On a donc non seulement un air de famille entre tous les écrans qui partent de cette même matière de base, mais aussi un système offrant des possibilités de design quasi infinies (pour peu que le système soit assez riche bien-sûr).
Commencer par l’identité de la marque
Alors vous allez me dire :
“Mais par quoi on commence quand on veut concevoir en atomic ?”
Ben je dirai, assez logiquement : par les atomes ;)
Donc la première chose qu’on va faire c’est de s’appuyer sur un langage visuel unique duquel découlera tout le reste.
C’est ce qui va définir nos atomes, notre matière première et c’est évidement très lié à l’identité de la marque. Ce langage visuel doit être fort, déclinable et s’affranchir du support sur lequel il va être affiché ; il doit marcher partout !
L’agence Gretel par exemple a fait un travail remarquable sur l’identité du produit NETFLIX :
Et grâce à cette identité forte, on sent qu’on a toute la matière pour dégager nos premiers atomes : des couleurs, des choix typographiques, des formes, des ombres, des espaces, des partis pris de construction et d’animation…
Il est donc essentiel de passer du temps sur la construction de cette identité en réfléchissant à ce qui fait la différence, l’unicité d’une marque ou d’un produit.
Affiner le système
Une fois qu’on a cette matière de base (finalement assez abstraite) on va pouvoir créer nos premiers composants, en fonction des objectifs du produit et des premiers parcours cibles qu’on aura identifiés.
Partir des fonctionnalités clés
Ce qui fait très peur aux designers qui commencent un système de composants c’est de devoir faire des composants qui ne sont rattachés à rien… Alors évidemment, on ne va pas créer un composant de panier de shopping si notre produit ne comporte aucune fonctionnalité d’achat !
Les premiers composants vont être étroitement liés au produit ou à la marque et à ses objectifs.
Et j’insiste sur le fait qu’une fois encore et afin de sortir de cette conception “par page” on va bien partir de fonctionnalités ou de parcours cibles, non pas d’écrans…
On va se concentrer sur la fonctionnalité ou l’action que l’on veut faire faire à l’utilisateur et sur les composants dont on va avoir besoin. Le nombre d’écrans qui en découlera variera ensuite en fonction du contexte : on aura peut-être besoin d’une moitié d’écran sur desktop pour faire cette action versus trois écrans consécutifs sur smartphone…
Faire évoluer le système
Ensuite et pour alimenter le système, on va sans arrêt faire des allers/retours entre les composants déjà créés et de nouveaux parcours clés.
Les premiers composants aideront à créer les premiers parcours et les premiers parcours viendront créer de nouveaux composants dans le système ou faire évoluer les composants existants.
Penser générique
Quand on conçoit en atomic, on doit toujours garder en tête qu’un même composant va pouvoir être décliné et ré-utilisé dans des contextes potentiellement très différents.
On va donc faire une vraie distinction entre la structure d’un élément et son contenu.
Par exemple, si je crée un composant “liste de contacts”, je vais très rapidement le rendre générique et le transformer simplement en composant “liste”.
Je vais ensuite réfléchir aux différentes déclinaisons possibles de ce composant : Et si j’ajoute un élément ? Et si j’en retire un ? Si le texte passe sur 2 lignes ? Quels seront les comportements de ce composant ?
Le fait d’avoir anticipé les déclinaisons possibles de ce composant va me permettre ensuite de partir de ce composant pour en créer d’autres :
Ce travail d’abstraction est nécessaire si l’on souhaite un système de composants efficace et réutilisable mais également riche et varié.
Penser fluide
On a encore parfois trop tendance à traiter le responsive design comme une réorganisation de blocs sur des breakpoints définis.
Or, c’est bien chaque composant qui doit avoir ses propres breakpoints et ses propres comportements fluides en fonction du support d’affichage.
Et grâce à des logiciels comme Sketch, on peut enfin tester les différents comportements responsive de nos composants et définir ce que l’on souhaite rendre fluide ou au contraire ce qui doit rester fixe :
On peut ensuite aller plus loin en transformant totalement un composant ou en le remplaçant carrément par un autre, dans un contexte spécifique. Par exemple un bouton aux coins arrondis sur mobile deviendra peut-être un simple cercle avec une icône sur smartwatch.
Réfléchir au détail et à l’ensemble
Une des choses vraiment intéressante lorsqu’on choisit de construire son système de composants en atomic design, c’est qu’on a conscience qu’on crée un ensemble d’éléments dépendants les uns des autres.
On va donc sans cesse faire un travail de zoom et de dé-zoom.
On va passer du temps sur un détail, une micro- interaction, l’affinage d’un composant puis on va prendre du recul, vérifier ce que ça donne dans un contexte, puis se reculer encore pour voir ce que ça donne dans l’ensemble.
C’est comme ça que l’on va affiner l’identité de la marque dont on parlait tout à l’heure, faire évoluer les composants et vérifier que le système fonctionne.
Factoriser son design
Tous nos composants sont liés à nos atomes. Et comme tout est lié, on va pouvoir facilement faire des modifications sur une partie du système et vérifier la répercussion sur l’ensemble !
On a une chance infinie aujourd’hui en tant que designer : on a enfin des outils qui sont adaptés à la création de systèmes vivants et évolutifs.
Je pense bien-sûr aux logiciels comme Sketch ou Figma qui nous permettent de créer des styles partagés et de factoriser les composants semblables mais je suis sûre que beaucoup de logiciels de ce type vont voir le jour dans les prochaines années.
On peut enfin, tout comme les développeurs, avoir notre propre Style Guide et construire tout notre système autour de ce style guide. Une modification sur un atome de notre système se répercutera automatiquement sur l’ensemble des composants qui utilisent cet atome :
On se rend compte ainsi très rapidement des répercussions de la modification d’un composant sur le système entier.
En liant tous nos composants les uns aux autres, on prend également conscience que si on crée un nouveau composant, c’est bien le coeur du système qu’on va être impacté, pas juste un écran isolé.
Partager le système
Le partage du système de composant est essentiel pour garder une cohérence entre différents produits.
On le sait, on peut très rapidement perdre cette cohérence, déjà quand on travaille seul mais encore plus quand on travaille à plusieurs, ce qui nous arrive de plus en plus souvent.
Et là encore (petits chanceux que nous sommes ;) nous avons des outils qui commencent à être opérationnels pour réellement travailler en équipe autour d’un système commun.
Je pense aux bibliothèques partagées comme le plugin Craft pour Sketch ou celles d’Adobe par exemple, qui permettent d’avoir une seule source, accessible par tous et toujours à jour :
Cela permet à plusieurs designers de partir de la même base pour commencer leur design.
Cela permet également de factoriser le travail car si on met à jour un composant dans cette bibliothèque, la modification viendra automatiquement se répercuter sur tous les fichiers de tous les designers qui utilisaient ce composant.
Je dois avouer que pour le moment, sur les différentes bibliothèques partagées que j’ai testées, je n’en ai pas encore trouvé une qui soit totalement adaptée pour travailler en atomic…
L’autre souci avec ça, c’est qu’on a encore deux bibliothèques distinctes : celle des designers et celle des développeurs… Il faut maintenir les deux en parallèle, ce qui est source d’erreur et demande beaucoup de travail supplémentaire.
Ma vision de la bibliothèque partagée du futur serait celle-là : une seule bibliothèque qui alimenterait à la fois les designers et les développeurs :
Et quand je vois un plugin comme React Sketch app (lancé récemment par Airbnb) et qui promet des composants codés en React directement utilisables dans nos fichiers de design, je me dis que ce futur n’est peut-être pas si lointain…
Le mot de la fin
Vous l’aurez compris, je suis convaincue que ça n’a que du bon de concevoir nos interfaces par composants en réfléchissant à un système vivant et évolutif, et je pense que des démarches comme l’atomic design peuvent nous aider à le faire correctement.
Et pour aller plus loin :