Les dessous du Kit UI de KissKissBankBank
Kit UI, design systems, styleguide : malgré toutes les ressources disponibles sur ce sujet, il n’est pas si simple de franchir le pas et de savoir comment s’y prendre en tant que product manager, designer ou développeur. Chez KissKissBankBank, nous avons décidé en juin 2016 de construire “Kitten”, notre propre Kit UI. La récente mise en ligne de notre Styleguide à découvrir ici nous invite à partager l’histoire de sa construction.
Pourquoi on l’a fait ?
Nous opérons trois services de financement participatif (KissKissBankBank, LENDOPOLIS, hellomerci) avec une seule équipe technique et produit. Chaque solution web a été lancée pour tester rapidement le marché, sans penser une solution globale dès le début.
Aujourd’hui, notre volonté d’unifier les expériences sur les trois services et de construire plus efficacement des interfaces web et mobiles nous a naturellement poussés vers la démarche d’une bibliothèque de composants réutilisables.
Nous nous sommes alors fixés 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.
Feuille blanche, juin 2016, c’est parti !
Comment on l’a fait ?
Étape 1 : inscrire le Kit UI dans notre roadmap
Je savais que le développement du Kit UI allait prendre du temps sur notre roadmap, la première étape fut donc de vulgariser le principe au sein de toutes les équipes, et de convaincre en interne de la nécessité de passer par cette étape pour orchestrer la vision business et produit de KissKissBankBank.
Leçon : La communication interne est clé pour faire comprendre la démarche et la vision long terme.
Étape 2 : constituer l’équipe initiale
Nous avons réuni Camille, Sunny, Fanny, Bastien - développeurs et experts des technologies front, Kévin designer UI, Mathieu product designer, et moi-même CPO.
Nous avons commencé par un atelier qui a permis d’échanger sur des exemples inspirants (Gov UK, Mailchimp, Material Designs, Salesforce) et de fixer le premier milestone : mettre en place le kit UI pour construire un header commun aux trois plateformes qui permettra à l’utilisateur de naviguer entre ces trois plateformes.
Nous avons également défini ce que l’on entendait par “Kit UI” : un set de composants mis à la disposition des interfaces utilisateurs (“Components” ), auxquels on peut appliquer une identité visuelle (“Branding”).
Leçon : Se fixer un premier objectif de production nous a permis d’éviter l’écueil : construire le Kit de A à Z sans application directe.
Étape 3 : mettre en place un processus de discussion et de production
Décider d’une grille, d’un système de mesure, de la gestion de la typographie, décortiquer chaque composant pour en comprendre sa fonction et sa structure, nommer les composants et les classer dans une catégorie, définir les règles (interactions, états en responsive, accessibilité, animations, contrastes) sont des sujets que nous avons abordés ensemble grâce à des échanges réguliers et une compréhension mutuelle des exigences fonctionnelles et techniques.
Nous avons mis en place un channel Slack et une réunion hebdomadaire. Petit à petit, les terrains entre les sensibilités tech et produit se sont alignés : les designers testant les composants en récupérant le dépôt git sur leur machine et les développeurs mettant à l’épreuve chaque composant sur Zeplin.
Leçon : La construction d’un Kit UI se fait par la communication, la discussion pour aligner les ambitions visuelles, fonctionnelles et techniques, et en dernier, la production.
Étape 4 : s’accorder le temps de R&D Tech et Produit nécessaire
Côté tech : comment développer des composants qui peuvent être installés sur trois plateformes vivant sur des stacks différentes ?
Côté produit : comment construire un Kit qui marche visuellement sur trois produits aux identités visuelles historiquement différentes et qui n’oblige pas à un redesign complet ?
Une étape de recherche de quelques semaines nous a permis de répondre sereinement à ces interrogations. Côté produit, nous avons itéré sur une page d’application : la page projet, car le header seul ne nous permettait pas de valider l’identité visuelle du Kit UI. Commune aux 3 plateformes, et constituée d’un nombre suffisant de composants pour nous permettre de tester différents styles, le redesign de cette page projet nous a permis de constituer le set identitaire de base (boutons, typographie, navigation, formulaires). Côté tech, un article sur La Fabrique expliquera les choix technologiques .
Leçon : La phase de R&D est une étape indispensable pour construire une solution qui prenne en compte l’existant et réponde à nos trois objectifs.
Étape 5 : passer à l’échelle
Le 17 novembre 2016, nous avons publié la version 1 de Kitten publiée en open-source, celle qui a permis de lancer le header commun. Aujourd’hui, nous en sommes à la version 11.5.
Le Styleguide nous permet de répertorier les composants et de les tester.
Chaque phase de design s’ancre dorénavant dans cette logique :
- Si un composant existant répond au besoin de l’interface conçue, alors nous l’utilisons.
- Sinon, nous définissons le rôle du composant, nous le designons, le cartographions, le développons dans Kitten, le testons, et le publions sur le Styleguide.
Leçon : L’évolution du Kit UI demande rigueur et méthode pour continuer à dire “non” aux exceptions et automatiser les process sans sacrifier la créativité.
Et ensuite ?
Les trois objectifs fixés initialement sont remplis. Chaque nouveau pixel installé sur nos trois solutions web passe par Kitten et nos workflows de conception sont optimisés.
Les prochaines challenges ? Itérer sur les composants, appliquer le kit au mobile natif, automatiser les tests, mesurer leur performance, et permettre aux clients de nos APIs de l’utiliser simplement.
