Razorpay : booster l'adoption des design systems et la collaboration du design au développement avec Figma

Razorpay est l'une des plus grandes entreprises de services financiers d'Inde, et l'une de celles qui connaissent la croissance la plus rapide, avec 10 millions d'entreprises clientes. Dans cette session de questions-réponses, nous échangeons avec son équipe de design system pour en savoir plus sur les sujets suivants :

• Son approche de l'adoption et des mesures du design system
• Les défis rencontrés dans la collaboration en matière de design et de développement
• Comment elle a utilisé le Dev Mode et des plug-ins privés pour améliorer les workflows d'équipe
• L'impact de Figma sur la productivité et l'adoption du design system

Comment votre équipe et votre plateforme sont-elles structurées ?

Soni : Nous comptons environ 70 designers et 100 développeurs front-end. Dans ces équipes, 3 designers et 5 ingénieurs travaillent sur notre design system.

Kamlesh : Nos surfaces de produits incluent des applications web (bureau et mobile), iOS et Android. Nous disposons d'un seul design system pour toutes les plateformes, avec les mêmes API et les mêmes propriétés. Si un développeur passe d'une appli web à une appli web mobile, il peut utiliser sa connaissance du code web dans l'application mobile. Nous avons adopté cette approche pour ne pas avoir à investir du temps dans un redéveloppement sur plusieurs plateformes.

Parlez-nous de votre design system et de son importance

Soni : Blade est le design system de Razorpay. Avant son déploiement, les équipes pouvaient facilement manquer des nuances fines, telles que les différents états de boutons ou la façon dont doit être traitée une erreur dans un champ de texte. Les équipes essayaient de coder en dur et de développer des solutions personnalisées, et en le faisant, risquaient d'oublier quelque chose.

Cela entraînait une charge importante de travail imprévu et répétitif, au détriment de l'expérience client, qui est importante pour un produit comme le nôtre via lequel les entreprises nous confient leurs fonds. Une expérience produit fluide facilite l'établissement de cette confiance.

En tant que marque, Razorpay regroupe plusieurs produits dans différents domaines. Nous devons assurer la cohérence des interfaces utilisateur de nos produits. Un design system et un langage partagé nous permettent de le faire de bout en bout avec beaucoup plus d'agilité. Cela garantit également l'accessibilité complète des composants de Blade pour tous nos utilisateurs.

Kamlesh : Comme nous travaillons sur des design systems, les développeurs et les designers sont également nos clients. Avec Blade, chacun parle le même langage, ce qui réduit la friction entre les équipes et accélère la mise sur le marché. Nous l'avons développé de façon à ce que le design visible corresponde au code.

Comment votre équipe a-t-elle approché l'adoption de Blade ?

Kamlesh : Il s'agit de l'aspect le plus délicat des outils de plateforme. Nous avons mis en œuvre plusieurs étapes pour encourager l'adoption et réduire les points de friction :

• Obtenir l'approbation des leaders : Répondre aux attentes des leaders et les influencer est essentiel pour l'évolution du design system, de l'avant-projet au financement de l'équipe, pour qu'ils encouragent leurs propres équipes à adopter Blade.
• Identification des indicateurs clés : À l'aide d'outils internes et de scripts, nous suivons des indicateurs quantitatifs et qualitatifs, tels que le nombre de projets intégrés à Blade ou le pourcentage d'applications développées avec notre design system. Ainsi, notre direction et nous-mêmes pouvons évaluer plus facilement les progrès.
• Assistance active des consommateurs : Pendant les heures ouvrables, un canal Slack permet aux consommateurs de faire part de leurs questions ou de leurs problèmes. S'il s'agit d'un problème valide, l'équipe consommateurs crée des tickets GH que notre équipe trie. Nous avons également créé un groupe de promotion, qui inclut des designers de nos équipes consommateurs. Il nous aide à prendre des décisions sur les composants et promeut le design system dans les différentes équipes.
• Promotion dans notre organisation : Nous annonçons les nouveaux composants avec une vidéo de démo et la mise à jour de la page d'état des composants. Ces outils permettent d'éviter que les équipes consommateurs créent des composants qui existent déjà dans le design system.

Comment mesurez-vous l'impact de votre équipe ?

Kamlesh : Notre priorité absolue est de permettre aux équipes de créer des interfaces modernes et élégantes avec un minimum de code et de travail sur Figma, et de se concentrer sur la création des fonctionnalités tandis que le design system se charge du reste. Au niveau supérieur, notre objectif est que les nouvelles fonctionnalités utilisent Blade pour 70 % de leur design, et les surfaces de produits existantes à 50 %. Ce KPI est partagé par le design et le développement, et les deux équipes sont décidées à l'atteindre ensemble.

Toutefois, nous avons compris que la véritable couverture démarre à la phase de design. Si les designs ne sont pas réalisés avec nos composants de DS, les développeurs ne sauront pas qu'ils doivent également les réaliser avec Blade. Pour résoudre ce problème, nous avons créé un plug-in Blade Coverage qui indique aux designers leur écart par rapport au design system. Ce plug-in permet aux designers de mieux prédire leurs calendriers de lancement et de réduire la friction pendant le déploiement, car ils reçoivent plus tôt des commentaires sur les composants qu'ils utilisent.

