Construindo um design system escalável
e consistente
Construindo um design system escalável
e consistente
Construindo um design system escalável e consistente
Raízen / Raízen Power
2024 - 2025
Construimos um design system do zero na Raízen Power, marca de energia renovável do grupo Raízen. O resultado? Uma redução de 52% de tempo no desenvolvimento, 81% dos componentes sendo utilizados nos produtos e adoção em massa pelos usuários.
Construimos um design system do zero na Raízen Power, marca de energia renovável do grupo Raízen. O resultado? Uma redução de 52% de tempo no desenvolvimento, 81% dos componentes sendo utilizados nos produtos e adoção em massa pelos usuários.
Introdução
O Ampere é o primeiro design system da Raízen Power, marca de energia renovável do grupo Raízen. Esse projeto reduziu significativamente o tempo de desenvolvimento em cerca de 52%, além de melhorar a usabilidade, acessibilidade, presença da marca e refino dos produtos.
A sua primeira versão foi construída em apenas 82 dias, com todos os tokens e 5 componentes iniciais espelhados em design e código.
O Ampere é o primeiro design system da Raízen Power, marca de energia renovável do grupo Raízen. Esse projeto reduziu significativamente o tempo de desenvolvimento em cerca de 52%, além de melhorar a usabilidade, acessibilidade, presença da marca e refino dos produtos.
A sua primeira versão foi construída em apenas 82 dias, com todos os tokens e 5 componentes iniciais espelhados em design e código.
Overview
Fui contratado pela Raízen para construir o design System do zero, algo que tinha feito com o DomoDS na SenseData.
Inicialmente, comecei a explorar como tudo estava sendo construído, tanto com o time de produtos, design e engenharia. Na época, tínhamos uma biblioteca do Angular Material que era consumida nos produtos.
O problema dessa abordagem é a dificuldade para os desenvolvedores estilizarem componentes pré-prontos da biblioteca, já que os designers precisavam de componentes específicos, cores da marca, tipografia própria e outros elementos para construir melhores interfaces.
Minha estratégia inicial foi apresentar para a liderança um plano de discovery, construção, documentação e implementação. Com base no plano, podia garantir que as principais dores do designers e desenvolvedores seriam solucionadas.
Fui contratado pela Raízen para construir o design System do zero, algo que tinha feito com o DomoDS na SenseData.
Inicialmente, comecei a explorar como tudo estava sendo construído, tanto com o time de produtos, design e engenharia. Na época, tínhamos uma biblioteca do Angular Material que era consumida nos produtos.
O problema dessa abordagem é a dificuldade para os desenvolvedores estilizarem componentes pré-prontos da biblioteca, já que os designers precisavam de componentes específicos, cores da marca, tipografia própria e outros elementos para construir melhores interfaces.
Minha estratégia inicial foi apresentar para a liderança um plano de discovery, construção, documentação e implementação. Com base no plano, podia garantir que as principais dores do designers e desenvolvedores seriam solucionadas.
Proposta de migração em fases: Discovery, Construção, Documentação e handoff, Implementação e acompanhamento
Proposta de migração em fases: Discovery, Construção, Documentação e handoff, Implementação e acompanhamento
Proposta de migração em fases: Discovery, Construção, Documentação e handoff, Implementação e acompanhamento
Equipe
2 Product Designers (🙋🏽♂️)
1 Desenvolvedor frontend
2 Product Designers (🙋🏽♂️)
1 Desenvolvedor frontend
Identificando problemas
Conversei com cerca de 32 pessoas, entre elas designers, desenvolvedores, arquitetos, QAs, PMs, para identificar problemas ou que não gostavam do sistema atual.
Os insights obtidos nas conversas foram essenciais para desenhar a solução que atendesse a todos os envolvidos de maneira eficaz e sem sobrecarregar nenhum time, entre eles:
O retrabalho era constante, aumentando o tempo de desenvolvimento
Não existia documentação de uso, o que facilitava erros e inconsistências entre design e código
O número de bugs dos componentes personalizados eram maiores
A construção da marca era recente e existia uma expectativa em como as novas diretrizes seriam aplicadas nas aplicações
Em paralelo, realizei uma Auditoria de Design nos produtos existentes identificando padrões, cores, tipografias, componentes mais utilizados, problemas de usabilidade e acessibilidade. Assim era possível definir por onde começar a construir de fato.
Conversei com cerca de 32 pessoas, entre elas designers, desenvolvedores, arquitetos, QAs, PMs, para identificar problemas ou que não gostavam do sistema atual.
Os insights obtidos nas conversas foram essenciais para desenhar a solução que atendesse a todos os envolvidos de maneira eficaz e sem sobrecarregar nenhum time, entre eles:
O retrabalho era constante, aumentando o tempo de desenvolvimento
Não existia documentação de uso, o que facilitava erros e inconsistências entre design e código
O número de bugs dos componentes personalizados eram maiores
A construção da marca era recente e existia uma expectativa em como as novas diretrizes seriam aplicadas nas aplicações
Em paralelo, realizei uma Auditoria de Design nos produtos existentes identificando padrões, cores, tipografias, componentes mais utilizados, problemas de usabilidade e acessibilidade. Assim era possível definir por onde começar a construir de fato.
Auditoria de Design nos produtos existentes identificando padrões, cores, tipografias, componentes mais utilizados, problemas de usabilidade e acessibilidade
Auditoria de Design nos produtos existentes identificando padrões, cores, tipografias, componentes mais utilizados, problemas de usabilidade e acessibilidade
Auditoria de Design nos produtos existentes identificando padrões, cores, tipografias, componentes mais utilizados, problemas de usabilidade e acessibilidade
Design tokens e mapeamento
de componentes
Design tokens e
mapeamento
de componentes
Com base na auditoria, identifiquei 5 componentes que mais apareciam nos produtos:
Botão (primário e secundário)
Input de texto
Checkbox
Card
Snackbar
Junto a esse mapeamento, comecei a definir os design tokens do zero seguindo o brandbook da marca e sugestões para melhoria para casos mais específicos. Trabalhei junto ao desenvolvedor, para definir as melhores nomenclaturas e variáveis.
Para as cores, defini 2 níveis de token: Core e Semantic
As cores Core são derivadas do Brandbook e serviam muito bem para o contexto, existiam diferentes variações das principais cores e uma paleta de neutras que nos atendia
Já as Semantic são nomenclaturas utilizadas com base em como elas são usadas e aplicadas em tela, o valor das variáveis Semantic deriva das Core.
Com base na auditoria, identifiquei 5 componentes que mais apareciam nos produtos:
Botão (primário e secundário)
Input de texto
Checkbox
Card
Snackbar
Junto a esse mapeamento, comecei a definir os design tokens do zero seguindo o brandbook da marca e sugestões para melhoria para casos mais específicos. Trabalhei junto ao desenvolvedor, para definir as melhores nomenclaturas e variáveis.
Para as cores, defini 2 níveis de token: Core e Semantic
As cores Core são derivadas do Brandbook e serviam muito bem para o contexto, existiam diferentes variações das principais cores e uma paleta de neutras que nos atendia
Já as Semantic são nomenclaturas utilizadas com base em como elas são usadas e aplicadas em tela, o valor das variáveis Semantic deriva das Core.
Aplicação das cores Core e Semantic
Aplicação das cores Core e Semantic
Decription
Aplicação das cores Core e Semantic
Outros exemplos de tokens para sombra, espaçamento, altura de linha e arrodandamento de borda
Outros exemplos de tokens para sombra, espaçamento, altura de linha e borda
Outros exemplos de tokens para sombra, espaçamento, altura de linha e arrodandamento de borda
Componentes espelhados
em design e código
Se tratando de componentes, garanti que as propriedades estivessem o mais claras possíveis e parecidas com o que havia no código para que tanto o dev quando o designer que utilizassem e se comunicassem da forma correta, também apresentei para líderes o Dev Mode, que poderia facilitar ainda mais para os desenvolvedores.
Antes de oficializar cada componente, fizemos sessões de teste com o time de design para ajustar nomenclaturas e melhorar a experiência de uso, e para isso criamos o Ampere Lab, um arquivo no Figma onde os designers se reuniam para testar os componentes.
Se tratando de componentes, garanti que as propriedades estivessem o mais claras possíveis e parecidas com o que havia no código para que tanto o dev quando o designer que utilizassem e se comunicassem da forma correta, também apresentei para líderes o Dev Mode, que poderia facilitar ainda mais para os desenvolvedores.
Antes de oficializar cada componente, fizemos sessões de teste com o time de design para ajustar nomenclaturas e melhorar a experiência de uso, e para isso criamos o Ampere Lab, um arquivo no Figma onde os designers se reuniam para testar os componentes.
Documentação e handoff
A documentação dos componentes e tokens existentes era inexistente, sem um padrão claro para organização e uso e a estrutura não facilitava a consulta por designers e desenvolvedores.
Para resolver isso, reestruturei a documentação utilizando a ferramenta o Figma e o Storybook. Agora, cada componente possui descrição detalhada, exemplos de uso, boas práticas, especificações técnicas e código correspondente, facilitando a adoção o dentro da empresa.
A documentação dos componentes e tokens existentes era inexistente, sem um padrão claro para organização e uso e a estrutura não facilitava a consulta por designers e desenvolvedores.
Para resolver isso, reestruturei a documentação utilizando a ferramenta o Figma e o Storybook. Agora, cada componente possui descrição detalhada, exemplos de uso, boas práticas, especificações técnicas e código correspondente, facilitando a adoção o dentro da empresa.
Componente botão e suas propriedades
Ampere LAB
Arquivo onde os designers podiam testar novos componentes, sugerindo melhorias.
Visão geral e boas práticas
Documentação com boas práticas e link da Storybook
Componentes no Storybook
Documentação de uso e implementação para desenvolvedores
Componente botão e suas propriedades
Ampere LAB
Arquivo onde os designers podiam testar novos componentes, sugerindo melhorias.
Visão geral e boas práticas
Documentação com boas práticas e link da Storybook
Componentes no Storybook
Documentação de uso e implementação para desenvolvedores
Implementação e adoção
Decidimos começar a implementar numa squad que estava construindo um novo produto e aproveitamos para usar o Angular 18 (o mais recente na época).
Felizmente a adoção foi muito positiva, os desenvolvedores relataram mais facilidade na implementação dos componentes, e os designers sentiram maior consistência e velocidade ao construir protótipos, e o negócio se beneficiou com a redução do retrabalho, resultando em economia de tempo, recursos e custos operacionais.
Atualmente, o Ampere segue evoluindo e é constantemente atualizado, já foram 125 tokens e 44 componentes criados.
Resultados e impacto
52% de tempo de desenvolvimento (entre discovery e delivery)
81% dos componentes já foram aplicados nos produtos
82 dias para implementação da primeira versão
125 design tokens criados
44 componentes criados
Adoção em massa por designers e desenvolvedores, com uma curva de aprendizado baixa
Aprendizados
Esse projeto me ensinou que, para criar um design system eficiente, é crucial envolver os times desde o início, para garantir que as necessidades de todos sejam atendidas. Com isso, foi possível evitar retrabalho e criar algo que fosse verdadeiramente útil e atendesse às expectativas.
Aprendi também que uma documentação bem estruturada e acessível é fundamental para garantir a adoção do sistema. Organizar as informações de forma visual e clara fez toda a diferença para as equipe.
Por fim, aprendi que implementar um design system vai muito além de criar componentes e tokens. Trata-se de melhorar a forma como as equipes trabalham juntas, promovendo mais agilidade e eficiência em todo o processo.
Implementação e adoção
Decidimos começar a implementar numa squad que estava construindo um novo produto e aproveitamos para usar o Angular 18 (o mais recente na época).
Felizmente a adoção foi muito positiva, os desenvolvedores relataram mais facilidade na implementação dos componentes, e os designers sentiram maior consistência e velocidade ao construir protótipos, e o negócio se beneficiou com a redução do retrabalho, resultando em economia de tempo, recursos e custos operacionais.
Atualmente, o Ampere segue evoluindo e é constantemente atualizado, já foram 125 tokens e 44 componentes criados.
Resultados e impacto
52% de tempo de desenvolvimento (entre discovery e delivery)
81% dos componentes já foram aplicados nos produtos
82 dias para implementação da primeira versão
125 design tokens criados
44 componentes criados
Adoção em massa por designers e desenvolvedores, com uma curva de aprendizado baixa
Aprendizados
Esse projeto me ensinou que, para criar um design system eficiente, é crucial envolver os times desde o início, para garantir que as necessidades de todos sejam atendidas. Com isso, foi possível evitar retrabalho e criar algo que fosse verdadeiramente útil e atendesse às expectativas.
Aprendi também que uma documentação bem estruturada e acessível é fundamental para garantir a adoção do sistema. Organizar as informações de forma visual e clara fez toda a diferença para as equipe.
Por fim, aprendi que implementar um design system vai muito além de criar componentes e tokens. Trata-se de melhorar a forma como as equipes trabalham juntas, promovendo mais agilidade e eficiência em todo o processo.
Agradecimentos
Gostaria de agradecer a toda liderança, que me deu confiança e autonomia para tomar decisões, a todos os designers e desenvolvedores que usaram e usam o Ampere diariamente, esse projeto não sairia do papel senão fossem vocês.
Agradecer ao Ro 🤍, um dos melhores profissionais com que trabalhei, sempre prestativo e com uma liderança técnica formidável, sua parceria foi incrível para construirmos o produto.
E obrigado você que chegou até aqui!
Componente botão e suas propriedades
Componente botão e suas propriedades
Ampere LAB
Arquivo onde os designers podiam testar novos componentes, sugerindo melhorias.
Ampere LAB
Arquivo onde os designers podiam testar novos componentes, sugerindo melhorias.
Visão geral e boas práticas
Documentação com boas práticas e link da Storybook
Visão geral e boas práticas
Documentação com boas práticas e link da Storybook
Componentes no Storybook
Documentação de uso e implementação para desenvolvedores
Componentes no Storybook
Documentação de uso e implementação para desenvolvedores