â€č retour

đŸ± Kitten, le design system de KissKissBankBank

Article originellement publié sur Notion:Kisskiss


Petite histoire

Au mois de juin dernier, Kitten, le design system de KissKissBankBank (GitHub) a cĂ©lĂ©brĂ© ses six ans, avec une onziĂšme release majeure. Cet anniversaire est d’abord passĂ© inaperçu dans l’équipe, mais on a pu fĂȘter ça avec un verre de champagne đŸ„‚.

Étant donnĂ©s les changements prochains dans les Ă©quipes de KissKissBankBank & Co., l’équipe derriĂšre Kitten a voulu prĂ©senter le projet aux autres Ă©quipes du groupe, pour les inviter Ă  l’adopter. Cet article rĂ©capitule l’histoire et la philosophie du Design System, et divers choix techniques d’intĂ©gration.

Les racines du projet

Kitten, en tant que design system, a été conçu pour résoudre le problÚme de la dette de design présente sur les plate-formes KissKissBankBank, Lendopolis et HelloMerci.

L’acte de fondation de Kitten avait ces trois objectifs :

  1. Unifier le langage d’interface entre les trois services.
  2. Optimiser nos méthodes de travail en product design afin de consacrer
    plus de temps à l’UX qu’à l’UI et afin de diminuer la maintenance.
  3. Faire du Kit UI de KissKissBankBank le premier Kit UI du crowdfunding,
    ie. celui qui sera utilisé par nos partenaires et par les clients de nos
    APIs.

Vous pouvez découvrir ces objectifs et le tout début du projet dans Les dessous du Kit UI de KissKissBankBank, par SolÚne Maßtre, responsable Produit à cette époque.

Les processus mis en place partent de maquettes de pages complĂštes, Ă  partir desquelles l’équipe de dĂ©veloppement dĂ©cortique et isole chaque composant. Il n’y a donc pas le mĂȘme systĂ©matisme entre le design, qui travaille en pages complĂštes, et le code, qui travaille en composants isolĂ©s. Ces choix sont faits Ă  cause du manque de maturitĂ© des design systems en 2016-2017, de la faible expĂ©rience de l’équipe sur le sujet et surtout du besoin d’avancer et d’itĂ©rer rapidement pour rĂ©sorber la dette design.

L’équipe

Kitten a Ă©mergĂ© sous la houlette de Fanny Cheung, Bastien Maillard et Sunny Ripert en 2016. Le projet a Ă©tĂ© trĂšs vite rejoint par Camille Delbove qui a pu suivre l’intĂ©gralitĂ© de sa conception, et coordonne maintenant l’intersection du design et du code. En 2019, Joachim Robert est arrivĂ© dans l’Ă©quipe tandis que Fanny et Sunny s’en retiraient. Bastien l’a quittĂ©e plus tard, en 2021.

CĂŽtĂ© design, KĂ©vin Lagier a conçu et fait progresser l’identitĂ© du site jusqu’en 2020, puis Marie Boegly a pris le relais pour faire Ă©voluer le design et dĂ©composer les maquettes vers des composants et leurs variantes, sur l’outil de conception graphique Figma : Design System Kitten.

Une Ă©volution de choix technologiques

Au dĂ©but, Kitten a Ă©tĂ© conçu autour de composants HTML / SCSS. Le premier composant Ă©tait le simple Button. TrĂšs vite, les composants demandent de l’interactivitĂ©, comme le nouveau Header commun aux trois plate-formes. Pour ça, le choix est fait d’utiliser React ponctuellement. Pour prĂ©senter le design system, une app Rails est accrochĂ©e, elle s’appelle Karl (on peut encore la voir sur styleguide.kisskissbankbank.com, figĂ©e dans le temps), elle sera remplacĂ©e en 2019 par Storybook hĂ©bergĂ© sur Vercel : kitten.vercel.app.

En 2018, le choix est fait de ne dĂ©velopper qu’en React, et de ne plus avoir de composants basĂ©s sur du HTML / SCSS. Le choix du moteur CSS-in-JS se porte d’abord sur Radium, puis en 2019 la migration se fait vers Styled Components, qui permet d’écrire les styles comme du CSS, et non comme des objets JS inadaptĂ©s. La transition de Radium vers Styled Components se termine en 2020 avec la migration des plus vieux composants de Kitten.

Les derniers composants HTML / SCSS sont migrĂ©s en 2021, pour Kitten v3. La v2 avait Ă©tĂ© publiĂ©e deux ans auparavant, cette version majeure a permis de se dĂ©barrasser d’une grande partie du code legacy et de la dette technique, et de profiter pleinement de React pour nos composants.

Les versions majeures se suivent beaucoup plus rapidement, ce qui permet de faire passer des Breaking Changes conséquents, comme le nouveau design, introduit fin 2020.

À partir de 2021, les maquettes sont Ă©laborĂ©es avec l’outil Figma, Kitten devient un design system complet. Il faut trouver un langage commun entre le design et le code, c’est pourquoi en 2022 on fait Ă©voluer l’arborescence pour avoir la mĂȘme architecture des deux cĂŽtĂ©s. Le dĂ©ploiement des design tokens permet en outre de faciliter la transmission de donnĂ©es de style du design system entre les maquettes et le code.

Détail des déclinaisons du composant Button, dans les maquettes Figma

Détail des déclinaisons du composant Button, dans les maquettes Figma

Philosophie

Kitten est tournĂ© vers l’humain

L’objectif premier de notre design system, est de permettre la crĂ©ation d’interfaces centrĂ©es sur la personne qui les utilise. Cette personne mĂ©rite avant tout le respect, la clartĂ©, la facilitĂ©.

Qualité & Accessibilité

Rendre un site accessible, c’est donner la possibilitĂ© Ă  toutes et tous d’utiliser les outils informatiques, quelle que soit la maniĂšre d’y accĂ©der. C’est pourquoi il est indispensable de rendre nos applications web accessible Ă  toutes et tous en respectant les principes d’accessibilitĂ© numĂ©rique.

De la mĂȘme maniĂšre, la qualitĂ© est primordiale dans le respect dĂ» aux utilisatrices et utilisateurs. Kitten est conçu dans l’esprit du rĂ©fĂ©rentiel Opquast, qui apporte des opinions strictes et une maniĂšre rigoureuse de concevoir des sites et services internet.

Documentation par le code

Pour faciliter le travail en équipe, Kitten a intégré dÚs le début des principes de documentation par le code. Les conventions de nommage ou de structuration de composants ont été mises en place dÚs le début, celles-ci rendent la source plus facile à lire et comprendre et minimisent la dette technique. Au fil des années, les changements de paradigme ou de technologie ont toujours appliqué ce principe de compréhension du code par la lecture.

Interface du Storybook montrant les différentes variations du composant Button.

Interface du Storybook montrant les différentes variations du composant Button.

Des principes techniques et des bonnes pratiques

Des tokens en commun avec les maquettes

L’utilisation de Figma nous permet, via le plugin Figma Design Tokens, d’importer et exporter les donnĂ©es basiques de style (ou tokens) dans plusieurs dimensions : typographie, arrondis de blocs, espacement, etc


Dans la partie code, ces tokens sont transformés en CSS Custom Properties, qui sont ensuite consommées par les composants et les utilitaires.

Cette approche nous permet de maintenir une cohérence entre les maquettes et le code, et limite les aller-retours inutiles entre les designers et les devs.

Un Styled Component pour les gouverner tous

Styled Components nous permet de lier le style au composant, et de s’assurer que le style ne s’appliquera qu’au composant (et parfois à ses descendants), et donc de limiter les conflits avec des styles globaux.

NĂ©anmoins, notre usage est limitĂ© : au lieu d’habiller chaque Ă©lĂ©ment d’un composant dans un Styled Component sĂ©parĂ©, le style est appliquĂ© Ă  l’élĂ©ment le plus haut, et utilise la cascade pour transmettre leurs styles aux Ă©lĂ©ments enfants. Ça nous permet de limiter la taille de l’arborescence React : lors du rendu, un composant habillĂ© d’un Styled Component augmente d’autant le nombre d’élĂ©ments de l’arbre, avec un effet nĂ©faste sur la performance.

De plus, on limite trĂšs fortement l’inclusion de JS dans les Styled Components : au lieu de transmettre des propriĂ©tĂ©s par des props, on utilise des Custom Properties CSS transmises par l’attribut style. Plus on utilise l’API native HTML / CSS, plus on Ă©vite des calculs JS potentiellement moins performants.

De mĂȘme, pour gĂ©rer le style des diffĂ©rents Ă©tats du composants, on utilise des classes spĂ©cifiques, gĂ©rĂ©es par l’utilitaire classNames() dans les classes des Ă©lĂ©ments du markup. Ça nous permet par la mĂȘme occasion de transmettre les classes passĂ©es au composant lors de son utilisation, ce qui est souhaitable lorsqu’on veut surcharger un style (via une classe utilitaire par exemple, voir point suivant).

Composants + Classes Utilitaires

Lors de l’utilisation de Kitten dans une app web, on peut souhaiter surcharger le style d’un composant, par exemple pour gĂ©rer son positionnement, sa visibilitĂ©, etc.

La surcharge peut se faire via Styled Components comme vu plus haut, mais aussi via les classes utilitaires. Comment choisir l’un ou l’autre ?

Si le nombre de classes utilitaires dépasse 3, ou si la compréhension du code est mise en jeu, il faut préférer habiller le composant avec un Styled Component.

En mĂȘme temps, pour des raisons de performance il faut limiter l’usage des Styled Components, les classes utilitaires sont fournies pour ça.

Des principes CSS solides

Pour une meilleure comprĂ©hension des styles CSS, Kitten utilise la mĂ©thodologie BEM au sein des composants. Ça permet aussi de limiter les problĂšmes de scope et de pollinisation croisĂ©e par des styles globaux.

En 6 ans, le support du CSS moderne s’est bien amĂ©liorĂ©. Kitten a fait le choix d’utiliser toutes les fonctionnalitĂ©s modernes : Grid, Custom Properties, etc
 avec parfois un fallback pour Safari maintenant que IE est Ă©liminĂ© de la course.

On n’hĂ©site plus Ă  utiliser Flex ou Grid pour le layout des composants, mais aussi pour le layout des pages ou des conteneurs. Une des rĂšgles qu’on met en place, c’est que les composants eux-mĂȘmes ne gĂšrent pas leur propre marge, Ă©tant donnĂ© que la marge dĂ©pend du contexte ; les parents doivent gĂ©rer les marges des enfants. C’est maintenant trĂšs facile avec des conteneurs Flex (1 dimension) ou Grid (2 dimensions ou cas spĂ©ciaux de gestion de largeurs).

Les hacks sont Ă  Ă©viter, mĂȘme s’ils sont parfois utiles. Heureusement il n’y a (quasiment) plus besoin de polyfills.

Un turnaround rapide

Étant donnĂ© qu’on travaille sur les plate-formes en mĂȘme temps que sur le design system, il faut que le code soit disponible trĂšs rapidement pour qu’il puisse ĂȘtre utilisĂ© le plus vite possible.

Le cycle de releases est flexible et permet une grande rapidité.

Entre 2019 et 2021 il n’y a pas eu de release majeure, pour Ă©viter les breaking changes—il nous a fallu un mois (et 25 versions beta) pour sortir la version 3 et rĂ©soudre tous les breaking changes qui s’étaient accumulĂ©s en 23 mois. Pour Ă©viter ce problĂšme, nous avançons de maniĂšre cyclique, et essayons de faire une release majeure dĂšs qu’on a deux ou trois breaking changes en attente. En 2022 nous avons eu presque une release majeure par mois.

Les principaux breaking changes rĂ©cents ont eu trait Ă  des suppressions d’anciens composants.

Compatible avec le futur

Un des fils rouges concernant les choix technologiques ou architecturaux de Kitten, c’est la pĂ©rennitĂ© du code, et la facilitĂ© d’adaptation Ă  un nouveau contexte, un nouveau framework, etc.

C’est aussi la raison pour laquelle Styled Components est utilisĂ© comme nous le faisons : on reste le plus proche possible des standards HTML / CSS pour permettre une migration plus aisĂ©e vers une autre technologie.

De mĂȘme, les design tokens pourront eux aussi ĂȘtre facilement traitĂ©s et exportĂ©s vers une nouvelle plateforme technique.


Feedback (en travaux)

RĂ©pondez sur votre propre site, envoyez une Webmention!

🌿 🌿 đŸŒ± đŸŒ± đŸŒ± đŸŒ± 🌿 🌿 đŸŒ± 🌿 🌿 🍂 🌿 🌿 đŸŒ± 🍁 đŸŒ± đŸŒ± 🌿 🍂 🍂 🍁 🍁 🌿 🍂 đŸŒ± 🌿 🍁 đŸŒ± đŸŒ± đŸŒ± 🍂 đŸŒ± đŸŒ± đŸŒ± 🍂 đŸŒ± 🌿 🍁 🌿 🍁 đŸŒ± 🌿 đŸŒ± 🍂 🍁 🌿 đŸŒ± đŸŒ± 🌿 đŸŒ± 🌿 đŸŒ± đŸŒ± 🌿 đŸŒ± 🌿 🌿 🍂