Les pièges à éviter dans son design system quand on est seul designer

Romain Magri

27.9.24

Ou comment créer un Design System qui serve à quelque chose.

‍

Un article basé sur mon expérience personnelle qui vous donnera des bonnes pratiques pour vous éviter de faire votre design system tout·e seul·e trop vite, et d’en faire un document non scalable et rigide.

‍

La première fois que j’ai entendu parler de design systems, on était en 2015 et j’avais mon premier job. À cette époque, les cool kids postaient #avocadotoasts 🥑 sur Instagram, le logo de Google faisait sa transition du serif au sans-serif, et on voyait fleurir un nombre impressionnant d’articles définissant et redéfinissant ce que devrait être un bon design system (il y a le bon design system et le mauvais design system… 🦌).

Comme j’ai commencé seul designer dans ce premier job, je n’avais pas de référent pour me guider dans la création d’un design system. Tout ce que je pouvais faire c’était lire des articles contradictoires et m’appuyer sur ma veille confuse. Donc j’ai fait plein d’erreurs. J’ai voulu tout faire moi-même, dans un contexte où je n’avais pas le temps, et en imposant une vision que je ne maîtrisais pas. Si c’était un bingo, j’aurais déjà gagné le jambon. 🍖

‍

‍

Depuis, certaines lectures m’ont beaucoup aidé à me forger une opinion sur le sujet, et je ne recommanderais jamais assez de les lire :

📚 L’Atomic Design de Brad Frost,

📚 Design Systems d’Alla Kholmatova,

ou encore le 📚 Design System Handbook d’InVision.

‍

Au delà d’une simple corde de plus à notre arc de designer, les Design Systems nous plongent dans la pensée systémique. Envisager le monde comme un ensemble d’interactions, optimiser notre manière de designer des produits, créer un pont tangible entre designers et développeurs (et aussi entre équipes d’une même organisation), tout ça fut rendu possible grâce aux designs systems et aux personnes qui ont contribué·es à sa définition.

Comme tout nouvel outil, son implémentation comporte des risques. Sa création demande trop d’effort / trop de temps ? Il est tout beau tout neuf, mais personne ne l’utilise ? Il est perçu comme une contrainte plus qu’un guide ? Pas de problèmes, laissez-moi attraper mon marteau-piqueur et on va péter tout ça ensemble. 👷

REMARQUE : Cet article est là pour vous donner les ressources théoriques et vous orienter sur la meilleure façon de démarrer votre propre design system, du point de vue d’un designer en startup. Ce n’est pas un tutoriel pratique de A à Z.

‍

A History of Design Systems

Si vous voulez faire un peu d’archéologie sur l’histoire des design systems, c’est par ici et c’est passionnant.

Accéder à "From designing interfaces todesigningsystems"

‍

Design System — C’est quoi ? À quoi ça sert ?

‍

‍

La littérature sur le sujet est foisonnante. Il y a tellement d’articles et de ressources qu’il existe même des curateurs qui ne parlent que de ça (voir plus bas). Plus besoin de chercher très loin pour trouver une définition claire et complète :

“Un Design System est un langage visuel, organisé et évolutif régissant la composition d’un ou de plusieurs produits.” ~ signé Internet

C’est-à-dire que tout organisme possédant un ou plusieurs produits peut avoir un design system. Une startup peut en posséder un, comme une grosse entreprise, un gouvernement, ou même une communauté. Autrement dit, c’est une documentation complète, qui comprend :

Des Principes : Quels sont les grands concepts qui vont influencer les décisions de design dans le produit? Quelles valeurs le design doit-il véhiculer ?
Un Style Guide : Les couleurs, typographies, espacements, logos, icons et illustrations du produit.
Des Composants : Une liste ordonnée de composants UI (par type, par familles, en atomic design…), de leurs états (hover, error, disabled…) et de leurs usages (do & don’t).
Des bonnes pratiques : Les normes d’accessibilité et/ou d’eco-conception à respecter, la stratégie de contenu à adopter, des règles concernant le design de l’attention…

