En deux tweets

  • Le design system est le garant de la cohérence de votre ou vos produits/fonctionnalités.
  • Un design system est un produit à part entière : il a constamment besoin d’évoluer.

Le contexte

Premier jour de conférence et premier atelier. Dans une petite salle climatisée à l’américaine, les quelques trente personnes venues du monde entier ont eu la chance d’assister à une belle démonstration du sérieux et de la rigueur de l’équipe en charge du design system chez Salesforce.

Jina Anne — Design Systems — 23 Mai 2017

C’est Jina Anne qui est venu nous exposer sa vision des design systems, Jina est Design system lead chez Salesforce ; elle sait de quoi elle parle lorsqu’elle nous explique les positionnements pris et les problématiques auxquelles son équipe est confrontée au quotidien.

Pour ceux qui souhaitent voir à quoi ressemble l’un des design systems les plus aboutis qu’il soit donné de voir aujourd’hui, c’est ici : https://www.lightningdesignsystem.com/

Jina Anne c’est une développeuse, une designer, une manager et une écrivaine. C’est ce genre de personnalité qui vous motive à apprendre le code, à écrire un article Medium ou à suivre un MBA en parallèle… ou alors qui vous fait culpabiliser car vous ne faites rien de tout cela.

Son portfolio ici : https://www.sushiandrobots.com/

C’est quoi un design system ?

Un des principes fondamentaux du design d’interaction est la consistance de l’expérience utilisateur. Prenons l’exemple d’une maison : on s’attend à ce que toutes les poignées de portes se tournent de la même façon, vers le bas. Montez l’une des poignées à l’envers et votre visiteur s’y reprendra à deux fois pour ouvrir la porte, créant ainsi une mauvaise expérience (frustration, énervement, voir même abandon). Il en va de même sur un site internet, si l’un de vos boutons se comporte différemment des autres boutons, alors l’utilisateur aura une mauvaise expérience.

Il est relativement facile de créer une expérience consistante lorsque l’on travaille seul sur un site, mais cela devient bien plus complexe au fur et à mesure que votre équipe s’agrandit et que les fonctionnalités/produits annexes se multiplient. C’est là que le design system entre en jeu.

Donc un design system c’est quoi ? Ce n’est autre que le produit référent lorsque vous construisez vos produits. Il est la ligne directrice design de vos produits/fonctionnalités.

Lightning design system

Voici les exemples cités par Jina :
– Carbon design system de IBM http://carbondesignsystem.com/
– Polaris de Shopify https://polaris.shopify.com/
– Fluent design system de Microsoft http://fluent.microsoft.com/
– Harmony de Intuit http://harmony.intuit.com/

