Blog

Design, Design Strategy, Design Systems, UI Design

Design Systems with Brad Frost

Workshop in Amsterdam

By Audrey Hacq, Lead Designer chez Backelite

La semaine dernière, j’ai eu la chance d’être invitée par Invision France pour assister à un Workshop d’une journée, animé par Brad Frost (oui, oui, le papa de l’Atomic Design 😉 )

Mis à part le fait que cette journée n’avait rien d’un workshop (c’était plutôt une grande journée de conférence avec un seul et même speaker 😉 ), le sujet était très intéressant et nous avons encore appris un tas de choses sur les Design Systems et l’Atomic Design.

Voici ce que je retiens principalement de cet événement.

Qu’est-ce qu’un Design System ?

Un Design System, c’est un ensemble d’outils, de guidelines, de composants, de valeurs et de principes qui vont aider les différents acteurs (designers, développeurs, PO…) à concevoir, réaliser et faire évoluer les produits digitaux d’une même marque.

« A design system is the story of how your organization designs and builds digital products » Brad Frost

Pour aller plus loin : Tout savoir sur les Design Systems

 

Que faire avant de se lancer ?

Le conseil de Brad : ne pas se précipiter tout de suite sur des librairies Sketch ou une pattern librairie codée mais prendre le temps de se poser les bonnes questions :

– Interviewer les équipes pour connaître leurs principales préoccupations et pouvoir ainsi répondre au mieux à leurs besoins
– Faire un inventaire de l’existant
– Faire un workshop de priorisation : où est l’urgence ? Par où doit-on commencer ?
– Établir des principes solides : des principes pour votre Design System en tant que produit et des principes pour les process que vous mettez en place pour y arriver.

Voir aussi cet article : 6 astuces pour tester la pertinence de vos principes de design.

  • Choisir un projet pilote : il est très important de commencer avec un vrai projet qui posera les premières briques de votre système. Ce projet doit être le plus représentatif de votre écosystème digital (composants communs à plusieurs produits ? Technologie représentative de la majorité des projets ? Visibilité et enjeux business du projet ?)

« What 20% can we design and build that can assuage 80% of the wheel reinvention pain? » Dan Mall

Pour aller plus loin : Design Systems pilots scorecards, by Dan Mall

 

Comment être créatif avec un Design System ?

Pour Brad (comme pour moi d’ailleurs 😉 ) il n’y a aucun doute possible : un design system peut et doit encourager la créativité.

Le Design System va permettre d’aller plus vite sur ce que Brad appelle les « Dark Corner » de vos projets : vous savez, ces écrans sur lesquels personne ne va jamais mais qui doivent être là et dont la qualité ne doit pas pour autant être négligée.

Cela permettra de passer plus de temps sur les écrans qui ont eux une forte valeur ajoutée et pour lesquels on pourra, si besoin sortir du système établi.

« Put the creativity where it has to be » Brad Frost

 

Les équipes et le Design system

Le Design System est un produit ; il doit donc avoir son équipe dédiée, tout comme n’importe quel produit digital (PO, designers, dev…).

– Brad Frost compare le travail de cette team à celui des « prep chef » qui préparent tous les ingrédients dont les chefs vont avoir besoin afin qu’ils n’aient plus qu’à se concentrer sur la recette en elle-même.

– Pour lui, il faut recruter dans les équipes des profils mixtes qui ont des connaissances en UI et en développement front-end.

– Les designers doivent comprendre le medium pour lequel ils travaillent et avoir des notions de code (ou au moins comprendre comment ça marche).

– L’utilisation du Design System doit aider les équipes à monter en compétences sur leurs sujets d’expertises :

« Make people smarter just by using it » Brad Frost

 

Brad Frost distingue 2 types d’acteurs autour du système :

 

  1. Les makers (ceux qui font le système)

– Ils doivent avoir une vision globale (« bird eye perspective »).

– Ils font vivre le système et sont à la fois les garants et les plus forts contributeurs.

– Ce sont eux qui valident les changements et les nouveautés à apporter au système.

  1. Les users (ceux qui l’utilisent)

– Ils apportent leur vision spécifique et leurs savoirs concrets sur le déroulement des projets

