Comment Razorpay a rationalisé la charge de travail des développeurs
L'équipe Design systems de Razorpay a mis au point Blade pour offrir aux utilisateurs une expérience homogène et intuitive prenant en charge différents produits sur plusieurs plateformes.
Partager Comment Razorpay a rationalisé la charge de travail des développeurs
Figurant parmi les principales sociétés de services financiers en Inde tant par sa taille que par sa croissance rapide, Razorpay sert 10 millions d'entreprises. C'est Blade, son design system, qui permet aux équipes de design et de développement de tenir la cadence à une telle échelle tout en travaillant sur le design de façon fluide et collaborative. Nous discutons ici avec l'équipe Design systems de Razorpay pour en apprendre plus sur son approche de l'adoption du design system et des indicateurs, sur la manière dont elle relève les défis posés par la collaboration et sur les plugins privés qui aident les développeurs à travailler plus efficacement.
Comment votre équipe et votre plateforme sont-elles structurées ?
Nous sommes environ 70 designers et 100 développeurs front-end. Au sein de ces équipes, trois designers et cinq ingénieurs se consacrent à notre design system.
Nos produits sont disponibles sur ordinateur, sur l'Internet mobile et sur des applications iOS et Android. Nous avons un seul design system, Blade, qui fonctionne sur ces différentes plateformes avec la même API et les mêmes propriétés. Si un développeur passe du développement web à une application mobile, il peut transférer ses connaissances en code web sur l'appli. Nous avons choisi cette approche parce que nous ne voulions pas passer du temps à concevoir séparément plusieurs plateformes.
Quels problèmes votre design system a-t-il permis de résoudre ?
Avant le déploiement de Blade, les équipes pouvaient facilement passer à côté de nuances subtiles, comme les différents états d'un bouton, ou le meilleur moyen de résoudre une erreur dans un champ de texte. Les équipes essayaient de modifier le code source et de tout créer sur mesure. En procédant ainsi, elles prenaient le risque de faire des erreurs. Il y avait énormément de tâches de développement répétitives réalisées au cas par cas, ce qui nuisait à l'expérience client. C'est un enjeu important pour un produit comme le nôtre, à qui les entreprises confient leur argent. Une expérience client de qualité aide à établir une relation de confiance.
Par ailleurs, Razorpay proposant différents produits dans différents secteurs, nous devions donc veiller à l'homogénéité de l'expérience utilisateur sur l'ensemble de ces produits et domaines. Le fait d'avoir un design system et un langage communs nous permet de nous attaquer à la racine du problème avec bien plus d'agilité. Ce système veille également à ce que tous les composants de Blade soient entièrement disponibles pour l'ensemble de nos utilisateurs.
Comme nous travaillons sur des design systems, les développeurs et les designers de Razorpay sont nos clients au même titre que les utilisateurs finaux de Razorpay. Grâce à Blade, tout le monde parle la même langue, ce qui réduit les points de friction entre les équipes et accélère la mise sur le marché. La partie design et la partie code partagent la même vision.
Quelle approche votre équipe a-t-elle privilégiée pour adopter ce design system ?
C'est la partie la plus délicate, quel que soit l'outil. Nous avons pris plusieurs mesures pour encourager son utilisation et réduire les points de friction :
- Obtenir l'adhésion de la direction : la cohésion et l'appui de la direction sont des éléments cruciaux à chaque étape, que ce soit pour accompagner les premiers pas, financer l'équipe ou encore encourager leurs propres équipes à adopter Blade.
- Identifier les indicateurs clés : nous nous servons de scripts et d'outils internes pour suivre des indicateurs qualitatifs et quantitatifs, comme le nombre de projets intégrés à Blade ou le pourcentage d'applications conçues avec des composants de design system. La direction et le groupe de travail peuvent ainsi suivre plus facilement les progrès réalisés.
- Accompagner les utilisateurs : nous sommes disponibles aux heures de bureau et nous avons un canal Slack où les clients peuvent envoyer des requêtes ou signaler des problèmes. Nous avons également formé un groupe de sensibilisation composé de designers issus d'équipes qui utilisent Blade. Ils aident à prendre des décisions au sujet des composants et à promouvoir son utilisation au sein de leur propre équipe.
- En faire la promotion dans notre organisation : quand nous annonçons de nouveaux composants, nous publions une vidéo de démonstration et nous mettons à jour la page récapitulative des composants.
Comment mesurez-vous l'influence de votre équipe ?
Notre but ultime, c'est de permettre à nos équipes de livrer des interfaces modernes et élégantes pendant que le design system s'occupe du reste. Nous souhaitons que les équipes chargées de concevoir de nouvelles fonctionnalités utilisent Blade pour 70 % de leurs tâches. Cet indicateur passe à 50 % pour les surfaces de produits existantes. Ce KPI est partagé par le design et le développement, et ces deux équipes sont motivées pour atteindre cet objectif ensemble.
Notre but ultime, c'est de permettre à nos équipes de livrer des interfaces modernes et élégantes pendant que le design system s'occupe du reste.
Nous avons cependant appris que la couverture réelle commence dès la phase de design. Si les designs ne sont pas conçus avec les composants de Blade, les développeurs ne sauront pas qu'ils sont censés les utiliser. Pour résoudre ce problème, nous avons créé un plugin Blade Coverage qui indique aux designers l'écart entre leur design et le design system. Grâce à ce plugin, les designers peuvent mieux anticiper leurs dates de lancement et réduire les points de friction lors des transferts, car ils reçoivent du feedback plus tôt sur les composants utilisés.
À eux seuls, les indicateurs quantitatifs ne peuvent pas refléter parfaitement l'adoption et l'impact d'un design system. Nous comptons donc également sur des sondages internes et des groupes de réflexion. Ces mesures plus qualitatives nous aident à évaluer l'opinion des équipes, par exemple si elles trouvent que Blade permet de livrer plus rapidement, et à écouter leurs commentaires concernant l'expérience client, la documentation, les sessions de formation et la collaboration entre designers et développeurs. Tout cela est compilé en un taux de recommandation net qui fait l'objet d'un suivi annuel.
Avant que votre équipe ne commence à utiliser Dev Mode, à quoi ressemblait votre collaboration pendant les transferts et la conception ?
Lors d'un transfert, les développeurs sont censés inspecter chaque élément et en copier les propriétés. Avant, cette expérience n'était pas idéale. Les développeurs devaient cliquer, cliquer, cliquer, jusqu'à trouver par hasard le bon composant, il leur fallait identifier les composants, voir leurs propriétés puis les intégrer au code.
Pour pallier ces lacunes de l'inspection, l'un de nos développeurs a créé un plugin privé appelé RazorSharp. Ce projet parallèle a nécessité deux à trois mois de développement. Cela nous a permis de générer automatiquement le code équivalent aux designs. Les développeurs n'avaient plus qu'à faire un copier-coller.
Notre plugin RazorSharp a résolu certaines difficultés, mais pas toutes. Avant Dev Mode, il fallait impérativement disposer d'un accès éditeur à un fichier pour exécuter les plugins dans Figma, ce qui n'était pas le cas de la plupart de nos développeurs. Quand un designer remettait un fichier Figma à un développeur, celui-ci devait prendre le temps de le cloner dans un nouveau fichier pour pouvoir exécuter le plugin RazorSharp.
Comment avez-vous surmonté ces obstacles ?
À présent, la majorité de nos problèmes d'inspection sont résolus. Quand Figma a lancé Dev Mode, nous avons mis à jour RazorSharp pour l'exécuter comme un plugin de Dev Mode, de sorte que nos développeurs puissent utiliser le plugin RazorSharp sans avoir à s'inquiéter de modifier les fichiers pour voir l'implémentation du code. Comme cette fonctionnalité existait déjà, deux jours ont suffi 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.
La transition de nos jetons vers les variables est en cours. Ce n'est que le début, mais nous voyons déjà des avantages aux méthodes de travail de nos développeurs.
Copier des jetons depuis le design vers le code est désormais simplissime. Au lieu de supprimer les barres obliques des noms des jetons (surface/text/subtle), nous pouvons à présent assigner une structure adaptée au travail du développeur (surface.text.subtle) en fonction. De plus, nous avons maintenant des jetons d'espacement reliés aux variables, ce qui répond à une demande de longue date des équipes d'utilisateurs.
Il est possible de mettre en place aisément un mode clair et un mode sombre sans avoir à recréer de zéro les designs de chacun des modes. Un autre problème auquel nous étions confrontés avec Blade sur Figma concernait la consommation massive de mémoire requise pour les modes multiples (clair/sombre) sur différents thèmes (paiement/banque) pour chacun de nos composants. Cela freinait considérablement la productivité de nos designers, du simple fait de la lenteur des systèmes pendant le design. Toutefois, avec l'introduction de variables, nous avons pu simplifier Blade en un seul thème, ce qui a grandement augmenté la productivité des designers.
Quelques autres fonctionnalités ont amélioré notre charge de travail. Grâce au plugin VS Code, nos développeurs peuvent écrire du code sans perdre le contexte en basculant entre Figma et le code. Le modèle de zone aide les développeurs à visualiser les designs plus près du code à l'intérieur même de Figma. Grâce aux fonctionnalités de comparaison des modifications et d'historique des versions, les développeurs sont informés de façon plus transparente quand un fichier a été modifié. Cela leur permet de bloquer les fichiers et de les passer en revue pour éviter les retards dus aux changements de dernière minute.
Quels ont été les effets de ces changements en termes de productivité et d'adoption du design system ?
Nous avons interrogé nos designers et nos développeurs, et 80 % d'entre eux affirment se sentir plus productifs en utilisant notre design system Blade que sans lui. Dev Mode a joué un rôle de premier plan pour rendre notre design system plus simple à comprendre et à adopter.
Les développeurs qui ont commencé à utiliser Dev Mode ont constaté une amélioration de leur charge de travail, soit grâce à la réduction des points de friction entre le design et le développement, soit grâce à l'accroissement de la productivité globale.
Si vous souhaitez explorer notre propre plugin privé pour codegen, lisez la documentation développeur de Figma ou utilisez notre exemple de plugin codegen sur GitHub.