Razorpay: Impulsionando a adoção de design system e a colaboração entre design e desenvolvimento com o Figma

A Razorpay é uma das maiores empresas de serviços financeiros da Índia e uma das que mais crescem, atendendo a 10 milhões de negócios. Nesta sessão de perguntas e respostas, conversamos com a equipe de design system para saber mais sobre:

• A abordagem da equipe na adoção e monitoramento do design system
• Os desafios que enfrentaram na colaboração entre design e desenvolvimento
• Como eles usaram o Dev Mode e os plug-ins privados para melhorar os fluxos de trabalho da equipe
• O impacto do Figma na produtividade e na adoção do design system

Como o seu time e a sua plataforma estão estruturados?

Soni: Temos cerca de 70 designers e 100 desenvolvedores front-end. Dentro dessas equipes, temos 3 designers e 5 engenheiros trabalhando em nosso design system.

Kamlesh: A extensão dos nossos produtos inclui aplicativos para web (desktop e web móvel), iOS e Android. Temos um único design system que funciona em várias plataformas com a mesma API e o mesmo conjunto de propriedades. Se um desenvolvedor mudar do desenvolvimento de aplicativos web para o de aplicativos móveis, ele poderá levar seu conhecimento de código web para o aplicativo móvel. Adotamos essa abordagem porque não queremos investir tempo reconstruindo para diferentes plataformas.

Conte mais sobre seu design system e por que ele é importante?

Soni: O Blade é o design system da Razorpay. Antes de implementá-lo, algumas nuances passavam despercebidas pelas equipes facilmente, como diferentes estados de botões ou como um erro em um campo de texto que deveria ser corrigido. As equipes tentavam codificar e criar tudo de forma personalizada e, ao fazer isso, podiam deixar algo de fora por engano.

Como resultado, havia muito trabalho de desenvolvimento ad-hoc e repetitivo e, com isso, a experiência do cliente era prejudicada. Isso é importante para um produto como o nosso, em que as empresas confiam seu dinheiro a você. Uma experiência de produto tranquila ajuda a estabelecer essa confiança.

Além disso, a Razorpay, como marca, é formada por vários produtos em diferentes domínios, e precisamos de coerência entre as diferentes interfaces de usuário de nossos produtos. Ter um design system e uma linguagem compartilhada nos permite fazer isso desde o início, com muito mais agilidade. Ele também garante que os componentes do Blade sejam acessíveis a todos os nossos usuários.

Kamlesh: Como trabalhamos com design systems, tanto a equipe de desenvolvimento quanto a de design são clientes, além dos usuários finais. Com o Blade, todos falam a mesma língua, o que reduz o atrito entre as equipes e acelera o tempo de lançamento no mercado. Nós o desenvolvemos de forma que o que você vê em design é o que você tem no código.

Como a equipe promoveu a adoção do Blade?

Kamlesh: Essa é a parte mais complicada de qualquer ferramenta. Tomamos várias medidas para incentivar o uso e reduzir atritos:

• Adesão da liderança: Alinhar e influenciar a liderança é crucial para a evolução do design system, desde a concepção até o financiamento da equipe, além do incentivo para que suas próprias equipes adotem o Blade.
• Identificação das principais métricas: Usando ferramentas e scripts internos, rastreamos métricas qualitativas e quantitativas, como o número de projetos integrados ao Blade ou a porcentagem de aplicativos criados com o nosso DS. Isso facilita o entendimento do progresso para a liderança e para nós.
• Suporte ativo aos consumidores: Há um horário disponível para tirar dúvidas e um canal do Slack em que os consumidores podem publicar perguntas ou problemas. Se for uma questão relevante, a equipe de consumidores vai escalar os problemas de GH que passam pela triagem da nossa equipe. Também temos um grupo de promotores, que inclui designers das nossas equipes de consumidores. Eles ajudam a tomar decisões sobre os componentes e os defendem em suas próprias equipes.
• Evangelização dentro da organização: Para novos componentes, anunciamos com um vídeo de demonstração e atualizamos uma página de status de componentes. Essas duas coisas nos ajudam a evitar que as equipes de consumidores criem componentes que já existem no design system.

Como você mede o impacto da sua equipe?

Kamlesh: Nosso principal objetivo é permitir que as equipes entreguem uma UI moderna e elegante com o mínimo de esforço no Figma e no código, para que possam se concentrar no lançamento de recursos do produto, enquanto o design system cuida do resto. Em um nível elevado, definimos uma meta de que os novos recursos devem usar o Blade em 70% de seu design, e 50% para produtos existentes. Esse KPI é compartilhado por design e desenvolvimento, e ambas as equipes estão motivadas a alcançá-lo juntas.

No entanto, o que aprendemos é que a cobertura real começa na fase design. Se os designs não forem criados com os componentes do nosso DS, os desenvolvedores não saberão que também precisam criá-los com o Blade. Para resolver isso, criamos um plugin de Blade Coverage que mostra aos designers o quanto eles estão desviando do nosso design system. Usando o plugin, designers podem prever melhor seus cronogramas de lançamento e reduzir o atrito durante a entrega, pois recebem feedback mais cedo sobre os componentes que estão usando.

