Como transformei decisões duplicadas entre dois produtos em uma fundação compartilhada capaz de evoluir sem multiplicar complexidade.
CONTEXTO
Neotrust e Aftersales evoluíam sobre estruturas de interface que acumulavam variações, exceções e decisões duplicadas. À medida que novos requisitos, marcas e temas surgiam, manter consistência exigia cada vez mais esforço.
DESAFIO
Permitir que os produtos evoluíssem de forma independente sem aumentar, na mesma proporção, o custo de manutenção, retrabalho e inconsistência.
ABORDAGEM
Propus substituir uma biblioteca centrada em componentes por uma arquitetura de Design Tokens organizada em quatro camadas: Global, Brand, Semantic e Component.
IMPACTO
A nova fundação passou a estruturar decisões de forma reutilizável entre os dois produtos e criou uma linguagem compartilhada para Design, Engenharia, Produto e QA. Mais tarde, ela revelou potencial para servir como contexto em experimentos com IA.
Ao longo da evolução da plataforma, percebemos que o principal desafio já não era criar novos componentes. Era manter decisões consistentes entre diferentes produtos, marcas, temas, times e tecnologias.
O que começou como uma iniciativa para reorganizar um Design System acabou se tornando o redesenho da arquitetura que sustentava toda a experiência da plataforma. A arquitetura passou a sustentar fluxos de Neotrust e Aftersales sobre a mesma fundação, com expectativa de expansão futura.
Essa arquitetura passou a funcionar como uma linguagem compartilhada, capaz de conectar Design, Engenharia, Produto, QA e agentes de IA à mesma fonte de verdade.
Como criar um Design System que pudesse evoluir continuamente sem que sua complexidade crescesse na mesma velocidade dos produtos?
Toda arquitetura nasce de um problema. Esta nasceu quando percebemos que nosso Design System já não acompanhava a velocidade de evolução da plataforma.
O Design System havia sido criado para promover consistência e acelerar desenvolvimento. Por algum tempo, essa estratégia funcionou: mais componentes, mais variantes, mais regras.
Conforme o ecossistema amadurecia, tornou-se evidente que o aumento da biblioteca não estava reduzindo a complexidade; ela apenas mudava de lugar. Cada nova necessidade gerava exceções, cada nova marca introduzia personalizações e cada novo contexto exigia adaptações.
O Design System continuava crescendo, mas sua capacidade de organizar decisões diminuía gradualmente.
Os problemas surgiam em decisões aparentemente pequenas:
Individualmente, pareciam inofensivos. Coletivamente, mostravam que a arquitetura havia deixado de ser uma fonte de verdade compartilhada.
Inicialmente, tratamos o problema como puramente visual. Ao aprofundar a investigação, percebemos que ele era estrutural.
As diferenças não estavam apenas nas interfaces; estavam nas decisões. Cada equipe interpretava conceitos semelhantes de maneiras diferentes. Uma mesma intenção gerava implementações distintas. Design, Engenharia e Produto discutiam soluções usando linguagens diferentes.
O Design System continuava organizando componentes.
Mas já não organizava decisões.
Como acontece em muitos Design Systems em crescimento, a hipótese inicial parecia lógica: talvez faltassem componentes, documentação ou uma reorganização da biblioteca.
Por algum tempo seguimos esse caminho e reorganizamos arquivos, revisamos componentes, refatoramos estruturas, melhoramos documentação. Essas iniciativas geraram ganhos pontuais, mas não resolveram a origem do problema.
A cada novo produto, a complexidade voltava a crescer.
Até então, nossa principal pergunta era:
Como organizar melhor nossos componentes?
Os sintomas apontavam para outra direção. Os componentes continuavam funcionando; o que havia deixado de escalar eram as decisões que definem esses componentes.
Foi nesse ponto que formulei uma nova tese:
Componentes são consequência.
Decisões são causa.
Pela primeira vez, deixamos de investigar a biblioteca. Passamos a investigar a arquitetura que sustentava suas decisões.
Antes de redesenhar qualquer arquitetura, houve uma barreira menos técnica. Stakeholders de negócio e equipes com backlog cheio questionavam:
"Se já temos um Design System em Figma, por que mexer nisso em vez de focar em novas features?"
Essa dúvida é comum: muitos design systems são vistos como iniciativas de UI, não como alavancas de produto.
Minha resposta não poderia ser apenas estética. Reestruturei a conversa em torno de três eixos:
Ao trocar "refazer o Design System" por "diminuir o custo de mudança para toda a plataforma", a conversa deixou de ser sobre componentes e passou a ser sobre estratégia.
Com a tese clara (organizar decisões, não componentes), o próximo passo foi transformá-la em arquitetura.
A primeira decisão arquitetural foi identificar qual seria a menor unidade capaz de representar uma escolha de design independentemente de um componente específico. Essa unidade precisava existir antes do Button, do Input, do Card, da própria interface.
Design Tokens ofereciam exatamente essa característica. Eles permitiam representar decisões fundamentais (cor, tipografia, espaçamento, raio, elevação) de forma abstrata, reutilizável e independente da implementação final.
Componentes descrevem interfaces.
Tokens descrevem decisões.
Ao deslocar o foco da camada visual para a camada semântica, deixamos de pensar em "como o componente parece" e passamos a pensar em "qual decisão ele representa".
Representar decisões não era suficiente. Também era necessário saber quem é responsável por qual delas.
Percebemos que as decisões se organizavam em níveis de abstração diferentes:
Misturar tudo na mesma camada era justamente o que fazia a complexidade explodir. A solução foi distribuir responsabilidades em níveis independentes.
A arquitetura foi estruturada em quatro camadas:
valores fundamentais da plataforma.
identidade visual de cada marca (Neotrust, Aftersales).
significado, não aparência.
contrato entre componentes e a arquitetura.
Cada camada conhece apenas a camada imediatamente inferior. Essa separação reduz acoplamentos e torna a evolução previsível. Diferente de sistemas que resolvem marca só na camada semântica, isolamos Brand como camada própria porque Neotrust e Aftersales precisavam trocar identidade visual inteira sem duplicar as regras de significado — marca vira parâmetro de entrada da arquitetura, não uma bifurcação de regras.
Global representa valores básicos, sem significado de marca atribuído:
Global não conhece marcas, componentes ou contextos específicos. Sempre que um valor realmente muda, é aqui que a alteração acontece. É a fundação da arquitetura.
Brand traduz Global para a identidade visual de cada marca. É aqui que Neotrust e Aftersales se diferenciam, sem duplicar componentes.
Cada marca define:
Marcas não precisam conhecer hexadecimais. Elas referenciam Global Tokens. Uma nova marca passa a existir alterando aliases em Brand, não componentes. Isso reduziu o tempo para lançar uma nova marca de cerca de 2–3 semanas de trabalho manual para 2–3 dias ajustando aliases.
Semantic representa significado.
Ela não conhece valores concretos nem marcas, mas responde perguntas como:
Em vez de color/purple/600, falamos em surface/action.
Marcas mudam.
Significados permanecem.
Ao mudar o foco de cor para significado, desacoplamos comportamento da identidade visual.
Component conecta a arquitetura ao componente.
Ela não define valores finais; apenas descreve quais decisões cada componente consome.
Um Button, por exemplo, conhece:
Cada propriedade aponta para Semantic Tokens, que apontam para Brand, que apontam para Global. Component deixa de armazenar decisões e passa a consumi-las.
Hoje, a mesma arquitetura sustenta:
Neotrust e Aftersales compartilham a fundação de tokens, mantendo comportamentos alinhados mesmo com contextos de negócio diferentes.
identidades visuais distintas são resolvidas na camada Brand, sem duplicar componentes.
Light, Dark e campanhas sazonais representam conjuntos diferentes de aliases, não novas bibliotecas.
decisões de espaçamento, tipografia, densidade e área de toque são centralizadas, permitindo adaptação responsiva entre desktop, tablet e mobile sem proliferar variantes.
Design, Engenharia, Produto, QA e agentes de IA consomem a mesma linguagem arquitetural como fonte de verdade.
Depois de estruturar a arquitetura, precisávamos garantir que os componentes respeitassem a separação. Abandonamos a prática de armazenar valores diretamente dentro dos componentes.
Antes:
Button conhecia #5B3FD9, 16px, 8px, Inter SemiBold, rgba(...) — uma entre 12 variações do mesmo componente espalhadas entre os dois produtos, cada uma com pequenas diferenças de cor, raio ou tipografia.
Depois:
button/primary/bg
↓
surface/action/rest
↓
brand/primary
↓
color/purple/600
O componente não armazena um valor visual diretamente.
button/primary/bg aponta para surface/action/rest, que já carrega o significado (ação) e o estado (repouso) da decisão — estados como hover, pressed e disabled existem como variantes do mesmo token semântico, não como uma camada à parte.
No modo Aftersales / Light, surface/action/rest herda a identidade visual em brand/primary e resolve no primitivo global color/purple/600.
O Button deixa de ser o lugar onde a decisão nasce. Ele passa a ser o lugar onde uma decisão compartilhada é consumida.
A resolução dos aliases varia por marca e tema. Neste exemplo, utilizamos Aftersales / Light, que percorre a cadeia completa entre componente, semântica, marca e valor global, resolvendo em #8F44F7.
A arquitetura de tokens não tinha valor por si só. Ela precisava sair do diagrama e entrar na rotina.
Antes da arquitetura, decisões estavam espalhadas:
Depois, tokens passaram a representar:
Isso reduziu interpretações subjetivas. Discussões deixaram de depender de "como cada um sempre fez" e passaram a se apoiar na mesma linguagem.
Uma arquitetura não permanece consistente sozinha. Ela precisa de regras claras para evoluir.
Definimos critérios que toda nova contribuição deveria respeitar:
O mesmo critério que avaliava a entrada de um token também se aplicava à saída: remover um token passava por aviso prévio às equipes consumidoras antes da exclusão.
Componentes deixaram de ser resposta automática. A primeira pergunta passou a ser:
"Esta necessidade representa uma nova decisão, um novo token ou apenas uma combinação do que já existe?"
Como Design e Engenharia passaram a trabalhar sobre a mesma estrutura de decisões, muitas conversas deixaram de acontecer em nível visual. As discussões migraram para significados, responsabilidades e contratos entre camadas.
Design deixou de entregar apenas telas. Engenharia deixou de receber apenas especificações. Ambos passaram a compartilhar o mesmo vocabulário arquitetural, com Storybook como interface comum.
Na prática, os tokens viviam como Variables nativas do Figma — o plano pago do Tokens Studio não estava no orçamento, e a versão gratuita não cobria o que a arquitetura exigia. A ponte até o código era o MCP do Figma: agentes de IA liam as Variables diretamente do arquivo de design e geravam os artefatos consumidos pelos produtos, versionados no GitHub. A mesma infraestrutura que mais tarde alimentou os experimentos de IA já nascia sendo lida por máquinas.
A arquitetura precisava ser acessível para diferentes públicos. O Storybook cumpriu esse papel.
Mais do que um catálogo de componentes, passou a funcionar como uma camada de visualização da arquitetura:
Documentação e implementação deixaram de evoluir em trilhas separadas. O que estava na arquitetura era o que estava no Storybook. O que estava no Storybook era o que chegava em produção.
Mesmo com um Design System documentado, desenvolvedores frequentemente não o utilizavam como referência principal. Na prática, o sistema existia em Figma; o código seguia caminhos próprios.
Conversas com Engenharia revelaram padrões conhecidos:
Em muitos casos, o caminho mais rápido era copiar o que já estava funcionando, mesmo que inconsistente, em vez de consultar o Design System.
Tratei isso como sinal, não como falha individual. Um Design System não é adotado por ser "correto"; ele precisa ser mais rápido e mais previsível do que o atalho.
Essa percepção influenciou diretamente a forma como desenhei a arquitetura: ela precisava nascer onde devs realmente trabalham (tokens, repositórios, Storybook), não apenas em Figma.
A arquitetura não nasceu para IA. Ela nasceu para organizar decisões.
Quando decisões passaram a ter nomes, responsabilidades e dependências explícitas, surgiu uma consequência que não fazia parte do escopo inicial: a mesma estrutura que ajudava pessoas a interpretar componentes também poderia oferecer contexto para máquinas.
Durante o desenvolvimento deste case, surgiu uma pergunta:
"Se um desenvolvedor consegue compreender um componente a partir dos seus tokens, será que um modelo de IA também conseguiria?"
Grande parte das discussões sobre IA aplicada a design estava concentrada em gerar interfaces por prompt, produzir imagens ou gerar código. Pouco se falava sobre a qualidade da informação consumida pelos modelos.
Decidimos inverter a lógica. Em vez de pedir para a IA "inventar" uma interface, passamos a fornecer a própria arquitetura como contexto.
No primeiro experimento, solicitamos que um modelo de IA reconstruísse um Button apenas com uma descrição textual:
O resultado era funcional, mas apresentava inconsistências: espaçamentos diferentes, hierarquia tipográfica diferente, contrastes imprecisos, estados inconsistentes. Cada nova execução variava detalhes.
Embora visualmente aceitáveis, essas diferenças acumulavam inconsistências na interface.
No segundo experimento, utilizamos exatamente o mesmo prompt. A única diferença foi fornecer ao modelo a estrutura de tokens que descrevia o Button, incluindo a cadeia:
button/primary/bg
↓
surface/action/rest
↓
brand/primary
↓
color/purple/600
Em vez de decidir sozinho qual valor visual utilizar, o modelo passou a reconstruir o componente a partir da arquitetura fornecida.
No exemplo Aftersales / Light, o contexto incluía o token de componente, os aliases semânticos, a referência de marca e o valor global resolvido. Assim, as decisões deixaram de depender apenas da interpretação do modelo e passaram a depender de contratos explícitos do sistema.
Em um terceiro passo, testamos um cenário mais extremo. Exportamos apenas os tokens relacionados ao Button, sem screenshots, sem arquivos de Figma e sem código.
O modelo recebeu apenas a estrutura de tokens e foi instruído:
"Reconstrua este componente respeitando a arquitetura descrita."
O resultado apresentou aderência relevante à estrutura fornecida, embora ainda exigisse ajustes. Pequenos ajustes ainda eram necessários, mas a maior parte das decisões foi corretamente interpretada.
O componente deixou de ser apenas um artefato visual. Passou a ser consequência direta da arquitetura.
Esses experimentos modificaram a forma como passamos a enxergar o Design System. Antes, os consumidores eram apenas pessoas.
Agora, também existem consumidores automatizados:
A arquitetura deixou de organizar apenas componentes. Passou a organizar conhecimento.
Arquiteturas bem estruturadas não escalam apenas produtos.
Elas escalam conhecimento.
Este foi um experimento exploratório, não uma validação científica nem uma promessa de geração autônoma de interfaces. O principal aprendizado foi que arquitetura estruturada melhora a qualidade do contexto disponível para futuros fluxos de automação e assistência.
A IA não foi o ponto de partida. Foi a consequência de tornar decisões legíveis.
O verdadeiro sucesso deste projeto não foi apenas a arquitetura criada, mas a mudança na forma como a organização passou a tomar decisões sobre seus produtos.
Variações do Button consolidadas
Tempo para lançar uma marca nova
Componentes na arquitetura de tokens
Relatos de inconsistência visual
Bibliotecas de design unificadas
Novos produtos passaram a reutilizar a mesma fundação arquitetural. A evolução deixou de depender da criação contínua de novos componentes.
Neotrust e Aftersales passaram a compartilhar tokens globais, semântica de superfícies e ações e contratos de componentes. Isso reduziu a necessidade de criar bibliotecas independentes para cada produto. Ao todo, cerca de 35 a 40 componentes core passaram a consumir a arquitetura de tokens.
Alterações passaram a ocorrer nas camadas responsáveis por cada decisão. Rebranding atua principalmente em Brand Tokens; ajustes de acessibilidade em Semantic; atualizações tipográficas em Global.
Essa reorganização criou condições para reduzir retrabalho e tornar mudanças mais previsíveis, além de diminuir efeitos colaterais durante evoluções da interface.
Produtos diferentes passaram a compartilhar os mesmos significados, mesmo com identidades visuais distintas. Decisões como "ação primária", "erro crítico" ou "sucesso" são expressas pela mesma semântica, independentemente da marca. Relatos de inconsistência visual entre produtos caíram de cerca de 8–10 por trimestre para 1–2.
Design, Engenharia, Produto e QA passaram a discutir utilizando uma linguagem comum. As conversas deixaram de focar em valores específicos (hexadecimais, pixels) e passaram a focar em responsabilidades e significados. Ao todo, 2 produtos e essas 4 disciplinas passaram a operar sobre uma única arquitetura compartilhada, em vez de bibliotecas isoladas por produto — à qual a IA se juntou depois, como consumidora, tornando-se a 5ª disciplina conectada.
A plataforma tornou-se preparada para incorporar novas marcas, novos temas e novos produtos sem exigir mudanças estruturais na arquitetura. A cada nova necessidade, a pergunta deixou de ser "que componente precisamos criar?" e passou a ser "que decisão precisa passar a existir?".
Uma forma objetiva de explicar o impacto é comparar como decisões semelhantes eram tratadas antes e depois do projeto.
Toda arquitetura envolve escolhas. Ao estruturar decisões em camadas independentes, também surgiram desafios.
Entre eles:
Consideramos esses custos aceitáveis diante dos ganhos obtidos em manutenção, previsibilidade, escalabilidade e capacidade de servir múltiplos consumidores (humanos e máquinas).
Se este projeto começasse hoje, algumas decisões seriam diferentes.
Eu:
Os princípios fundamentais, entretanto, permaneceriam os mesmos. Continuaria priorizando decisões sobre componentes.
Componentes evoluem.
Tecnologias mudam.
Ferramentas são substituídas.
Decisões bem estruturadas permanecem.
Este projeto mudou profundamente minha forma de enxergar Design Systems. Antes dele, eu tendia a avaliar maturidade pela qualidade dos componentes.
Hoje, entendo que componentes representam apenas a camada visível de uma arquitetura muito maior. A verdadeira escalabilidade nasce quando decisões deixam de estar implícitas e passam a fazer parte de um sistema compreensível por toda a organização.
Arquiteturas bem definidas escalam conhecimento, não apenas interface. Essa visão passou a orientar meu trabalho em novos projetos de Design Systems, plataformas digitais e iniciativas com IA.
Este case começou como uma iniciativa para evoluir um Design System. Terminou como o desenho de uma arquitetura compartilhada capaz de conectar Design, Engenharia, Produto, QA e Inteligência Artificial através da mesma fonte de verdade.
Mais do que organizar interfaces, essa arquitetura passou a organizar conhecimento. Essa talvez seja sua maior contribuição.
Plataformas escalam quando decisões são compartilhadas. E organizações evoluem quando essas decisões deixam de depender de pessoas específicas e passam a fazer parte da própria arquitetura.
Se você chegou até aqui, provavelmente compartilha o interesse por sistemas que vão além da interface e ajudam organizações inteiras a construir produtos de forma mais consistente, escalável e colaborativa. Esse continua sendo o tipo de desafio que mais me motiva como Product Designer.