Razorpay built Blade, a cross-platform design system, to create consistent, accessible experiences across its many products while accelerating collaboration between designers and developers. Its success depends not only on reusable components, but also on adoption metrics, advocacy, developer tooling, and tight integration between design and code. Tools such as Blade Coverage, RazorSharp, Dev Mode, Storybook links, and Figma variables have significantly reduced handoff friction and improved productivity.
## Blade’s Cross-Platform Structure
- Razorpay has around 70 designers and 100 front-end developers.
- Three designers and five engineers work full-time on Blade.
- Blade supports desktop web, mobile web, iOS, and Android through a shared API and common properties.
- This allows developers to transfer knowledge between platforms without rebuilding the system for each one.
## Problems Blade Solved
- Before Blade, teams frequently hard-coded custom components and missed details such as:
- Button states
- Text-field error handling
- Accessibility requirements
- Repetitive, ad hoc development led to inconsistent user experiences across Razorpay’s products and domains.
- Blade provides:
- A shared design and development language
- More consistent experiences across products
- Built-in accessibility
- Faster collaboration and shorter time to market
- Designers and developers are treated as Blade’s customers, while end users benefit from the resulting consistency and reliability.
## Driving Design System Adoption
- Razorpay uses several strategies to reduce adoption friction:
- Securing leadership support for funding and organizational adoption
- Tracking metrics such as onboarded projects and the percentage of apps using Blade components
- Holding office hours and maintaining a support Slack channel
- Creating an advocacy group of designers from consumer teams
- Announcing new components through demo videos and status-page updates
- These practices make Blade visible, supported, and easier for individual teams to adopt.
## Measuring Impact and Coverage
- Blade’s north star is enabling teams to ship polished interfaces while the system handles common design and implementation work.
- Its adoption targets are:
- 70% Blade usage for new features
- 50% usage for existing product surfaces
- Razorpay discovered that adoption begins during design, not just development.
- The Blade Coverage plugin shows designers where their designs diverge from Blade components, helping them:
- Identify issues earlier
- Predict launch timelines more accurately
- Reduce handoff friction
- Quantitative metrics are supplemented with surveys and focus groups measuring speed, documentation, training, collaboration, and user experience.
- These findings contribute to an annual Net Promoter Score for the design system.
## RazorSharp and Improved Developer Handoffs
- Before Dev Mode, developers had to inspect designs manually, identify components and properties, and reproduce them in code.
- A developer created RazorSharp as a private plugin that automatically generated equivalent code for designs.
- Initially, Figma required edit access to run plugins, forcing developers to clone shared files before using RazorSharp.
- When Figma introduced Dev Mode, Razorpay adapted RazorSharp to work there in just two days.
- Developers can now inspect designs and generate implementation code without editing or duplicating files.
- Dev Mode also includes links to Storybook, allowing developers to move directly from a design component to its code playground.
## Variables and Design Tokens
- Razorpay is transitioning its design tokens to Figma variables.
- This makes token copying more seamless and supports developer-friendly naming such as `surface.text.subtle`.
- Spacing tokens are now mapped to variables, addressing a frequent request from consuming teams.
- Variables make light and dark modes easier to implement without duplicating entire designs.
- Previously, multiple themes and modes caused Blade files to consume large amounts of memory and slowed designers down.
- Consolidating Blade into a single theme with variables has substantially improved design performance.
Razorpay’s approach shows that a design system is most effective when it is treated as an internal product: it needs leadership support, measurable adoption goals, user support, and tooling that connects design directly to implementation. Teams building similar systems should invest in both component quality and the workflows that make those components easy to discover and use.