– Ils donnent leurs retours sur les difficultés qu’ils peuvent rencontrer au quotidien, à l’utilisation du système mais aussi plus largement dans leur manière de faire leur travail.

Article sur le Design system d’Etsy : the people part of design system

 

Nommage et vocabulaire commun

Avoir un vocabulaire commun et partagé est structurant pour un bon Design System.
Nommer les composants prend du temps et doit se faire avec des équipes pluridisciplinaires.

« Naming things is hard » Brad Frost

– Le nom d’un composant ne doit pas limiter ses utilisations futures (ex : « List group » est un bon nom car on pourra utiliser cette liste dans de multiples contextes. « Liste de contacts » ne serait pas un bon nom car il limiterait l’utilisation. Petit tip pour nommer un composant : rendre le contenu générique (lorem ipsum) et demander à quelqu’un d’extérieur au projet : « comment appellerais-tu ce composant ? ».

– Le nom des composants peut être inspiré par les markup CSS.

– Brad Frost n’encourage pas les équipes à utiliser les notions d’atomic (atomes, molécules, organismes…) s’ils ne sont pas à l’aise avec ça.

« Atomic design is more like a mental model » Brad Frost

 

Quelques remarques sur les outils

« Use the right tool at the right time to communicate the right thing » Brad Frost

 

Bootstrap, foundations, Material

Ces Frameworks sont très bien si l’on veut faire des choses simples et standardisées. Mais le plus souvent, les marques veulent se différencier et les frameworks sont souvent « tordus » dans tous les sens pour obtenir un résultat qui au final ne sera satisfaisant pour personne.

Les développeurs les aiment particulièrement car ils sont simples à utiliser. Votre Design System doit donc être au moins aussi simple d’utilisation.

 

Zeplin et autres outils de hand-off

Attention aux outils comme Zeplin qui n’encouragent pas la discussion et le rapprochement entre designers et développeurs !! Le fait d’envoyer tous les éléments sur Zeplin ne devrait pas éviter aux équipes de se parler et aux designers d’aller présenter leur travail aux développeurs.

Dès que possible, il faut privilégier une conversation plutôt qu’un process ou un outil car c’est beaucoup plus efficace :

« Collaboration & communication beat process » Brad Frost

Pour aller plus loin : les outils autour des Design Systems

 

Maintenir un Design System

Un Design System n’est pas terminé lorsque vous avez lancé votre site… Au contraire, l’aventure ne fait que commencer ! Voici quelques conseils de Brad pour maintenir et faire évoluer le système :

– Le Design System doit faire partie intégrante du workflow des équipes (voir par exemple le travail de Google sur les outils Material Design pour les designers et les développeurs).

– Dès le début vous devez vous poser ces questions : qui va maintenir le système ? Comment ? Est-ce qu’on aura un système commun aux différentes plateformes (ios, android, web…) ou un système distinct par plateforme ?

– Mettre son Design System sur une URL publique : cela donne une forte visibilité, une certaine fierté (on assume la façon dont on fait les choses et on le montre) et cela peut-être un très bon outil pour recruter des talents.

– La communication autour du système est également primordiale : Qu’est-ce qui est nouveau ? Quels sont les derniers projets ayant utilisé le système ?

– Les équipes doivent être accompagnées (support, formations, tutoriels, temps de l’équipe coeur dédié pour répondre aux questions)

– On doit donner l’opportunité à chacun de contribuer au système (en mettant à disposition par exemple des formulaires de soumission de nouveaux patterns)

– L’idée est de commencer petit et d’améliorer sans cesse le système avec les retours utilisateurs (feedbacks, questionnaires, suggestions…).

Quelques liens utiles

http://styleguides.io/ : regroupement d’articles, de ressources et de podcast sur les Design Systems.

https://cssstats.com/ : vous montre toutes les variables utilisées dans votre site et permet de faire une première estimation du travail de factorisation qui reste à faire.

http://www.webpagetest.org/ : pour tester les performances d’affichage de votre site et les comparer à d’autres sites.

https://cssguidelin.es/ : quelques bonnes pratiques CSS permettant aux équipes de se mettre d’accord sur les bases avant de commencer à coder.