Product Designer
✦
igma
São Paulo
Product Designer
✦
igma
sp
Product Designer
✦
igma
Alcançando eficiência e consistência através de um design system
RAÍZEN & RAÍZEN POWER
MINHA POSIÇÃO
PRODUCT DESIGNER
RESPONSABILIDADES
ADOÇÃO, DOCUMENTAÇÃO, COMPONENTES E TOKENS, CONSISTÊNCIA VISUAL
Criamos um design system escalável para a Raízen Power, apoiando iniciativas digitais voltadas à gestão e distribuição de energia solar para os segmentos B2B e B2C, o que resultou em uma redução de 48% no tempo de desenvolvimento.
A empresa contava com diversos produtos construídos sobre o Angular Material, uma biblioteca baseada em Angular que oferecia possibilidades limitadas de personalização e exigia alto esforço de manutenção.
Criamos um design system escalável para a Raízen Power, apoiando iniciativas digitais voltadas à gestão e distribuição de energia solar para os segmentos B2B e B2C, o que resultou em uma redução de 48% no tempo de desenvolvimento.
A empresa contava com diversos produtos construídos sobre o Angular Material, uma biblioteca baseada em Angular que oferecia possibilidades limitadas de personalização e exigia alto esforço de manutenção.
PROBLEMA
A empresa contava com diversos produtos construídos sobre o Angular Material, uma biblioteca baseada em Angular que oferecia possibilidades limitadas de personalização e exigia alto esforço de manutenção.
Esse cenário criava um ciclo ineficiente entre design e desenvolvimento, impactava diretamente a experiência dos usuários e a dificultava a expectativa do negócio de aplicar o Brandbook recém-criado de forma rápida e eficiente.
A empresa contava com diversos produtos construídos sobre o Angular Material, uma biblioteca baseada em Angular que oferecia possibilidades limitadas de personalização e exigia alto esforço de manutenção.
Esse cenário criava um ciclo ineficiente entre design e desenvolvimento, impactava diretamente a experiência dos usuários e a dificultava a expectativa do negócio de aplicar o Brandbook recém-criado de forma rápida e eficiente.
dESAFIOS
– Desenvolvedores enfrentavam dificuldades para adaptar componentes.
– Designers criavam novos componentes a cada entrega
– Fricção nas comunicações entre produto, design e desenvolvimento em agendas de handoff.
– Retrabalhos durantes as sprints.
– Brandbook não estava refletido nos produtos.
– Desenvolvedores enfrentavam dificuldades para adaptar componentes.
– Designers criavam novos componentes a cada entrega
– Fricção nas comunicações entre produto, design e desenvolvimento em agendas de handoff.
– Retrabalhos durantes as sprints.
– Brandbook não estava refletido nos produtos.
impacto
Redução no tempo de desenvolvimento
Redução no tempo de desenvolvimento
4 sprints para 2 sprints
4 sprints para 2 sprints
≈ 50%
≈ 50%
Menos de 90 dias para primeira versão (v1)
Menos de 90 dias para primeira versão (v1)
5 componentes e 70+ tokens na v1
5 componentes e 70+ tokens na v1
82
82
Pessoas impactadas
Pessoas impactadas
300+
300+
Componentes usados nos produtos
Componentes usados nos produtos
81%
81%
Tokens desenvolvidos espelhados em design e código
Tokens desenvolvidos espelhados em design e código
125
125
Componentes desenvolvidos espelhados em design e código
Componentes desenvolvidos espelhados em design e código
44
44
diagnóstico inicial
Com o apoio de um designer focado em Ops, conduzi 32 entrevistas com designers, desenvolvedores, arquitetos, QAs e PMs.
O objetivo era entender os gargalos de processo e desenvolvimento.
Principais descobertas:
– O retrabalho aumentava os ciclos de desenvolvimento
– A ausência de documentação gerava inconsistências entre design e código
– Havia mais bugs em componentes personalizados
– Existia uma expectativa alta para aplicar a nova identidade visual
Em paralelo, fizemos uma auditoria de design nos produtos existentes para identificar padrões, cores, tipografias, componentes mais usados e problemas de acessibilidade.
Com o apoio de um designer focado em Ops, conduzi 32 entrevistas com designers, desenvolvedores, arquitetos, QAs e PMs.
O objetivo era entender os gargalos de processo e desenvolvimento.
Principais descobertas:
– O retrabalho aumentava os ciclos de desenvolvimento
– A ausência de documentação gerava inconsistências entre design e código
– Havia mais bugs em componentes personalizados
– Existia uma expectativa alta para aplicar a nova identidade visual
Em paralelo, fizemos uma auditoria de design nos produtos existentes para identificar padrões, cores, tipografias, componentes mais usados e problemas de acessibilidade.
tokens
Estruturei o sistema de tokens em duas camadas:
– Core tokens: derivados do Brandbook paleta base e valores primitivos: green-100, purple-500
– Semantic tokens: nomenclatura contextual, por exemplo: background-primary-brand, background-failure.
Os nomes foram definidos em conjunto com o time de desenvolvimento para garantir espelhamento 1:1 entre design e código.
Estruturei o sistema de tokens em duas camadas:
– Core tokens: derivados do Brandbook paleta base e valores primitivos: green-100, purple-500
– Semantic tokens: nomenclatura contextual, por exemplo: background-primary-brand, background-failure.
Os nomes foram definidos em conjunto com o time de desenvolvimento para garantir espelhamento 1:1 entre design e código.
Componentes espelhados entre design e código
Componentes espelhados entre design e código
– Defini propriedades (props) no Figma com naming conventions idênticas às do Angular, que permitiu um handoff mais direto e reduziu erros de interpretação.
– Criei o Lab, um arquivo no Figma que funcionava como um playground, onde os designers testavam novos componentes antes do release oficial
– Implementamos junto a um desenvolvedor um Storybook, que passou a servir como documentação dos componentes e referência compartilhada entre as squads.
– Defini propriedades (props) no Figma com naming conventions idênticas às do Angular, que permitiu um handoff mais direto e reduziu erros de interpretação.
– Criei o Lab, um arquivo no Figma que funcionava como um playground, onde os designers testavam novos componentes antes do release oficial
– Implementamos junto a um desenvolvedor um Storybook, que passou a servir como documentação dos componentes e referência compartilhada entre as squads.
app – antes e depois
Implementação e evolução
A primeira versão foi aplicada em uma squad construindo um produto novo com Angular 18.
Feedback pós-implementação:
– Devs: Manutenção fácil com ajustes mínimos de layout
– Designers: Protótipos de alta fidelidade mais consistentes.
– Negócio: Redução de retrabalho e ganhos de eficiência mensuráveis.
Hoje, o design system conta com 125 tokens e 44 componentes, sendo atualizado continuamente.
A primeira versão foi aplicada em uma squad construindo um produto novo com Angular 18.
Feedback pós-implementação:
– Devs: Manutenção fácil com ajustes mínimos de layout
– Designers: Protótipos de alta fidelidade mais consistentes.
– Negócio: Redução de retrabalho e ganhos de eficiência mensuráveis.
Hoje, o design system conta com 125 tokens e 44 componentes, sendo atualizado continuamente.
aprendizados