Razorpay: Impulsar la adopción de sistemas de diseño y la colaboración entre diseñadores y desarrolladores con Figma

Razorpay es una de las empresas de servicios financieros más grandes y de más rápido crecimiento de India, y actualmente brinda servicio a más de 10 millones de empresas. En esta sesión de preguntas y respuestas, hablamos con su equipo de sistemas de diseño para aprender sobre lo siguiente:

• Cómo abordan la adopción de sistemas de diseño y cómo la miden.
• Qué desafíos encontraron en la colaboración entre diseño y desarrollo.
• Cómo usaron Dev Mode y plugins privados para mejorar los flujos de trabajo del equipo.
• Cuánto impactó Figma en la productividad y la adopción de sistemas de diseño.

¿Cómo es la estructura de su equipo y plataforma?

Soni: Contamos con alrededor de 70 diseñadores y 100 desarrolladores front-end. Dentro de esos equipos, hay 3 diseñadores y 5 ingenieros trabajando en nuestro sistema de diseño.

Kamlesh: Nuestras áreas de productos incluyen web (web de escritorio y móvil) y aplicaciones para iOS y Android. Tenemos un único sistema de diseño que funciona entre plataformas con la misma API y el mismo conjunto de propiedades. Si un desarrollador pasa del desarrollo web al de aplicaciones móviles, puede trasladar sus conocimientos sobre código web a la aplicación móvil. Adoptamos este enfoque porque no queremos invertir tiempo en volver a desarrollar para distintas plataformas.

Cuéntennos sobre su sistema de diseño y por qué es importante.

Soni: Blade es el sistema de diseño de Razorpay. Antes de que lo pusiéramos en marcha, era muy fácil que los equipos pasaran por alto un montón de pequeños detalles, como los diferentes estados de los botones o cómo debe gestionarse un error en un campo de texto. Los equipos intentaban usar codificación rígida y crear todo a medida y, al hacerlo, era probable que omitieran algo por error.

Como resultado, había mucho trabajo de desarrollo ad-hoc y repetitivo, lo que afectaba la experiencia del cliente. Esto es especialmente importante para un producto como el nuestro, donde las empresas confían en ti su dinero. Una experiencia de producto fluida ayuda a establecer esa confianza.

Además, Razorpay, como marca, está compuesta por múltiples productos en diferentes dominios, por lo que necesitamos coherencia entre las diferentes interfaces de usuario de nuestros productos. Tener un sistema de diseño y un lenguaje compartido nos permite lograrlo desde el principio con mucha más agilidad. También garantiza que todos los componentes de Blade sean totalmente accesibles para todos nuestros usuarios.

Kamlesh: Como trabajamos en sistemas de diseño, los desarrolladores y diseñadores son tan clientes como nuestros usuarios finales. Con Blade, todos hablan el mismo idioma, lo que reduce la fricción entre equipos y acelera el tiempo de salida al mercado. Lo hemos construido de tal forma que lo que se ve en el diseño es lo que se obtiene en el código.

¿Cómo ha abordado su equipo la adopción de Blade?

Kamlesh: Esta es la parte más complicada de cualquier plataforma; implementamos muchos pasos para fomentar la adopción y reducir los puntos de fricción:

• Obtener el respaldo de los líderes: Estar en sincronía con los líderes y persuadirlos es fundamental para la evolución de nuestro sistema de diseño, desde la concepción y la fundación del equipo hasta animar a que sus propios equipos adopten Blade.
• Identificar métricas clave: Mediante herramientas y scripts internos, monitoreamos métricas cualitativas y cuantitativas, como el número de proyectos incorporados a Blade o el porcentaje de aplicaciones creadas con nuestro sistema de diseño. Esto hace que sea más fácil para nosotros y los líderes comprender el progreso.
• Brindar asistencia a los usuarios de forma activa: Hay un horario de oficina y un canal de Slack en el que los usuarios pueden enviar consultas o reportar problemas. Si se trata de un problema válido, el equipo de asistencia al usuario generará un problema en GitHub, que luego nuestro equipo se encargará de resolver. También hemos formado un grupo de impulsores, que incluye a diseñadores de nuestros equipos de asistencia al usuario. Este grupo ayuda a tomar decisiones sobre los componentes y las defiende en sus propios equipos.
• Promover dentro de nuestra organización: En el caso de componentes nuevos, los anunciamos con un video de demostración, y actualizamos una página de estado de componente. Ambas cosas nos ayudan a evitar que los equipos de asistencia al usuario creen componentes que ya existen en el sistema de diseño.

¿Cómo miden el impacto de su equipo?

Kamlesh: Nuestro objetivo principal es que los equipos puedan lanzar UI modernas y elegantes sin hacer tanto esfuerzo en Figma y a la hora de codificar, de modo que puedan enfocarse en entregar funciones de producto mientras el sistema de diseño se encarga del resto. En un nivel alto, fijamos el objetivo de que las nuevas funciones deben usar Blade en un 70 % de su diseño y en un 50 % para las áreas de productos existentes. Este KPI es compartido por los equipos de diseño y desarrollo, y ambos están motivados para alcanzarlo juntos.

Sin embargo, lo que aprendimos es que la verdadera cobertura comienza en la etapa de diseño. Si los diseños no se crean con los componentes de nuestro sistema de diseño, los desarrolladores no sabrán que deben desarrollarlos también con Blade. Para abordar esto, creamos el plugin Blade Coverage que muestra a los diseñadores cuánto se están desviando de nuestro sistema de diseño. Con el plugin, los diseñadores pueden prever mejor sus plazos de lanzamiento y reducir la fricción al traspasar el proyecto a los desarrolladores, ya que reciben feedback con anticipación sobre los componentes que están usando.