Certaines entreprises comme Mailchimp vont même encore plus loin en créant un design system pour les designers et développeurs (https://ux.mailchimp.com/patterns), et un site de guidelines sur le ton à adopter lorsque l’on s’adresse au client (http://voiceandtone.com/)

Workshop : créer le design system d’une entreprise

Ce workshop d’environ deux heures consistait à créer le design system d’une entreprise choisie par nos soins, le but étant de nous familiariser avec le concept de design system en identifiant les différents éléments d’un site.

Nous étions répartis par tables de 8 et j’ai eu l’opportunité de travailler avec un allemand, des polonais, un turc, des portugais et une anglaise sur la création du design system d’ebay. Nous étions (fictivement, le temps du workshop) des designers, des développeurs, des gens du marketing, des CEO et des chefs de produit. En créant ces rôles nous pouvions mieux comprendre quels étaient les intérêts qu’ont chaque partie prenante à la création d’un design system ; par exemple en tant que CEO, cela me coûte de l’argent d’investir dans un nouveau produit qui, lui, ne me rapporte par d’argent. Il en va donc de la responsabilité des designers et développeurs, principaux intéressés, d’expliquer la plus value de la mise en place d’un tel produit : cohérence graphique, meilleure vélocité etc…

Picking Parts, Products & People — Nathan Curtis

Le design system auquel nous sommes arrivés était plutôt spartiate mais l’idée était là : nous avions copié collé tous les différents boutons sur une page, tous les différents titres sur une autre, et ainsi de suite avec à peu près tous les éléments qui nous passaient par la tête tout en essayant d’être le plus exhaustif possible.

Après deux heures nous avions notre design system, et Jina pouvait donc maintenant nous parler du design system made in Salesforce.

V2MOM : design system 101

Ce sigle un brin barbare se décompose en réalité en cinq parties qui constituent la marche à suivre pour votre design system : (en anglais) Vision — Values — Methods — Obstacles — Measures

Si l’on en croit Jina, en suivant ces cinq étapes vous arriverez à un résultat qui reflète parfaitement la philosophie de votre entreprise.

Vision

La vision représente ce que vous souhaitez accomplir en créant votre design system. Votre vision doit pouvoir tenir en une phrase. Elle doit coller au plus près à la philosophie de votre entreprise, tout en montrant là où vous souhaitez aller.

La vision du Lightning System est la suivante :
Easy to do the right thing, hard to do the wrong thing (Facile de bien faire, difficile de se tromper)

On comprend instantanément que le but de Salesforce est de rendre si accessibles et clairs les éléments de leur design system que même un néophyte pourrait réussir à s’y retrouver.

Values (Valeurs)

Les valeurs ne sont ni plus ni moins que les principes que vous avez en tant que designer, développeur, chef de produit etc.. lorsque vous créez/faites évoluer votre design system. Ces principes doivent être dans la lignée de votre vision et permettre, au quotidien, à prendre des décisions lorsque vous avez un doute sur la décision que vous devez prendre.

Les valeurs du Lightning system :
Clarity, Efficiency, Consistency and Beauty (Clarté, efficacité, consistance et beauté)

L’ordre détermine les priorités, chez Salesforce il est plus important d’être clair que d’être beau.

Methods (Méthodes)

La méthode correspond au backlog de la création de votre design system. Quelles sont les actions à entreprendre pour pouvoir mener à bien votre projet ?

Chez Salesforce la méthode a été d’engager une équipe à part entière et de créer une v1 le plus vite possible pour pouvoir partir de ce premier jet comme base de travail. C’est le principe du mvp qu’appliquent la plupart des startups.

Obstacles

Les obstacles portent bien leur nom, l’interêt de lister les obstacles qui vous attendent sur la route de la création de votre design system est de trouver un moyen de les franchir avant d’y être directement confronté. Une bonne façon de procéder est de créer des scénarios utilisateurs afin d’illustrer ces obstacles et ainsi faire émerger un contexte donc une potentielle solution.

Exemple de scénario utilisateur : en tant que designer, j’ai besoin de liberté/flexibilité lorsque je créé une fonctionnalité. Comment rendre ceci possible lorsque le principe du design system est de normaliser/standardiser la façon dont je travaille ?

Les obstacles ne sont ni plus ni moins que des problématiques.

Measures (mesures)

Les mesures sont des objectifs tangibles, quantifiables, mesurables. Ils permettent de définir de façon très binaire si oui ou non vous avez rempli vos objectifs. Il existe une méthodologie made in Salesforce pour créer des objectifs de façon SMART : Specific — Measurable — Achievable — Relevant — Timely

Un exemple d’objectif pour un design system : Augmenter la vélocité de l’équipe de développement de 30% d’ici la fin de l’année.
Un adage à garder en tête lorsque vous écrivez vos mesures : si vous n’êtes pas capable de le quantifier, c’est que vous ne comprenez probablement pas ce que vous essayez d’accomplir.

Une fois que votre V2MOM est prêt(e?), vous pouvez attaquer le travail de construction de votre design system !

Structure d’un design system

Un design system peut se découper de plusieurs façon selon les besoins ; tous partagent cependant les mêmes grandes lignes : boutons, paragraphes, grilles, espacements et couleurs.

Si vous souhaitez approfondir cette partie, voici un bon article qui vous aidera à comprendre les différents degrés de complexité que peut comporter un design system :

  • Picking parts, products and people de Nathan Curtis https://medium.com/eightshapes-llc/picking-parts-products-people-a06721e81742

    Quelque soit la complexité et le degré de granularité que vous souhaitez pour votre design system, Jina conseille d’adopter la structure suivante lorsque vous créez votre bibliothèque de composants :

  • Nom
  • Représentation graphique
  • Description
  • Exemple
  • Contexte
  • Usage
  • Code
  • Ressources
  • Personnes concernées
  • Meta données

    Le plus important est de documenter en abondance, il vaut mieux avoir trop d’information quitte à scroller pour trouver ce que l’on cherche que de manquer d’indications sur le bon usage de l’élément. Il est impossible d’être TROP précis.« Toute information non écrite est une information perdue »

Convention de nommage des éléments
Parfois les éléments peuvent être difficile à nommer, prenez l’exemple du bloc central d’une page produit sur ebay :

Comment l’appelleriez-vous ? Il existe un moyen simple d’arriver à un consensus : Chaque personne écrit sur un post-it le nom qu’il donnerait à l’élément, la mise en commun fera émerger une appellation qui convient à tout le monde.

Intégrer l’animation et le javascript dans votre code
Ce pour la simple et bonne raison qu’un élément est la plupart du temps dynamique, il contient donc a priori du javascript et il serait trop bête de faire la moitié du travail sans incorporer la dimension d’interaction, donc d’animation, à vos éléments.

Les token : la valeur universelle
L’intérêt des tokens est de ne parler qu’un seul langage, qui s’adaptera et s’appliquera automatiquement sur toutes les plateformes (iOs, Android et web). Les valeurs HEX ou bien RGB pour les couleurs, les dp ou bien les px pour les espacements… Avec ces tokens, il suffit de déterminer une fois la valeur du dit token sur toutes les plateformes, ce après quoi il ne vous reste plus qu’à parler en Token et tout le monde s’y retrouve, sans avoir à faire la gymnastique des neurones à chaque valeur.

L’avertissement de Jina : La convention de nommage est encore plus importante pour les Tokens que pour les composants car bien souvent les tokens se multiplient, se dupliquent et se répètent, les rendants plus fastidieux à utiliser qu’autre chose.

Tout savoir sur les design tokens : https://www.lightningdesignsystem.com/design-tokens/

Le mot de la fin

Dès lors que vous vous retrouvez à travailler en feature team, le design system devient la seule façon de satisfaire les besoins des designers/dev de vos équipes tout en gardant une cohérence à travers l’ensemble de vos produits/fonctionnalités.

Does your company need a design system? — Josh Christopher

Le design system permet de stocker, compiler et restituer toutes les décisions design, permettant ainsi une communication asynchrone et enrichie à toutes les parties prenantes d’un projet, designers et développeurs en tête.

De notre côté au sein de l’équipe BtoE nous avons mis en place un design system basé sur l’atomic design de Brad Frost (http://bradfrost.com/blog/post/atomic-web-design/) qui montre pour l’instant ces preuves et dont j’aurai l’occasion de parler dans un second article.

Citations

« It used to be that designers made an object and walked away. Today the emphasis must shift to designing the entire life cycle »
Nathan Curtis Founder of eightshapes

« A design system is a living, funded product with a roadmap & backlog, serving an ecosystem »
Paul Saffo Technology forecaster

« Just because something is hard doesn’t mean it’s not worth pursuing… It’s our job to solve those problems. After all, we’re in the interface business. »
Brad Frost Author of atomic design

« …styleguides. Now it’s design systems. Is this just a change in the marketing? Or are these things actually different from one another? »
Jared Spool Founder of user interface engineering

« True collaboration isn’t throwing designs over the wall, it’s designers, engineers & the rest of the team sharing the responsibility to build a quality product »
Diana Mounter Design System Lead at Github

Ressources

Quelques design systems, pêle mêle :

https://www.nasa.gov/sites/default/files/atoms/files/nasa_graphics_manual_nhb_1430-2_jan_1976.pdf
http://carbondesignsystem.com/
https://polaris.shopify.com/
http://fluent.microsoft.com/
http://harmony.intuit.com/
http://primercss.io/
https://cssguidelin.es/
https://brand.ai/
http://bits.24ways.org/
https://material.io/components/
http://styleguides.io/
https://trailhead.salesforce.com/en/modules/manage_the_sfdc_organizational_alignment_v2mom/units/msfw_oav2m_writing_a_v2mom