Petz | Design system
Função
UX/UI Designer
Design System Specialist
Ano
2023 - atual
Ferramenta
Figma · Storybook · Zeroheight
Acesso concedido aos bastidores! Role a página para conferir a documentação e o processo criativo por trás desta versão.
Objetivo
Unificar os Design Systems das marcas Petz, Zee.Dog e Seres em uma única arquitetura multimarcas, criando uma base escalável para design e desenvolvimento.
Desafio
Transformar três Design Systems independentes em um único ecossistema, mantendo a identidade de cada marca sem abrir mão da consistência, escalabilidade e facilidade de manutenção.
3 Design Systems
Estruturas independentes para cada marca.
Retrabalho
Tokens duplicados
Valores repetidos e sem uma estrutura consistente.
Inconsistência
Manutenção triplicada
Atualizações precisavam ser replicadas em diferentes arquivos.
Retrabalho
Documentação fragmentada
Componentes e regras mantidos em estruturas diferentes.
Baixa autonomia
Visão geral do projeto
Ao início, existiam três Design Systems independentes, um para cada marca do ecossistema Petz.
Além de aumentar o esforço de manutenção, essa estrutura dificultava a evolução do sistema e gerava duplicidade de tokens, componentes e documentação.
Tomei a iniciativa de transformar essa estrutura em um Design System único de multimarcas, capaz de compartilhar uma mesma base enquanto preserva as particularidades de cada marca.
Meu papel
A partir dessa iniciativa, passei a construir a arquitetura, estrutura de tokens, construção dos componentes, documentação, e a governança do novo Design System.
Ao longo do projeto me aproximei dos times de Design, Desenvolvimento e QA, trabalhando em conjunto na evolução do Design System como produto.
O processo do projeto
Desmebrando o jornada de construção.
Fase 1 | Arquitetura
O primeiro passo foi entender qual seria a estrutura ideal antes de sair mexendo em tokens ou componentes. Mapeei as marcas, a necessidade de cada uma e defini as bibliotecas que passariam a existir.
Bibliotecas
Uma estrutura para atender diferentes necessidades, permitindo centralizar o que era comum sem perder a identidade de cada marca.
O Design System passa a ser construído por um conjunto de bibliotecas.
Fase 2 | Brand tokens
Antes, cada marca tinha seus próprios tokens de cor, muitas vezes repetindo o mesmo valor com nomes diferentes, possuindo tokens duplicados e sem hierarquia. Para resolver isso, construí uma arquitetura de tokens em 3 níveis:
Level 01
.primitives
São as cores base do sistema, em valores hexadecimais, agrupadas por tonalidade (ex: #175EA8)
Level 02
.alias
São os temas de cada marca. Aqui um único token compartilhado (ex: brand-400) aponta para primitivos diferentes dependendo da marca.
Level 03
.semantic
São os tokens aplicados diretamente nos componentes, com papel funcional definido (ex: color-surface-primary-mid), organizados por type, usage e level.
Esse sistema permite uma manutenção segmentada e isolada de forma prática.
Fase 3 | Global tokens
Com a estrutura de cores resolvida, parti para tudo que poderia ser compartilhado entre as três marcas sem variação: Border, Elevation, Grid, Opacity, Shadow, Spacing, Typography e Writing. Para cada um, defini um padrão único de estrutura e nomenclatura:
Esses tokens passaram a funcionar como uma camada compartilhada entre todas as marcas, garantindo consistência e reduzindo decisões repetitivas durante a construção das interfaces.
Fase 4 | Core components
Com a arquitetura de tokens definida, reconstruí os componentes utilizando essa nova base. O objetivo não era apenas criar uma biblioteca visual, mas estabelecer padrões reutilizáveis, previsíveis e fáceis de implementar. Sendo uma centralização para os times de Design, Desenvolvimento, Produto e QA.
Cada componente passou a seguir uma documentação padrão:
Identidade
Estrutura e organização do componente no Figma.
Design
Variants, propriedades e estados disponíveis.
Regras
Orientações de uso e comportamento.
Anatomia
Estrutura interna e relação entre os elementos.
Fase 5 | Governança
Depois da construção da base, passei a trabalhar na criação de processos para que o sistema pudesse evoluir de forma organizada. Foram definidos fluxos para a criação, evolução e reporte de componentes, com etapas de validação entre Design, Desenvolvimento e QA. Também foi estabelecido um processo de publicação e comunicação das atualizações, garantindo que todos os times acompanhassem a evolução do sistema.
Fase 6 | Design System como produto
O Design System passou a ser tratado como um produto compartilhado entre Design, Desenvolvimento e QA, aproximando também os times de Web, iOS e Android. Para manter todos alinhados, estabeleci reuniões, canais de comunicação e atualizações dentro do próprio DS, acompanhando suas necessidades, evoluções e adesão.
Fase 7 | Writing
A estrutura do Design System também foi ampliada para além da interface.
Em parceria com o time de Writing, construímos uma biblioteca de textos e mensagens padronizadas para os componentes.
A iniciativa ajudou a transformar o conteúdo em mais uma camada reutilizável do sistema, trazendo consistência também para a experiência verbal dos produtos.
Em construção
Fase 7 | De componentes para templates
Com os componentes mais maduros e os padrões mais bem definidos, surgiu uma nova oportunidade: subir um nível na abstração.
Começamos a construir templates para os fluxos mais recorrentes dos produtos. Em vez de oferecer apenas peças individuais, o Design System passou a ajudar os times a construir experiências completas de forma mais rápida e consistente.
Impacto
De três sistemas para um ecossistema.
Menos retrabalho
Uma única estrutura substituiu a manutenção de múltiplos sistemas.
Consistência
Padrões compartilhados entre marcas e plataformas.
Velocidade
Designers e desenvolvedores passaram a partir de estruturas já definidas.
Autonomia
Documentação e playground facilitaram a utilização dos componentes.
Previsibilidade
Regras e comportamentos passaram a ser definidos antes da implementação.
Escala
Uma mesma arquitetura consegue atender diferentes marcas e produtos.
O resultado
O que começou como a iniciativa de unificar três Design Systems se transformou em uma estrutura compartilhada por diferentes marcas, plataformas e times.
A nova arquitetura reduziu duplicidades, centralizou padrões e criou uma base mais simples para manutenção e evolução. Mas, principalmente, mudou a forma como o Design System era utilizado. De uma biblioteca de componentes para um produto vivo, construído em conjunto pelos times.
Um Design System não é um entregável, é um produto vivo. Presente em constante evolução, que só funciona se for tratado com processo e métrica. O maior ganho não foi técnico, foi organizacional: unificar arquitetura e comunicação gerou economia real de tempo para todos os times envolvidos.
:(
O carregamento de arte pesada, interações complexas e nostalgia visual causou uma falha de compatibilidade neste tamanho de tela.
Acesse este link por um computador para uma experiência completa.
Quer saber quem está por trás do erro? Acesse:
https://www.linkedin.com/in/ana-carolina-balan/
Error: DEVICE_NOT-SUPPORTED
:(
O carregamento de arte pesada, interações complexas e nostalgia visual causou uma falha de compatibilidade neste tamanho de tela.
Acesse este link por um computador para uma experiência completa.
Quer saber quem está por trás do erro? Acesse:
https://www.linkedin.com/in/ana-carolina-balan/
Error: DEVICE_NOT-SUPPORTED
Para mais detalhes sobre o projeto, me da um alô! :)
