Qu’est-ce que l’Atomic Design ?

RDV Tech powered by Agile Partner

L’Atomic Design est une méthode de conception par composants conçue par Brad Frost, designer américain ayant participé aux projets : This is Responsive, Styleguide.io.

Cette méthode, inspirée du Modular Design, part du constat que l’analogie faite à la naissance du web avec le livre et qui définit le concept de page n’est plus d’actualité. En effet, face à la multitude de supports et de tailles d’écrans auxquels nous sommes exposés aujourd’hui, ce concept n’est plus réaliste.

Analyse réalisée par Nicolas Vardavas – Co-Founder Swipe

Brad Frost propose donc une méthode basée sur une métaphore biologique permettant de créer des systèmes de composants modulaires s’adaptant à tout type de support. Il définit 5 étapes de conception afin de découper une interface : atomes, molécules, organismes, template et page.

L’approche Atomic en détail

Les atomes

Dans la vie les atomes sont des éléments de base de la matière, ici ce sont les éléments de base de notre interface. Ces atomes sont les plus petits éléments de notre système de composants, ils sont donc indivisibles sans perdre leur fonction première.

En pratique les atomes sont des éléments HTML de base tels que des titres (h1, h2, h3…), des éléments de formulaire (input, label, button…) ou des images (logo, icône…). Chaque atome d’interface possède ses propres propriétés uniques. Par exemple : un label aura sa propre taille et sa graisse de police, un champ de formulaire une couleur de fond et une bordure, un bouton sa couleur de fond et une couleur de police.

 

Exemple d’atomes d’interface « label, champ de type texte, BOUTON »

 

Au sein d’un styleguide les atomes vous donnent une vue globale sur l’ensemble de vos styles et déterminent l’identité de la marque.

 

Les molécules

 

 

En chimie les molécules sont des atomes liés entre eux et possédant des propriétés distinctes. Ces mêmes atomes liés à d’autres atomes de natures différentes possèdent d’autres propriétés.

Dans une interface, les molécules sont des groupes d’éléments HTML (atomes) fonctionnants entre eux. Par exemple, un label de formulaire associé à un champ texte et un bouton s’assemblent pour former un formulaire de recherche. Le résultat est un composant simple, portable et réutilisable pouvant être déposé partout où une fonctionnalité de recherche est nécessaire.

Exemple d’une molécule d’interface « formulaire de recherche »

Assembler des éléments en groupe fonctionnels simples n’est pas nouveau mais cela aide les designers et les développeurs à adhérer au principe de responsabilité unique. La création de molécules d’interface simples facilite les tests, encourage la réutilisation et favorise la cohérence dans toute l’interface.

 

Les organismes

Les organismes sont des éléments d’interface plus complexes composés de plusieurs groupes de molécules et/ou d’atomes et/ou d’autres organismes. En général ils forment des sections bien distinctes d’une interface comme par exemple un en-tête (header), une liste de produits, des résultats de recherche.

Prenons ici l’exemple d’un header. Un organisme de type header forme une section autonome d’une interface. Il peut être composé d’un logo, d’une navigation et d’un formulaire de recherche.

Exemple d’un organisme d’interface « header »

Si nous décomposons légèrement cet exemple nous trouvons un atome pour le logo, un organisme/molécule pour la navigation et une molécule pour le formulaire de recherche.

Les templates

C’est ici que s’arrête l’analogie avec le monde de la chimie. Celle-ci nous a servi à mettre en place notre hiérarchie et à construire les éléments de notre système de composants.

Les templates sont donc des zones d’une page qui fournissent un contexte aux organismes qu’ils contiennent. Ce contexte détermine le rendu visuel des éléments qui compose le template en fonction de l’espace accordé par l’écran.

Lors de l’élaboration d’un système de composants, il est essentiel de définir comment ces composants s’assemblent et fonctionnent ensembles dans différents contextes. C’est le rôle des templates de page.

 

