Razorpay: impulsa la adopción de sistemas de diseño, y la colaboración entre diseño y desarrollo con Figma.

Razorpay es una de las compañías de servicios financieros más grande de la India, y da servicio a 10 millones de negocios. En esta entrevista hablamos con el el equipo de sistemas de diseño para aprender sobre:

• Su enfoque para medir y adoptar un sistema de diseño
• Desafíos a los que se enfrentaron al colaborar diseño con desarrollo
• Cómo usaron Dev Mode y plugins privados para mejorar los workflow de equipos
• El impacto de Figma en la adopción del sistema de diseño y la productividad.

¿Cómo está estructurado vuestro equipo y vuestra plataforma?

Soni: tenemos unos 70 diseñadores y 100 desarrolladores front-end. Dentro de esos equipos, contamos con 3 diseñadores y 5 ingenieros que trabajan en nuestro sistema de diseño.

Kamlesh: nuestros productos abarcan tanto web (versiones para escritorio y móvil) como aplicaciones para iOS y Android. Contamos con un único sistema de diseño que funciona de manera transversal en todas las plataformas, utilizando la misma API y el mismo conjunto de propiedades. Si un desarrollador pasa de desarrollar web a desarrollar una app móvil, puede aplicar directamente sus conocimientos de código web en app. Optamos por esta estrategia para evitar invertir tiempo en crear versiones distintas para cada plataforma.

Háblanos de vuestro sistema de diseño y de por qué es importante.

Soni: Blade es el sistema de diseño Razorpay. Antes de que lo pusiéramos en marcha, era fácil que los equipos pasaran por alto muchos pequeños matices, como los diferentes estados de los botones o cómo se debe gestionar un error en un campo de texto. Los equipos intentaban codificar y crear todo a medida y, al hacerlo, podían omitir algo por error.

Como resultado, había mucho trabajo de desarrollo improvisado y repetitivo, lo que afectaba negativamente a la experiencia del usuario. Esto es crucial para un producto como el nuestro, donde las empresas confían en ti para gestionar su dinero. Ofrecer una experiencia fluida es clave para generar esa confianza.

Además, Razorpay, como marca, se compone de múltiples productos en distintos ámbitos, por lo que necesitamos coherencia entre las distintas interfaces de usuario de nuestros productos. Tener un sistema de diseño y un lenguaje compartido nos permite hacerlo desde cero con mucha más agilidad. También garantiza que todos los Componentes de Blade sean completamente accesibles para todos nuestros usuarios.

Kamlesh: como trabajamos en sistemas diseño, tanto los desarrolladores como los diseñadores son nuestros clientes, y además los usuarios finales. Con Blade, todos hablan el mismo idioma, lo que reduce las fricciones entre equipos y acelera el tiempo de comercialización. Lo hemos construido de forma que lo que se ve en diseño es lo que se obtiene en código.

¿Cómo ha enfocado tu equipo la adopción de Blade?

Kamlesh: esta es la parte más complicada de cualquier herramienta - plataforma: hemos tomado múltiples medidas para fomentar y reducir los puntos de fricción:

• Conseguir la implicación de los directivos: alinear e influir en el liderazgo es crucial para la evolución de nuestro sistema de diseño, desde el inicio hasta la financiación de equipo para animar a sus propios equipos a adoptar Blade.
• Identificación de métricas clave: utilizando herramientas y scripts internos, hacemos un seguimiento de métricas cualitativas y cuantitativas, como el número de proyectos que se incorporan a Blade o el % de aplicaciones creadas con nuestro sistema de diseño. Esto facilita tanto a los equipos directivos como a nosotros comprender el progreso.
• Apoyo activo a los consumidores: hay un horario de atención al cliente y un canal en Slack donde los usuarios pueden plantear consultas o problemas. Si el problema es válido, el equipo de usuarios crea issues en GitHub que nuestro equipo se encarga de priorizar. También hemos formado un grupo de representantes, que incluye diseñadores de los equipos de nuestros clientes. Ellos ayudan a tomar decisiones sobre los componentes y promueven su uso dentro de sus propios equipos.
• Evangelizando dentro de nuestra org: si hay nuevos componentes, lo anunciamos con un video demo y una página sobre el estado del componente. Ambas cosas nos ayudan a evitar que nuestros consumidores creen componentes que ya existen en el sistema de diseño.

¿Cómo mides el impacto en tu equipo?

Kamlesh: perseguimos facilitar a los equipos que puedan entregar interfaces de usuario elegantes y modernas con el mínimo esfuerzo en Figma y así pueden centrarse en desarrollar y entregar funcionalidades de producto mientras el sistema de diseño se encarga del resto. A un alto nivel, nos hemos fijado el objetivo de que las nuevas funciones utilicen Blade en el 70% de su diseño, y en el 50% de las interfaces de productos existentes. Este KPI es compartido por diseño y desarrollo, y ambos equipos están motivados para perseguirlo juntos.

De todas formas, lo que hemos aprendido es que la cobertura real empieza en la fase de diseño. Si los diseñadores no están construyendo con los componentes de nuestro sistema de diseño, los desarrolladores no sabrán que lo tienen que desarrollar con Blade también. Para solucionar esto, creamos un plugin de Blade coverage que muestra a los diseñadores cuánto se están desviando de nuestro sistema de diseño. Con este plugin, los diseñadores pueden predecir mejor sus tiempos de entrega y reducir fricciones durante el traspaso, ya que reciben feedback antes sobre los componentes que están utilizando.