As métricas quantitativas, por si só, não conseguem medir a adoção e o impacto de um design system, por isso também usamos pesquisas internas e grupos focais. Isso nos ajuda a entender o sentimento, por exemplo, se o Blade ajudou uma equipe a entregar mais rapidamente, a experiência da equipe com ferramentas, documentação, sessões de treinamento e se estamos realmente reduzindo o atrito entre designers e desenvolvedores. Tudo isso se transforma em um Net Promoter Score que acompanhamos anualmente.

Resolvendo atritos entre design e o desenvolvimento com plug-ins privados no Figma

Antes da sua equipe começar a usar o Dev Mode, como era a colaboração durante o handoff e o desenvolvimento?

Kamlesh: Quando acontece o handoff, espera-se que os desenvolvedores inspecionem cada elemento e copiem as propriedades de acordo. Mas a experiência anterior não era ideal e era maçante. Os desenvolvedores clicavam, clicavam, clicavam, até que acidentalmente chegavam ao componente certo, identificavam os componentes, viam suas propriedades e as implementavam no código.

Para resolver essas ineficiências de inspeção, um de nossos desenvolvedores criou um plugin privado chamado RazorSharp. Isso levou de 2 a 3 meses como um projeto paralelo. Isso nos permitiu gerar automaticamente o código equivalente para os projetos. A partir daí, os desenvolvedores podiam simplesmente copiar e colar o código.

Nosso plugin RazorSharp resolveu alguns dos problemas para os desenvolvedores, mas não todos. Antes do Dev Mode, os plugins no Figma só podiam ser executados se você tivesse acesso de edição ao arquivo, mas a maioria dos nossos desenvolvedores não tinha esse acesso. Isso significava que, se um designer entregasse a eles um arquivo Figma, o desenvolvedor precisaria realizar a etapa extra de cloná-lo em um novo arquivo para poder executar o plugin RazorSharp.

Acelerando a adoção de design system com Dev Mode

Como o Dev Mode (incluindo variáveis) ajudou a resolver esses pontos problemáticos?

Kamlesh: A maioria dos nossos problemas de inspeção foi eliminada. Quando o Dev Mode foi lançado, atualizamos o RazorSharp para ser executado como um plugin Dev Mode, para que nossos desenvolvedores possam usar o plugin RazorSharp sem precisar se preocupar em editar arquivos para ver a implementação do código. Como a funcionalidade já estava lá, foram necessários apenas dois dias para torná-la compatível com o Dev Mode.

Também estamos usando o Dev Mode para incorporar links do do Storybook em cada componente. Isso facilita a navegação dos consumidores do nosso design system no code playground no Storybook para esse componente.

Estamos no processo de transição de nossos tokens para variáveis. Embora ainda seja cedo, estamos começando a ver algumas vantagens na forma como nossos desenvolvedores trabalham.

Copiar tokens do design para o código agora é perfeita. Em vez de remover as barras dos nomes dos tokens (surface/text/subtle), agora podemos atribuir uma estrutura amigável ao desenvolvedor(surface.text.subtle). Além disso, agora temos tokens de espaçamento mapeados para variáveis, o que era um pedido constante das nossas equipes de consumidores.

De imediato, os modos claro e escuro podem ser implementados sem a necessidade de recriar designs do zero para ambos os modos. Outro problema anterior que enfrentamos com o Blade no Figma foi o enorme consumo de memória que ele exigia devido aos vários modos (claro/escuro) em vários temas (pagamento/banco) para cada um dos nossos componentes. Isso realmente prejudicou nossa produtividade de design devido à lentidão dos sistemas durante o design. No entanto, com a introdução do variáveis, conseguimos simplificar o Blade em um único tema, o que aumentou enormemente a produtividade do designer.

Saurav: Há alguns outros recursos que tornaram nossos fluxos de trabalho melhores. Usando o plugin VS Code, nossos desenvolvedores podem escrever código sem perder o contexto ao alternar entre o Figma e o código. O modelo de caixa ajuda os desenvolvedores a visualizar os designs mais próximos do código dentro do próprio Figma. Com a comparação de alterações e o histórico de versões, os desenvolvedores têm mais clareza sobre quando um arquivo foi alterado. Isso ajuda a congelar os arquivos e a definir o escopo para evitar a perda de cronogramas devido a alterações de última hora.

Aumento da produtividade e adoção do design system

Qual foi o impacto dessas mudanças em suas equipes?

Saurav: Fizemos uma pesquisa com nossos designers e desenvolvedores e 80% disseram que se sentiam mais produtivos usando nosso design system Blade em comparação a não usá-lo. O Dev Mode desempenhou um papel importante para tornar nosso design system mais fácil de entender e adotar.

Kamlesh: Ainda é cedo, nem todos os nossos desenvolvedores experimentaram o Dev Mode. Os desenvolvedores que começaram a usar o Dev Mode perceberam melhorias em seu fluxo de trabalho, seja reduzindo o atrito entre design e desenvolvimento ou aumentando a produtividade em geral.

Quer saber mais sobre como a Razorpay cria e mantém seus sistemas design? Confira o design system Blade no GitHub ou veja suas práticas recomendadas nos blogs Razorpay design e Engineering. Visite o Design blog ou confira o Blade design system no GitHub.

Se quiser explorar nosso próprio plugin privado para geração de código, leia os documentos de desenvolvimento do Figma ou use nossa amostra do plugin de geração de código no GitHub.