Les templates se concentrent sur la structure du contenu et non le contenu de la page. Un système de composants doit tenir compte de la nature dynamique du contenu. Il est donc important de pouvoir se rendre compte de l’évolution d’un titre, d’une image ou d’une liste en fonction de son contexte.

 

Exemple d’un template d’interface « page d’accueil »

 

 

Les pages

Les pages sont des instances des templates précédemment mis en place mais avec du contenu réel. Nous pouvons donc remplir notre précédent exemple avec du contenu réel.

 

Exemple d’une page avec du contenu réel

L’étape de la page est l’étape finale de la conception atomique. Elle est essentielle pour tester l’efficacité de notre système de composants. Du contenu réel peut mettre en avant d’éventuels soucis de conception de nos composants. Si un problème survient il suffit de revenir en arrière et d’itérer afin de le corriger.

Enfin, les pages fournissent le cadre nécessaire à matérialiser les différentes variations des templates. Par exemple, certaines informations sont masquées quand l’utilisateurs n’est pas connecté au site web ou certains news ont un texte d’introduction plus court que d’autres ou tout simplement n’en ont pas.

Les avantages de l’Atomic Design

Il est vrai que d’autres systèmes de composants comme Boostrap ou Foundation existent déjà mais ils ont aussi leurs limites, à savoir :

  • Toute ce qui est produits avec ces systèmes à tendance à se ressembler
  • On doit composer avec beaucoup de composants inutiles
  • On doit aussi souvent compléter certaines fonctionnalités
  • On subit la logique, le nommage, le style… de quelqu’un d’autre

Utiliser l’Atomic Design permets donc de :

  • Passer rapidement de l’abstrait au concret : nous pouvons voir simultanément nos interfaces décomposées en leurs éléments atomiques et observer comment ces éléments se combinent pour former nos expériences finales.
  • Mettre en place un langage commun au sein des équipes et faciliter une meilleure communication entre les designer, développeurs, product owner…
  • Définir un système de composant au sein d’une entreprise fournissant les briques nécessaires à la matérialisation et au test de prototypes dans un contexte réel. Ces prototypes peuvent être réalisés au cours d’ateliers (Design Sprint, LEAN UX).
  • Fournir un styleguide (atomes et molécules) à l’ensemble de l’entreprise permettant d’assurer une cohérence globale sur l’ensemble des interfaces en évitant la duplication de composants.
  • Structurer les développements : l’arborescence SASS peut intégrer les 5 niveaux du design atomique en définissant un répertoire pour chaque niveau. Dans le répertoire “atoms”, on placera un fichier form.scss, un fichier typography et ainsi de suite. Dans le répertoire “molecules”, on placera toutes les molécules de notre site, ainsi de suite pour les organismes et les niveaux suivants.
  • Gagner du temps en évitant de décliner tous les écrans de nos applications ou sites web.

 

Pour conclure

Atomic Design fournit donc les étapes nécessaires à la conception d’un système de composants modulaire. Cette méthode marque une réelle différence avec un fonctionnement plus traditionnel qui part de la conception d’une interface pour ensuite en décortiquer les éléments les plus atomiques. Ici nous allons d’abord créer ces éléments atomiques pour arriver à une interface dans son ensemble.

Il n’est cependant jamais facile de concevoir des systèmes de composants et des styleguides. Atomic Design nous donne quelques clés pour y parvenir. Comme toute méthode il conviendra de savoir l’adapter à nos besoins et notre contexte. Un très bon exemple est un article de de Jeff Crossman qui expose la méthode utilisée par GE pour concevoir leurs applications : https://medium.com/ge-design/ges-predix-design-system-8236d47b0891

 

LIENS 

Le site de Brad Frost : http://bradfrost.com/blog/post/atomic-web-design/

Pour acheter le livre : https://shop.bradfrost.com/

Les excellents articles d’Audrey Hacq : https://medium.com/@audreyhacq

Atomic et architecture SASS : https://subvisual.co/blog/posts/32-our-css-sass-project-architecture-and-styleguide/

Aucun commentaire pour le moment.

Réagissez à cet article

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *