1) Introduction

Chez KNP Labs, nous avons débuté le mois d’Avril 2023 avec la présentation du “Design system implementation” par Chloé (designer UX/UI) 👩‍💻 et Grégoire (développeur) 🧑‍💻. Le sujet porte sur deux documents qui lient fortement les équipes design et dev lors du processus de production d’un projet :

• l’UI kit
• le Storybook

Ces documents ont pour but de faciliter l’implémentation des composants dans un environnement de test isolé afin de réduire les écarts entre les maquettes hi-fi et l’intégration finale.

Tant en design qu’en développement, nous suivons le très répandu principe de l’atomic design qui permet à tous les domaines d’intervention de garder une cohérence dans les processus de réflexion et de production.

2) Côté design — Production des composants ‘atomic’ dans l’UI kit

Pour les KNPeers designers, les tâches peuvent être abordées de deux manières différentes en fonction du contexte de travail dans lequel nous nous trouvons au moment du démarrage du sprint.

Dans certains cas, les périodes de rush couplées aux multiples projets de refonte à long terme que nous suivons, peuvent nous contraindre à travailler les fonctionnalités dans un environnement plus global afin de proposer une vision d’ensemble au client, ce qui permet de capter le principe de l’iteration proposée de manière plus efficace tout en ouvrant la discussion. C’est dans ce type de configuration que les composants ‘atomic’ sont produits au coeur de la maquette haute fidélité, en direct du template ou de la page ciblée puis centralisés dans l’UI kit du projet.

Dans d’autres cas, nous préférerons des phases de recherche et de production des composants de manière isolée, depuis le document design system ou UI kit dans Figma, ce qui permet de prévoir instantanément tout·es les states, types, sizes etc. et d’éviter une éventuelle étape supplémentaire de centralisation des composants depuis les maquettes hi-fi vers l’UI kit. Ce contexte de travail permet également au designer d’avoir une vision 360 de toutes les variations des composants édités et d’en faciliter l’harmonisation et la cohérence des propositions.

Ainsi, les deux cas sus-cités facilitent la préparation de l’environnement storybook par les développeurs. Puisque le document design system ou UI kit est organisé suivant l’approche ‘atomic’, l’inspection des specs et la classification des composants restera la même d’un document (l’UI kit des designers) à l’autre (le storybook des développeurs).

3) Côté dev — Mise en place d’un environnement de test isolé (le storybook)

Lors de l’implémentation d’une application, il est souvent difficile d’isoler les composants (atoms) du contexte de l’application.

Des outils pilotés par composant tels que React, Vue ou Angular, aident à décomposer les interfaces utilisateur complexes en composants simple. Cependant à mesure que les interfaces se développent, le nombre de composants augmente, les projets matures peuvent contenir des centaines de composants gui génèrent des milliers de variations.

De plus, ces interfaces utilisateur sont compliquées à débuguer du fait qu’elles sont directement liées à la logique métier, les états interactifs et le contexte de l'application.

Le service storybook est présenté sous la forme d'un petit atelier de développement qui cohabite avec l’application. Il permet d’avoir un iframe isolé pour restituer les composants sans interférence de la logique métier et du contexte de l'application.

Cela aide les développeurs à concentrer le développement sur chaque variante d'un composant en synchronisation avec le design (figma).

4) Conclusion

Vous avez bien aimé notre recherche d'amélioration en continue ? Contactez nous https://knplabs.com/fr/contact