Las métricas cuantitativas por si solas no pueden medir el impacto de la adopción del sistema de diseño, así que también utilizamos encuestas internas y focus groups. Esto ayuda a entender el sentimiento, tanto si Blade ha ayudado al equipo hacer entregas más rápido, la experiencia del equipo con las herramientas, las formaciones, y si realmente estamos reduciendo la fricción entre diseñadores y desarrolladores. Todo esto contribuye a un Net Promoter Score que seguimos anualmente.

Solucionando las fricciones entre diseño y desarrollo con plugins privados en Figma

Antes de que tu equipo empezara a utilizar Dev Mode, ¿cómo era la colaboración durante el traspaso y el desarrollo?

Kamlesh: cuando se hace el traspaso, se espera que los desarrolladores inspecciones cada elemento y copien las propiedades en consecuencia. Pero la experiencia previa no fue buena. Los desarrolladores hacían clic, clic y clic hasta que por casualidad daban con el componente correcto, identificaban el componentes, veían sus propiedades y luego implementaban lo mismo en el código.

Para redirigir estas ineficiencias de inspección, uno de nuestros desarrolladores creó una plugin privado llamada RazorSharp. Fue un proyecto secundario de unos 2 o 3 meses. Esto nos permitió autogenerar el código equivalente para los diseños. A partir de ahí, los desarrolladores podían simplemente copiarlo y pegarlo.

Nuestro plugin RazorSharop resolvió algunas de las batallas de los desarrolladores, pero no todas. Antes de Dev Mode, los plugins en Figma solo funcionaban si tenías acceso al archivo, pero muchos de nuestros desarrolladores no lo tenían. Así que eso significó que si un diseñador le pasaba un archivo de Figma, el desarrollador tenía que hacer un paso extra, clonarlo en un nuevo archivo para que pudiera funcionar el plugin RazorSharp.

Acelerar la adopción de sistemas de diseños con Dev Mode

¿Cómo ha contribuido Dev Mode (incluyendo variables) a resolver estos problemas?

Kamlesh: la mayoría de nuestros problemas de inspección han desaparecido. Cuando lanzamos Dev Mode actualizamos RazorSharp para que funcionara como un plugin de Dev Mode, de modo que nuestros desarrolladores pudieran utilizar el plugin de RazorSharp sin tener que preocuparse de editar archivos para ver la implementación del código. Debido a que la funcionalidad ya estaba allí, sólo necesitamos 2 días para hacerlo compatible con Dev Mode.

También estamos utilizando Dev Mode para incrustar enlaces de Storybook en cada componente, facilitando a los usuarios de nuestro sistema de diseño navegar al entorno de pruebas de código en Storybook para ese componente.

Estamos en el proceso de transición de nuestros tokens a variables. Aunque aún es pronto, estamos empezando a ver algunas ventajas en la forma de trabajar de nuestros desarrolladores.

Copiar tokens del diseño al código ahora es mucho más fácil. En lugar de eliminar las barras de los nombres de los tokens (interface / texto/ sutil), ahora podemos asignar una estructura más amigable para los desarrolladores (interface / texto/ sutil). Además, ahora tenemos tokens de espaciado asignados a variables, que era una petición constante de nuestros equipos de consumidores.

Desde el principio, los modos claro y oscuro se pueden implementar sin necesidad de recrear los diseños desde cero para ambos modos. Un problema anterior al que nos enfrentábamos con Blade en Figma era el enorme consumo de memoria que requería debido a los múltiples modos (claro/oscuro) en varios temas (pago/banca) para cada uno de nuestros componentes. Esto realmente afectaba la productividad de los diseñadores debido a la lentitud de los sistemas durante el proceso de diseño. Sin embargo, con la introducción de variables, hemos logrado optimizar Blade en un solo tema, lo que ha impulsado significativamente la productividad de los diseñadores.

Saurav: hay algunas otras funcionalidades que han mejorado nuestros workflows. Con el plugin de VS Code, nuestros desarrolladores pueden escribir código sin perder el contexto al cambiar de Figma a código. El modelo de caja ayuda a los desarrolladores a visualizar los diseños de manera más cercana al código directamente dentro de Figma. Con las funciones de comparación de cambios e historial de versiones, los desarrolladores tienen más transparencia sobre cuándo se ha modificado un archivo. Esto les permite bloquear los archivos y definir el alcance para evitar retrasos debido a cambios de última hora.

Mejorando la productividad y adopción de sistemas de diseño

¿Qué impacto han tenido estos cambios en tus equipos?

Saurav: encuestamos a nuestros diseñadores y desarrolladores, y el 80% dijo que se sentían más productivos cuando utilizaban nuestro sistema de diseño Blade que cuando no. Dev Mode ha desempeñado un papel importante a la hora de hacer que nuestro sistema de diseño sea más fácil de entender y adoptar.

Kamlesh: aún es pronto, no todos nuestros desarrolladores han probado Dev Mode. Los desarrolladores que han empezado a utilizar Dev Mode han visto mejoras en su flujo de trabajo, ya sea reduciendo la fricción entre diseño y desarrollo o aumentando la productividad en general.

¿Quieres saber más sobre cómo Razorpay construye y mantiene sus sistemas diseño? Echa un vistazo al sistema de diseño Blade en GitHub, o fíjate en sus mejores ejemplos de uso en los blogs de Razorpay diseño e Ingeniería. Visita su Blog de diseño , o consulta el sistema de diseño Blade en GitHub.

Si quieres explorar nuestro plugin privado para la generación de código, lee los docs dev de Figma, o utiliza nuestro ejemplo plugin generador de código en GitHub.