L’atomic design, une méthode de co-création prometteuse

En tant qu’UX/UI designer, il est essentiel de remettre régulièrement en question notre workflow et nos techniques de co-création, pour être toujours plus efficaces sans perdre de vue la qualité et la cohérence d’un projet.

Avec le nombre croissant de sites web responsives et les nouveaux principes d’applications universelles, la façon dont nous concevons nos interfaces est en train d’évoluer. Nous devons prendre en compte un large panel de tailles d’écrans et de résolutions, et des interfaces qui sortent du cadre habituel des écrans (ex : HoloLens, Oculus Rift…)

Nous avons donc commencé à étudier de près l’Atomic Design qui nous semble une méthode adaptée au contexte actuel (et à celui de demain). Les développeurs utilisent déjà ce genre de méthodes depuis longtemps et il est grand temps que la façon de concevoir une interface et la façon de la développer se rejoignent.

L’atomic design : Kesako ?

Brad Frost

L’Atomic Design est une méthode de design par composants, expliquée en détail par le génialissime Brad Frost.

Il part d’un constat simple : la page est un concept datant du livre et que l’on a transposé au web. Mais aujourd’hui, le design par page n’a plus sa place… On ne conçoit plus des pages mais des éléments d’interface qui vont devoir trouver leur place dans des environnements aussi bien immenses (projections sur un mur) que tout petits (écrans de montre connectée).

Get your content ready to go anywhere, because it’s going to go everywhere.

Nous ne devons donc plus penser en « écrans » ou en « pages » mais en systèmes de composants, en éléments modulaires, tout comme Google l’a fait avec le Material Design : une bibliothèque de composants qui s’adaptent aux différents supports.

L’Atomic en détail

Un atome

Exemple d’atome

C’est un élément qui, seul, n’a pas de but fonctionnel. Il est « irréductible », ne peut pas être divisé et il compose la base de tout élément graphique de l’interface.
Ex : un logo, une couleur, un style typographique, un bloc image, une icône, un champ de saisie…

Les molécules

Exemple de molécule

Ce sont des collections d’atomes qui forment des composants d’interface simples.

Les molécules doivent être pensées « responsive ». Il faut définir si elles sont fixes ou fluides, et sur quelles tailles de device elles apparaitront ou non.
Exemple : label + champ de saisie + picto loupe = champ de recherche.

Les organismes

Exemple d’organisme

Ce sont des combinaisons plus complexes de différentes molécules ou de molécules + atomes qui forment une partie de l’interface finale.
Ex : champ de recherche + nav + logo = header

L’analogie scientifique s’arrête là. Tous ces organismes vont servir à composer les interfaces, en fonction des différents supports.

Les templates

Les templates sont les “squelettes” de la page

Dans l’Atomic Design vu par Brad, les templates sont déjà développés en code. Ils peuvent être dépourvus de contenus réels (par exemple, on mettra du lorem ipsum à la place des textes et des placeholders pour les images ou icones). Ils sont là pour vérifier l’organisation et la hiérarchie des divers organismes créés et de tester leurs comportements “responsive”.

Les pages

Les pages sont la version finale d’un écran

Ce sont des templates qui ont évolués vers ce que sera l’écran dans sa version finale. Tous les placeholders ont été remplacés par les vrais contenus (textes, images, couleurs, pictos, organismes et molécules finalisées…).

Les “pages” ne doivent pas être toutes réalisées en maquette. Le but de l’Atomic est de pouvoir créer des systèmes ; les composants sont tous spécifiés graphiquement, les pages non.

Les composants (atomes et molécules) doivent être rapidement intégrés dans un Styleguide.

Quels sont les avantages de l’Atomic Design ?

J’en vois énormément mais je vais citer ceux qui me viennent en tête immédiatement :

Gagner du temps

  • Ne pas décliner tous les écrans (ou tous les points de ruptures pour du responsive)
  • Faire plus rapidement des tests en environnement réels et affiner ensuite
  • Pouvoir factoriser certains éléments entre le design et le développement

Garder une cohérence globale sur les éléments d’interface créés

  • Le fait de créer rapidement une StyleGuide et de fonctionner par atomes oblige à garder une vraie cohérence et à ne pas dupliquer les éléments graphiques du projet.

Mieux s’entendre avec les développeurs

  • Avoir la même logique pour la conception d’une interface que pour son développement (par exemple avec un langage commun entre leurs atomes et les nôtres).

Les allers/retours entre la style guide et les composants du designer (atomes/molécules/organismes) seront sûrement nombreux avant d’arriver au résultat final (en mode test&learn). C’est pour cela que les équipes de conception et de réalisation devront être très proches et travailler ensemble.

Qu’en est-il de la créativité ?

Pour moi la créativité n’a pas à craindre ce genre de système de conception, bien au contraire… On est tous fait du même squelette de base et de la même matière et pourtant les combinaisons sont infinies et les gens sont tous uniques.

Le travail du designer d’interface est de définir la bonne typographie, les bonnes couleurs, les bons rapports de hiérarchies, les bons composants graphiques et de faire marcher ces éléments ensemble, de leur donner du sens.

Le designer pourra également prendre plus de temps pour réfléchir aux comportements animés de ces atomes/molécules… Et bien sûr, suivre les développements (puisqu’ils seront fait au fil de l’eau) afin que le résultat final corresponde à la vision partagée par l’équipe.

Pour aller plus loin :

Tout savoir sur les systèmes de Design

L’atomic design et la créativité

Comment concevoir des systèmes de composants en atomic design ?

TouchUp : concevoir une application à deux, de l’idée à la réalisation