“Là où il y a des interfaces, il y a des design systems.” ~ selon un dicton populaire.

‍

‍

Le design system peut prendre une forme plus ou moins complexe en fonction des besoins de l’entreprise, de sa plus simple (UI Kit & Style Guide) à sa plus complexe. Lorsqu’il est implémenté et fonctionnel, un design system va permettre à l’entreprise de :

Réduire drastiquement l’effort et le temps de production UI et front-end,
Alléger la pression sur l’UI pour se concentrer sur des problèmes plus vastes et plus complexes,
Harmoniser le design des produits de l’entreprise à travers un langage cohérent et identifiable par les utilisateur·ices,
Aligner les équipes développement et produit autour d’une vision commune,
Aider à l’onboarding de nouveaux·elles designers dans l’équipe.

‍

Design Systems Repo

Une collection de Design Systems structurés et fréquemment mise à jour, avec des ressources, outils, articles et vidéos pour vous aider

https://designsystemsrepo.com/

‍

Piège n°1 — Tout faire soi-même

‍

‍

En 2015, lorsque j’ai voulu créer mon premier design system, l’une des premières erreurs que j’ai pu faire, ça a été de le créer seul. C’était le meilleur moyen pour que mon travail ne serve à rien. Je me suis ensuite épuisé à convaincre les développeur·euses du bien-fondé de la démarche en leur imposant malgré moi ma vision des choses.

‍

🙊 Mauvaise idée.

Un design system est un pont entre les designers et les développeur·euses. S’il est uniquement construit par les un·es ou par les autres, il perd alors son rôle de liant et devient une documentation imposée, incomprise et difficile à adopter. C’est pourquoi il est crucial de le co-construire avec les développeur·euses pour garantir son adoption.

C’est une histoire d’équilibre.

‍

‍

Imaginons qu’on soit dans une petite équipe produit classique (1 PM, 1 Designer, 3-4 Devs), il faudrait alors initier le projet et le porter en binôme avec le·la Lead Développeur·euse. Les avantages de ce binôme sont qu’on réfléchit avec l’approche technique et design dès le départ. Aussi, en incluant un lead technique, on implique par extension toute l’équipe de développement dans le processus.

En parlant de fondations, c’est maintenant que le binôme peut se mettre d’accord sur la base, c’est-à-dire :

Une architecture : en fonction de la stack technique utilisée (React, VueJS…), il faut déterminer quelle est l’architecture de composants la plus logique à utiliser. Est-ce que ce sera par famille, par usage, ou en atomic ? Il n’y a pas de solution universelle mais il n’y a qu’une bonne solution : bien comprendre comment fonctionne les technologies front-end afin d’aligner l’organisation du design system et la logique du code.
Des principes design : c’est aussi avec les devs qu’on définit quelles valeurs vont structurer tout le reste de la collaboration. En cas de conflit sur un composant, ou de différend sur la priorisation, quels principes vont arbitrer la discussion ?
Une convention de nommage : c’est capital d’aligner tout le monde sur le nommage des éléments car c’est par là que commence la création du langage design/dev. Est-ce que les composants seront nommés en camelCase, PascalCase ou kebab-case (oui c’est un vrai truc 🌯)? De quoi se compose le nom d’un composant (par exemple : famille-parent-enfant…) et d’une variable ?
Des outils : forts de tout ça, un petit benchmark de l’existant s’impose pour définir quel sera le meilleur outil pour adresser votre contexte. Par exemple, j’ai beaucoup travaillé avec des stacks ReactJS/NodeJS, donc le combo parfait pour nous a longtemps été Figma — Zeroheight — Storybook.Mais il existe bon nombre d’outils que vous retrouverez dans mes ressources.

Le principe reste le même pour les moyennes et plus grosses organisations, sauf que le binôme se serait transformé en comité incluant les leads design et dev nécessaires.

