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 :

Image for post
Image for post
Tous les supports peuvent désormais afficher des éléments d’interface

Pourquoi alors continuons-nous à concevoir nos produits par “page” ou par écran ?

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.

Jai 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 :

Image for post
Image for post
Avant : on déconstruisait les écrans pour en faire des planches de composants

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 :

Image for post
Image for post
Avec l’atomic design : on part d’une matière de base pour créer une infinité de possibilités

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 :

Image for post
Image for post
Le langage visuel de Netflix : fort, reconnaissable et déclinable

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…

Image for post
Image for post
Réfléchir d’abord par fonctionnalités/parcours clés

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.

Image for post
Image for post
Construire le système en faisant des allers/retours entre les composants et les parcours cibles

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

Image for post
Image for post

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 ?

Image for post
Image for post
Prendre un composant spécifique et le rendre générique

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 :

Image for post
Image for post
Déclinaisons possibles d’un même composant

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 :

Image for post
Image for post
Anticiper le comportement responsive de nos composants

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.

Image for post
Image for post
Travailler sur un détail puis prendre du recul pour vérifier ce que ça donne dans la vision d’ensemble

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

Image for post
Image for post

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.

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 :

Image for post
Image for post
Tous les composants sont liés aux atomes

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 :

Image for post
Image for post
Les bibliothèques partagées : toujours à jour et synchronisées

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.

Image for post
Image for post
Un changement dans la bibliothèque partagée peut se répercuter sur tous les fichiers des autres designers

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 :

Image for post
Image for post
Ma vision du futur : une bibliothèque unique pour alimenter designers & 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…

Image for post
Image for post
Plugin React Sketchapp qui transforme des composants codés en ressources utilisables dans nos designs

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.

Head of product design @Openclassrooms & Design Systems advocate

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store