Razorpay: Boosting design system adoption, and design-to-dev collaboration with Figma

Razorpay is one of India's largest and fastest-growing financial services companies serving 10 million businesses. In this Q&A, we spoke with their design systems team to learn about:

• Their approach to design system adoption and measurement
• Challenges they faced in design and dev collaboration
• How they used Dev Mode and private plugins to improve team workflows
• Impact of Figma on productivity and design system adoption

How is your team and platform structured?

Soni: We have around 70 designers and 100 front-end developers. Within those teams, we have 3 designers and 5 engineers working on our design system.

Kamlesh: Our product surfaces include web (desktop and mobile web), iOS and Android apps. We have one single design system that works cross-platform with the same API and same set of properties. If a developer switches from web to mobile app development, they can bring their knowledge of web code to the mobile app. We took this approach because we don't want to invest time in rebuilding for different platforms.

Tell us about your design system and why it’s important?

Soni: Blade is Razorpay’s design system. Before we rolled it out, it was easy for teams to miss a lot of small nuances like different button states, or how an error within a text field should be handled. Teams would be trying to hard-code and build everything custom, and in doing so, they might leave something out by mistake.

As a result, there was a lot of ad-hoc, repetitive development work and the customer experience suffered. This is important for a product like ours, where businesses trust you with their money. A smooth product experience helps establish that trust.

Also Razorpay, as a brand, is built of multiple products in different domains, we need coherence between different user interfaces across our products. Having a design system and shared language lets us do it from the ground up with a lot more agility. It also ensures that all Blade's components are fully accessible for all our users.

Kamlesh: Because we work on design systems, both developers and designers are our customers in addition to the end users. With Blade, everyone speaks the same language, which reduces friction between teams and speeds up time to market. We’ve built it in a way that what you see in design is what you get in code.

How has your team approached adoption for Blade?

Kamlesh: This is the trickiest part of any platform tool–we have taken multiple steps to encourage and reduce points of friction:

• Getting leadership buy-in: Aligning and influencing leadership is crucial to our design system evolution, from inception to funding the team to encouraging their own teams to adopt Blade.
• Identifying key metrics: Using internal tools and scripts, we track qualitative and quantitative metrics, like the number of projects onboarded to Blade or % of apps built with our DS. This makes it easier for leadership and us to understand progress.
• Active supporting consumers: There’s office hours and a Slack channel where consumers can post queries or issues. If it’s a valid problem, the consumer team will raise GH issues that our team triages. We also formed an advocate group, which includes designers from our consumer teams. They help make decisions about components and champion it within their own teams.
• Evangelizing within our org: For new components, we announce with a demo video and update a component status page. Both of these things help us to prevent consumer teams from creating components that already exist in the design system.

How do you measure your team’s impact?

Kamlesh: Our north star is to enable teams to ship modern, elegant UI with minimal efforts on Figma and code where they can focus on shipping product features while the design system takes care of the rest. At a high level, we set a target that new features must use Blade for 70% of their design, and 50% for existing product surfaces. This KPI is shared by design and development, and both teams are motivated to chase it together.

However, what we learned is that real coverage starts at the design phase. If the designs aren’t built with our DS components, developers won’t know that they have to build it with Blade too. To tackle this, we created a Blade Coverage plugin that shows designers how much they’re deviating from our design system. Using the plugin, designers can better predict their launch timelines, and reduce friction during hand-off as they get feedback earlier on the components they're using.

Quantitative metrics alone cannot measure a design system’s adoption and impact, so we also use internal surveys and focus groups. It helps us understand sentiment, like whether Blade has helped a team ship faster, team experience with tooling, documentation, training sessions, and whether we are truly reducing friction between designers and devs. All of this ladders up to a Net Promoter Score that we track annually.

Solving design to dev friction with private plugins in Figma

Before your team started using Dev Mode, what was collaboration like during handoff and build?

Kamlesh: When hand-off happens, developers are expected to inspect each element and copy the properties accordingly. But the previous experience was not ideal and annoying. Devs would click, click, click, until they accidentally landed on the right component, identify the components, see their props, and then implement the same in code.

To address these inspection inefficiencies, one of our developers built a private plugin called RazorSharp. It took 2-3 months as a side project. This allowed us to auto generate the equivalent code for the designs. From there, the devs could simply copy-paste it.

Our RazorSharp plugin solved some of the friction for devs, but not all. Before Dev Mode, plugins in Figma could only be run if you had edit access to the file, but most of our developers didn’t have this. So that meant if a designer handed them a Figma file, a developer would need to take the extra step of cloning it in a new file so they could run the RazorSharp plugin.

Accelerating design system adoption with Dev Mode

How has Dev Mode–including variables–helped address these pain points?

Kamlesh: The majority of our inspection issues are gone. When Dev Mode was released, we updated RazorSharp to run as a Dev Mode plugin, so that our devs can use the RazorSharp plugin without needing to worry about editing files to see the code implementation. Because the functionality was already there, it only took 2 days to make it Dev Mode compatible.

We are also using Dev Mode to embed Storybook links for each component to make it easier for our design system consumers to navigate to the code playground on Storybook for that component.

We are in the process of transitioning our tokens to variables. While it’s still early, we are starting to see some advantages in how our devs work.

Copying tokens from design to code is now seamless. Instead of removing slashes from the tokens names(surface/text/subtle) we can now assign a dev-friendly structure(surface.text.subtle) accordingly. Also, we now have spacing tokens mapped to variables, which was a constant ask from our consumer teams.

Out of the box, light & dark mode can be implemented without re-creating designs from scratch for both the modes. Another previous problem that we faced with Blade on Figma was the massive memory consumption it required due to multiple modes (light/dark) on multiple themes (payment/banking) for each of our components. This really hindered our designer productivity due to the sheer slowness of the systems during design. However with the introduction of variables we have been able to streamline Blade into a single theme which massively boosts designer productivity.

Saurav: There are a few other features that have made our workflows better. Using the VS Code plugin our developers can write code without losing their context by switching between Figma and code. The box model helps developers visualize the designs closer to the code inside Figma itself. With compare changes and version history, developers have more transparency on when a file has changed. That helps them to freeze the files and scope things to avoid missing timelines due to last-minute changes

Improving productivity and design system adoption

What’s been the impact on your teams from these changes?

Saurav: We surveyed our designers and devs, and 80% said that they felt more productive when using our Blade design system versus without it. Dev Mode has played a large role in making our design system easier to understand and adopt.

Kamlesh: It’s still early days, not all of our developers have tried Dev Mode. The devs who have started using Dev Mode have seen improvements to their workflow with, either reducing friction between design and dev or increasing productivity overall.

Want to learn more about how Razorpay builds and maintains their design systems? Check out the Blade design system on GitHub, or see their best practices on the Razorpay Design and Engineering blogs. Visit their Design blog, or check out Blade design system on GitHub.

If you want to explore our own private plugin for code gen, read Figma’s dev docs, or use our codegen plugin sample on GitHub.