Uma marca nova em 3 dias, sem tocar em componente.

00 Arquivo

Produto	O design system que sustenta os aplicativos da Diletta
Produtos que consomem	CPF Seguro, que protege a pessoa contra fraude no nome dela e foi a base do sistema, e Conta Bold, um banco digital · os dois no ar · e, desde outubro, o painel web da Flash Enterprise
Papel	Product Designer, Sênior desde 2025 · Diletta Solutions · no Figma, os componentes foram divididos entre os designers; a ideia, a arquitetura e a execução do sistema foram minhas
Plataforma	Flutter, iOS e Android · web, em web components
Ferramentas	Figma, Flutter, web components, Git, Python, Claude Code
Escopo	tudo além da minha parte dos componentes no Figma: especificações e contratos, cores, pacote de código, versões, catálogo, verificação e governança
Estado em 23/09/2026	versão 1.0.2, com 302 versões publicadas
Período	novembro de 2021 até hoje

---

01 Resumo

Problema. Aplicativos com marcas diferentes, dois no ar e um terceiro a caminho, e um time pequeno. O caminho comum é copiar a biblioteca de componentes para cada um, e aí a correção feita numa cópia não chega nas outras.

Papel e time. No Figma, os componentes foram divididos entre os designers; a ideia, a arquitetura e a execução do sistema foram minhas. Isso inclui contratos, cores, pacote de código, versões, catálogo, verificação e governança. Cada aplicativo tem o seu time de engenharia, que decide quando adotar uma versão nova.

A decisão. Tirar a cor de dentro do componente. A marca virou uma lista de 55 cores que o produto declara, e o componente só sabe o uso: fundo, texto, erro.

Resultado. Quando o Conta Bold entrou no sistema, em julho de 2026, foram 3 dias do levantamento da paleta ao primeiro build. Pelo caminho antigo, de copiar a biblioteca, a minha conta dava seis semanas. Em julho, um aplicativo estava 176 versões atrás. Hoje o CPF Seguro está na atual e o Conta Bold, 5 atrás.

Estado. No ar nos dois aplicativos, versão 1.0.2 em 23/09/2026. Desde outubro roda também na web, no painel da Flash Enterprise.

---

02 Contexto

A Diletta vende software para outras empresas e tem produtos próprios, com nome, marca e público diferentes, atendidos pelo mesmo time de design e front-end. A pergunta era como fazer cada um parecer uma empresa sem manter uma biblioteca por produto. O sistema nasceu do CPF Seguro. O Conta Bold entrou em julho de 2026 como segundo produto, e o ciX, um produto de governo e o terceiro da fila, está em construção.

---

03 Restrição

Time pequeno. Não havia gente para manter um sistema por produto, nem como parar os produtos para refazer a base.

O aplicativo decide quando atualiza. O sistema chega como dependência com número de versão. Se subir quebra alguma tela, ninguém sobe. Quem consome tem veto, e eu acho isso saudável.

Marca de verdade. Cada produto precisa de identidade própria, e mudar o tom do mesmo azul não resolve.

Eu peço e eu julgo. Sou dono do sistema e desenho num dos produtos que usam ele. Várias decisões abaixo tiram esse julgamento da minha memória e colocam num arquivo.

---

04 O problema em número

Antes, ninguém sabia dizer se um componente estava pronto. Pronto no código não era pronto no Figma, e nenhum dos dois batia com a documentação.

A auditoria que eu rodei em julho mediu o preço disso num dos produtos: 176 versões publicadas desde a última que aquele aplicativo tinha adotado, sem uma linha escrita sobre o que mudou. Ninguém atualiza dependência sem saber o que vem dentro. O sistema tinha parado de chegar nos produtos porque faltava o registro.

---

05 O que existia antes

Em 2022 eu resolvi o mesmo problema à mão no Diletta Pay, a plataforma white-label que a Diletta vende para bancos: doze paletas, que são doze cores de marca possíveis num exemplo de aplicação, e vinte e quatro telas desenhadas uma a uma.

O jeito comum de tratar marca é o tema: o componente conhece as cores e os valores trocam por configuração. Funciona enquanto as marcas se parecem. Quando elas se afastam, alguém copia o componente para mudar, e a cópia nunca volta. Então mudei a pergunta para "como faço o componente nunca precisar saber a cor".

---

06 Decisões

D1 · A marca é uma lista de cores, e só

O produto declara 55 cores obrigatórias e 7 opcionais. Com elas o sistema calcula 59 cores de uso, nos dois modos: fundo, texto, erro, sucesso, superfície elevada. Nenhum componente conhece uma cor específica, só o uso dela.

Por quê: enquanto a cor mora no componente, cada marca nova mexe no componente. Com a cor do lado de fora, marca nova é preencher um formulário.

Medido: entre um produto e outro mudam essas 55 cores. Nenhuma alteração em componente ou em teste.

D2 · Três camadas, e cada uma declara só o que é dela

Para dois produtos bastavam duas camadas: o design system em cima, o produto embaixo. A terceira apareceu quando o Conta Bold virou base de uma família de produtos. A base neutra e a identidade dele moravam no mesmo pacote, e todo produto novo da família nascia com a cara do Conta Bold.

A camada do meio declara estrutura e composição. Nunca declara valor que só a marca decide, como cor, tamanho de texto, imagem ou fonte. A primeira verificação que escrevi para essa regra procurava o nome da marca no código e deu zero, com treze tamanhos de texto do Conta Bold lá dentro. Tamanho de texto é número e não carrega nome. Hoje ela procura as duas coisas.

Abri mão de: um desenho mais simples. Duas camadas eram mais fáceis de explicar, e a terceira existe porque o negócio pediu.

D3 · O que o produto esquece de declarar, um relatório mostra

Se o produto não declara uma cor, herda a do sistema. A tela fica errada e ninguém percebe. Por isso um relatório lista, por produto, o que foi declarado e o que foi herdado sem declarar.

Por quê: o modelo só é seguro se o esquecimento aparecer antes de alguém abrir a tela errada.

D4 · Componente aberto em vez de opção de configuração

Quando um produto precisa de um componente que o sistema não tem, ele monta com as partes do sistema, que são públicas. Uma superfície se divide em topo, conteúdo e base, e cada parte pode ser usada sozinha.

Por quê: configuração escondida é contrato que ninguém lê.

Abri mão de: controle sobre o resultado final de cada produto. Em troca, ninguém mais copia o sistema para alterar.

D5 · Pronto é medido em seis lugares

Um componente só está pronto quando bate em seis lugares: a especificação escrita, o código, o catálogo que o time consulta, o arquivo do Figma, a cor que ele mostra de fato em cada modo, e a comparação com o desenho que o produto fez. A verificação devolve número.

Medido: o CPF Seguro usa 85 componentes do sistema, e os 85 passam. Desses, 38 foram comparados com o desenho do produto. Nos outros 47 um dos lugares não se aplica, com o motivo escrito.

D6 · Pedido de produto vira arquivo com resposta escrita

Quando um produto precisa de algo que o sistema não tem, ele escreve um pedido num formato fixo. O pedido entra num registro com a resposta, o motivo e a versão em que entrou. Hoje são 196 linhas.

Uma variante só sobe para o sistema no segundo pedido. Dois times pedindo a mesma coisa quer dizer que falta algo no sistema. Um time só quer dizer que falta algo no produto dele.

Por quê: sem o registro do primeiro pedido, a regra do segundo nunca dispara.

Abri mão de: velocidade. Escrever a resposta demora mais que responder no chat.

D7 · A mesma mudança vale em qualquer plataforma

A Diletta também tem painel de operação e internet banking, os dois na web. Uma mudança num componente do sistema tem que poder ser adotada em qualquer produto, em qualquer plataforma, do mesmo jeito.