Las métricas cuantitativas por sí solas no pueden medir la adopción y el impacto de un sistema de diseño, por lo que también usamos encuestas internas y grupos de discusión. Esto nos ayuda a entender el sentimiento, por ejemplo, si Blade ha ayudado a un equipo a entregar un proyecto más rápido; la experiencia del equipo con las herramientas, la documentación y las sesiones de capacitación; y si realmente estamos reduciendo la fricción entre diseñadores y desarrolladores. Todo ello se traduce en una índice de promotores neto (Net Promoter Score, NPS) que comprobamos anualmente.

Resolver la fricción entre diseño y desarrollo con plugins privados en Figma

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

Kamlesh: Cuando se produce el traspaso, los desarrolladores deben inspeccionar cada elemento y copiar las propiedades según corresponda. Nuestra experiencia anterior no era ideal y era bastante molesta. Los desarrolladores tenían que hacer clic por todos lados hasta que por casualidad daban con el componente correcto, identificaban los componentes, veían sus propiedades y luego implementaban lo mismo en el código.

Para solucionar estas ineficiencias en la inspección, uno de nuestros desarrolladores creó un plugin privado llamado RazorSharp. Fue un proyecto paralelo que llevó de 2 a 3 meses y nos permitió generar automáticamente el código equivalente para los diseños. A partir de ahí, los desarrolladores podían simplemente copiar y pegar.

El plugin RazorSharp resolvió algunas de las dificultades de los desarrolladores, pero no todas. Antes de Dev Mode, los plugins en Figma solo se podían ejecutar si tenías permisos para editar el archivo, y la mayoría de nuestros desarrolladores no los tenían. Eso significaba que si el equipo de diseño entregaba un archivo de Figma, el equipo de desarrollo iba a tener que hacer el paso adicional de clonarlo en un nuevo archivo para poder ejecutar el plugin RazorSharp.

Acelerar la adopción del sistema de diseño con Dev Mode

¿Cómo ha ayudado Dev Mode (y sus variables) a resolver estos problemas?

Kamlesh: La mayoría de nuestros problemas de inspección desaparecieron. Cuando se lanzó Dev Mode, actualizamos RazorSharp para que se ejecutara como un plugin de Dev Mode, de modo que nuestros desarrolladores pudieran usar el plugin RazorSharp sin tener que preocuparse de editar archivos para ver la implementación del código. Como la funcionalidad ya estaba ahí, solo llevó dos días hacerlo compatible con Dev Mode.

También estamos usando Dev Mode para integrar enlaces de Storybook para cada componente, de modo que sea más fácil para nuestros usuarios del sistema de diseño navegar al área de pruebas de código en Storybook para ese componente.

Estamos en el proceso de pasar nuestros tokens a variables. Si bien 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 (superficie/texto/sutil), ahora podemos asignarles una estructura adecuada para el desarrollo (superficie.texto.sutil). Además, ahora tenemos tokens de espaciado asignados a variables, lo que era un pedido constante de nuestros equipos de asistencia al usuario.

Los modos claro y oscuro se pueden implementar fácilmente sin necesidad de volver a crear diseños desde cero para ambos modos. Otro problema al que nos enfrentábamos con Blade en Figma era el enorme consumo de memoria que requería debido a los diferentes modos (claro/oscuro) en los diferentes temas (pago/banco) para cada uno de nuestros componentes. Esto realmente perjudicaba la productividad de nuestros diseñadores debido a la gran lentitud de los sistemas durante el diseño. Sin embargo, al introducir variables, hemos podido agilizar Blade y unificarlo en un solo tema, lo que aumenta enormemente la productividad del equipo de diseño.

Saurav: Hay algunas otras funciones que han mejorado nuestros flujos de trabajo. Con el plugin VS Code, nuestros desarrolladores pueden escribir código sin perder el contexto al poder pasar de Figma y al código. El modelo de cuadros ayuda a los desarrolladores a visualizar los diseños más cerca del código dentro de Figma. Con la comparación de cambios y el historial de versiones, los desarrolladores tienen más transparencia sobre cuándo se ha modificado un archivo. Esto les ayuda a congelar los archivos y a delimitar el alcance de las cosas para evitar que se incumplan los plazos por cambios de última hora.

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

¿Cuál han impactado estos cambios en sus equipos?

Saurav: Encuestamos a nuestros diseñadores y desarrolladores, y el 80 % dijo que se sentían más productivos cuando usaban nuestro sistema de diseño Blade que cuando no. Dev Mode ha contribuido en gran medida a 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. Quienes lo han empezado a usar han visto mejoras en su flujo de trabajo, ya sea porque se redujo la fricción entre diseño y desarrollo o porque aumentó la productividad en general.

¿Quieres saber más sobre cómo Razorpay crea y mantiene sus sistemas de desarrollo? Echa un vistazo al sistema de diseño de Blade en GitHub o consulta sus prácticas recomendadas en los blogs de diseño e ingeniería de Razorpay. Visita el blog de diseño o echa un vistazo al sistema de diseño de Blade en GitHub.

Si quieres explorar nuestro propio plugin privado para la generación de código, lee los documentos de desarrollo de Figma o usa nuestra muestra de plugin de generación de código en GitHub.