Votre librairie Sketch n’est pas un design system

C’est le “hot topic” depuis plusieurs mois pour les UX Designers: sketch + Atomic Design = Design system. Et c’est … raté !

J’ai eu l’idée de cet article en répondant à une question judicieuse posée dans le groupe Facebook dédié à Sketch. La question était celle-ci:

D’ailleurs, beaucoup connaissent la différence entre “Design system” et “Atomic design” ? La nuance m’a l’air assez ténue ! J’aimerais avoir vos retours là-dessus !

L’association entre Atomic Design et Sketch est assez régulièrement considérée comme l’approche pertinente pour la création d’un Design system. C’est faux et vrai à la fois. Mais surtout faux :)

C’est faux

Utiliser l’Atomic Design et Sketch, c’est mon quotidien depuis 2016. C’est un workflow qui ne doit pas être systématique mais approprié au projet, au contexte et surtout aux parties prenantes. Utiliser une approche modulaire, c’est changer le paradigme de conception, modifier les livrables entre designers et développeurs et plus encore leur relation au quotidien: je parle alors de “pair designing” où comment un designer et un développeur vont former un binôme pour ne plus travailler chacun de leur côté.

Donc vous avez utilisé l’Atomic Design pour : abandonner un mode de réflexion basée sur le nombre de pages, de gabarits à produire sur un projet, pour adopter une approche orientée autour de systèmes de composants, d’éléments modulaires. Yeaaah !

Et Sketch pour: les symboles simples ou imbriqués, pour la libraire partagée et la puissance de l’outil. Yeaaahhhhh !

Le résultat ? Une libraire de composants. Qui, si vous avez bien travaillé, seront utiles car réutilisables, consistants et cohérents mais qui ne permettront pas de développer facilement un produit. Et au pire, vous aurez une collection de composants inutilisables pour les développeurs ou les utilisateurs.

C’est vrai

Avec cette librairie de composants, si elle est bien conçue, vous avez une partie de votre futur design system. La démarche est bonne mais ce n’est qu’une étape parmi tant d’autres.

Première étape: un design system light

  • Pour atteindre cette étape vous allez avoir besoin d’un développeur front ou encore mieux d’un creative développeur. Ce sera à elle ou lui de créer un code robuste, modulaire et réutilisable.
  • Changez les habitudes de travail. Instaurez du “pair designing”. Les designers UI sortiront de leur zone de confort, qui est souvent “statique”. Le travail collaboratif entre designer et développeur va permettre de confronter des maquettes et réalité du navigateur (dans l’exemple d’un produit “web”). Cela permettra aussi aux développeurs de sensibiliser les designers à leurs contraintes et sera bénéfique à la vélocité des équipes. Un but: pousser le plus rapidement possibles les composants UI vers le code final pour itérer plus rapidement.
  • Instaurez un langage et une nomenclature commun.
  • Profitez en pour mettre en place, si ce n’est pas déjà fait, l’utilisation de Zeplin ou Abstract, le GitHub des designers.

Ce design system light va agréger vos composants UI, les composants front développés, la documentation (ergo, technique …)

Créer un Design System en 1 mois
Pour l’un des clients d’Econocom, j’ai pu récemment concevoir mon premier Design System. Pour continuer dans les…medium.com

Deuxième étape: en route vers un full stack design system

L’effort fourni pour atteindre la première étape et ce design system light est déjà un succès en soit. Si vous voulez aller plus loin, il faudra fournir un réel effort supplémentaire. Atteindre un design system global me semble difficile pour de petites structures et sera plus approprié à des organisation moyennes ou grandes.

Voici une liste, non exhaustive, de tout ce qui peut être pertinent à votre design system:

  • Vos composants UI developpés et hérités de la première étape
  • Toutes la documentation de ces composants: guidelines, usages et comportements …
  • Vos templates de pages
  • Votre libraire Sketch, évidemment.
  • Les guidelines Design (charte graphique, charte éditoriale)
  • Des guidelines UX: pour donner des exemples concrets aux équipes et les guider dans le respect des bonnes pratiques de conception (W3C, ISO 9241–201 …) & normes ergonomiques (HIG d’Apple, Material Design de Google …), Accessibilité et Design inclusif … Mettez à disposition certains livrables UX pour les nouveaux arrivants par exemple (Personas, Userflow …)
  • Guidelines technique: pour respecter les bonnes pratiques notamment liées à l’éco-conception (minifier les CSS, optimiser les images…), l’utilisation de GitHub …
  • Les process de mise à jour: de la libraire Sketch, du code, du design system en lui même …
  • La structure de l’équipe: qui est en charge de quoi …

L’ensemble de ces éléments donnent un cadre à la conception et à la création de vos futurs produits en embarquant UX, accessibilité, design, performance … où comment atteindre, en tant qu’équipe, un haut niveau de qualité.