À eux seuls, les indicateurs quantitatifs ne permettent pas de mesurer l'adoption et l'impact d'un design system. Nous utilisons donc des enquêtes internes et des groupes ciblés. Ils nous aident à comprendre le ressenti des équipes : Blade a-t-il aidé une équipe à livrer plus vite ? A-t-il facilité l'expérience de l'équipe avec les outils, la documentation, les sessions de formation ? Réduisons-nous vraiment la friction entre designers et développeurs ? Tout ceci donne un taux de recommandation net que nous suivons annuellement.

Résoudre la friction entre design et développement avec des plug-ins privés dans Figma

Avant que votre équipe commence à utiliser Dev Mode, comment se passait la collaboration pendant la mise en production et le développement ?

Kamlesh : Au moment de la mise en production, les développeurs doivent inspecter chaque élément et copier ses propriétés en conséquence. Cependant, l'expérience précédente n'était pas idéale. Les développeurs multipliaient les clics jusqu'à atteindre accidentellement le bon composant, identifient les composants, consultent leurs propriétés et les implémentent dans le code.

Pour gagner en efficacité, un de nos développeurs a créé un plug-in privé appelé RazorSharp. Ce projet lui a pris 2 à 3 mois en parallèle. Il nous a permis de générer automatiquement le code équivalent aux designs. Il suffisait ensuite aux développeurs de le copier-coller.

Le plug-in RazorSharp a éliminé une partie de la friction pour les développeurs, mais une partie seulement. Avant Dev Mode, l'exécution des plug-ins dans Figma nécessitati un accès en édition au fichier, ce que la plupart de nos développeurs n'avaient pas. Si un designer envoyait un fichier Figma, le développeur devait d'abord cloner ce dernier dans un nouveau fichier pour exécuter le plug-in RazorSharp.

Accélérer l'adoption du design system avec Dev Mode

Comment Dev Mode, y compris les variables, a-t-il permis de résoudre ces problèmes ?

Kamlesh : La plupart de nos problèmes d'inspection sont résolus. Lors de la sortie de Dev Mode , nous avons mis à jour RazorSharp pour qu'il s'exécute en tant que plug-in de Dev Mode, afin que nos développeurs puissent utiliser RazorSharp sans avoir à se soucier de modifier les fichiers pour voir l'implémentation du code. Comme cette fonctionnalité existait déjà, il a suffi de 2 jours pour la rendre compatible avec Dev Mode.

Nous nous servons également de Dev Mode pour intégrer des liens Storybook pour chaque composant afin que les utilisateurs de notre design system puissent plus facilement accéder à l'initiation du code sur Storybook pour ce composant spécifique.

Nous sommes en cours de transition des jetons vers des variables. Bien que nous n'en soyons qu'au début, nous commençons à constater des avancées dans la façon de travailler de nos développeurs.

Copier des jetons du design au code se fait sans difficulté. Au lieu de supprimer des barres obliques de noms de jetons (surface/text/subtle), nous pouvons attribuer une structure adaptée au développement(surface.text.subtle). Les jetons d'espacement sont maintenant mappés aux variables, ce que nos équipes consommateurs nous demandaient depuis longtemps.

Il est possible d'implémenter immédiatement les modes clair et sombre sans avoir à recommencer les designs pour chaque mode. En outre, un ancien problème avec Blade sur Figma était la quantité de mémoire requise pour développer plusieurs modes (clair/sombre) sur plusieurs thèmes (paiement/banque) pour chacun de nos composants. C'était un vrai obstacle à la productivité des designers, en raison de la lenteur des systèmes pendant le design. L'introduction de variables nous a permis de simplifier Blade en un thème unique, ce qui dope la productivité des designers.

Saurav : D'autres fonctionnalités nous ont permis d'améliorer nos workflows. Le plug-in VS Code a permis à nos développeurs d'écrire du code sans perte de contexte en basculant entre Figma et le code. Le modèle de zone permet aux développeurs de visualiser les designs plus près du code dans Figma. La comparaison des modifications et l'historique des versions ont donné davantage de transparence aux développeurs en cas de modification d'un fichier. Ainsi, ils peuvent geler les fichiers et délimiter les éléments pour éviter tout retard dû à des changements de dernière minute.

Améliorer la productivité et l'adoption du design system

Quel impact ces changements ont-ils eu sur vos équipes ?

Saurav : 80 % de nos designers et développeurs ont déclaré se sentir plus productifs avec le design system Blade. Dev Mode a largement contribué à rendre notre design system plus facile à comprendre et à adopter.

Kamlesh : Tous nos développeurs n'ont pas encore essayé Dev Mode. Ceux qui ont commencé à l'utiliser Dev Mode ont constaté des améliorations de leur workflow, soit par la réduction de la friction entre design et développement, ou par l'augmentation de la productivité globale.

Voulez-vous savoir comment Razorpay développe et maintient ses design systems ? Découvrez le design system Blade sur GitHub, ou consultez leurs bonnes pratiques sur les blogs de Razorpay Design et Engineering. Consultez le blog de Design, ou découvrez le design system Blade sur GitHub.

Si vous voulez découvrir notre propre plug-in privé de génération de code, lisez les documents de développement de Figma ou utilisez notre échantillon de plug-in de génération de code sur GitHub.