Medido: as 93 cores de base já saem para web, como 162 variáveis de CSS. As 59 cores de uso ainda só existem em Flutter, e esse buraco está escrito na decisão.

Como medi o passo: contei o painel de operação antes de propor prazo. São 3.746 componentes no Figma, 2.689 visíveis, contados pelo identificador do componente. Pelo nome da camada o número inflava quase 30%.

D8 · A máquina colhe e mede, e quem decide sou eu

Em agosto surgiu a ideia de dividir a verificação entre agentes de inteligência artificial para ir mais rápido. Cronometrei antes: as quatorze verificações que bloqueiam uma versão levam 15,2 segundos. O tempo estava no julgamento, e cada divergência que eu leio muda a pergunta da próxima.

Dividi por direito de escrita. Um agente colhe fatos e não conclui nada. Outro mede, e só entra em uso depois de ficar vermelho diante de um defeito plantado. Publicar, subir versão e adotar no aplicativo continuam sendo decisão de pessoa.

Abri mão de: a velocidade prometida. A verificação completa segue em cinco minutos, e eu escrevi isso no documento.

Medido: em quatro dias, 11 de 88 entregas de código (12,5%) corrigiam uma medição minha errada. Nenhuma eu peguei relendo.

---

07 Craft

--cps-primary: #003BE0
data-theme:    light
tela:          aplicativo

Na versão 0.175.0 o sistema tinha 128 contratos escritos, um por componente ou parte de componente. O CPF Seguro usa 85 deles. Cada tela tem teste que compara a imagem pixel a pixel com a versão aprovada.

---

08 Resultado

Produto novo em 3 dias. Contei quando o Conta Bold entrou no sistema, em julho de 2026: 3 dias do levantamento da paleta ao primeiro build. Uma sessão para levantar a paleta, uma para declarar as cores e conferir contraste, uma para o build. Pelo caminho antigo eram seis semanas, pela minha leitura do histórico. Os 4 dias do Diletta Pay são outra coisa: em 2022, marca nova na plataforma antiga.

A atualização que ninguém viu. O sistema pulou treze versões de uma vez, com 1.022 arquivos alterados. No aplicativo, as 24 imagens de tela ficaram idênticas e os 2.062 testes passaram.

A circulação. 302 versões publicadas até 23/09/2026, cada uma com registro de mudança. Em julho um aplicativo estava 176 versões atrás. Hoje o CPF Seguro está na atual e o Conta Bold, 5 atrás. O Conta Bold escolhe quando sobe, então esse número mexe de um dia para o outro. Prefiro mostrar essa distância a contar 128 contratos, porque é ela que diz se o sistema está sendo usado.

A web. Em outubro o sistema ganhou uma segunda saída: as mesmas cores, tipos e componentes publicados como web components, hoje 51 peças. O painel da Flash Enterprise trocou o Ant Design por elas em uma semana. Um defeito corrigido no sistema chega no aplicativo e no painel na mesma versão.

A verificação. Na comparação de cor entre o desenho do CPF Seguro e o sistema, 33 pares batem e 29 divergem. Em 22 dessas dá para ler qual cor deveria estar ali e qual está.

---

09 O que eu faria diferente

Testaria o medidor antes de publicar a medida. O programa que contava componentes prontos pulava em silêncio o que não sabia classificar. O primeiro total que publiquei saiu bonito e errado.

Testaria a pergunta certa. Tenho vinte casos anotados de verificação que errou: verde sobre defeito, ou vermelha sem defeito. No primeiro, ela olhava a cor declarada no componente quando a pergunta era a cor do pixel. Azul com 18% de opacidade não é azul cheio. Hoje eu escrevo o caso de defeito antes da verificação.

Escreveria o registro de mudanças antes de precisar dele. As 176 versões sem explicação eram o motivo de o sistema ter parado de chegar nos produtos.

---