‍

Evaluer votre maturité produit

Identifier ses axes d'amélioration avec la Product Review

Un outil d'auto-évaluation à destination des Product Managers au sens large (First, Lead, Head of ...). Il permet d'identifier rapidement ses forces et ses faiblesses.

Accéder à la Product Review

‍

Piège n°2 — “On a pas le temps !”

En 2017, lorsque j’ai voulu créer mon deuxième design system, je l’ai créé avec les devs. La collaboration était géniale, mais on avait très peu de temps et de ressources pour le construire. Comme il y avait déjà un produit existant, on a voulu tout rusher d’un coup, mais ça nous a épuisés et ensuite on a eu énormément de mal à maintenir le design system à jour …

‍

🙈 Mauvaise idée.

Un design system est un produit à part entière, et comme tout produit, il a sa propre roadmap. C’est-à-dire qu’une fois le cadrage précédent fait avec l’équipe technique, il faut absolument inclure le·la product manager. Le but étant à cette étape de minimiser les risques de bottleneck (goulot d’étranglement) et de gagner du temps rapidement sur l’implémentation du design system :

En découpant le projet en itérations. Le découpage va beaucoup dépendre de votre manière de prioriser les sujets. Pour ça, chaque team produit a sa recette. Cependant il est quand même intéressant de se demander si c’est mieux pour vous de découper par composant, par page, par parcours ? Ou de faire en fonction des besoins de la roadmap produit ?
En automatisant les changements. Certains outils comme Zeroheight proposent des “design tokens”, c’est à dire des clés que les devs peuvent utiliser pour lier automatiquement la codebase et le design system. Vous pouvez également mettre en place du versionning de votre design system pour éviter les conflits de merge, surtout si vous travaillez à plusieurs designers, avec des outils comme Abstract, Kactus ou ce plugin Github.

Plus les itérations avancent, moins il y a de composants à faire.

‍

Piège n°3 — La loi, c’est la loi !

‍

‍

En 2020, lorsque j’ai voulu créer mon troisième design system, je l’ai créé avec les devs et par itération. Tout se passait très bien mais c’est rapidement devenu très compliqué pour moi de modifier/supprimer des composants, car au fur et à mesure qu’il se développait, le design system devenait tellement rigide que le moindre changement était verrouillé…

🙉 Mauvaise idée.

Un design system est un document vivant et évolutif. Le voir comme une loi inscrite dans le marbre, c’est oublier que dans le monde du travail les marques, les organisations et les contextes évoluent sans cesse. Pour s’inclure dans ce monde en mouvement, le design system doit pouvoir s’adapter :

En s’autorisant à échouer. Si un composant répond à une problématique à un instant T, ça ne veut pas dire qu’il y répondra toujours. C’est sans doute la chose la plus dure à intégrer, mais s’autoriser à échouer, c’est se permettre d’apprendre.
En créant des processus simples et flexibles. Il ne devrait y avoir que les développeurs, les designers et les product managers d’impliqués. Une idée serait de bêta-tester certains composants pendant vos user tests, une autre serait de gérer les changements de composants comme des bugfixs. C’est important d’expérimenter des méthodes avant de définir celle qui vous correspond le mieux.

‍

Pour conclure

Un Design System qui fonctionne est une documentation évolutive et flexible, co-construite de manière itérative avec l’ensemble de l’équipe produit et technique. Une fois que la machine est lancée entre les développeur·euses et les designers, c’est le bon moment pour communiquer sur les avantages de la méthode auprès des autres équipes et des décideur·euses via des KPI clairs.

Combien de temps de production avez-vous gagné ? À quoi le temps dégagé sera-t-il alloué ? Ce sont de très bons vecteurs pour commencer à s’attaquer à cette dette technique qui traîne depuis 4 ans, ou bien à ce nouveau projet qu’on souhaite mettre en place.

‍