Design system Diletta

00 Arquivo

Produto	O design system que sustenta os aplicativos da casa
Produtos que consomem	Conta Bold, um banco digital, e CPF Seguro, que protege a pessoa contra fraude no nome dela · os dois no ar, e um terceiro em construção
Papel	Product Designer · Diletta Solutions
Plataforma	Flutter, iOS e Android · e a camada de cor já publicada para web
Ferramentas	Figma, Flutter, Git, Python
Escopo	o sistema inteiro: as regras, os componentes, a verificação automática, a entrega versionada e a ligação com o Figma
Estado em 09/09/2026	versão 0.180.0, com 263 versões publicadas
Período	novembro de 2021 até hoje

Uma linha. Um produto novo entra no sistema declarando uma lista de 55 cores. Nenhum componente é reescrito, nenhum teste é alterado, e um relatório aponta o que aquele produto esqueceu de declarar.

---

01 Resumo

Problema. Três aplicativos, três marcas, um time pequeno. O caminho normal é copiar a biblioteca de componentes para cada produto. Seis meses depois existem três bibliotecas parecidas, e uma correção feita numa delas não chega nas outras.

O que eu fiz. Separei o que é linguagem do que é marca. A marca virou uma lista de cores que o produto declara. Os componentes deixaram de conhecer cores específicas e passaram a conhecer funções: fundo, texto, erro, sucesso. Em cima disso, montei três coisas que não existiam: uma verificação automática que responde se um componente está pronto, uma entrega versionada em que cada produto escolhe quando sobe, e um procedimento escrito para quando um produto precisa de algo que o sistema não tem.

Resultado. 263 versões publicadas. O produto mais atrasado hoje está 24 versões atrás do sistema, e o outro está 8. Na auditoria de julho um deles estava 176 versões atrás, sem uma linha escrita dizendo o que havia mudado. Uma atualização de 1.022 arquivos entrou num dos aplicativos sem mudar um pixel.

Papel. Product Designer na Diletta Solutions. Desenho de ponta a ponta, a arquitetura do sistema, e a régua que julga o que entra nele.

---

02 Contexto

A casa vende software para outras empresas e também tem produtos próprios. São três aplicativos no ar ou em construção, cada um com nome, marca e público diferentes. O time de design e de front-end é o mesmo para os três.

Isso cria um problema simples de enunciar e caro de resolver: como fazer três produtos parecerem três empresas diferentes sem manter três bibliotecas.

---

03 Restrição

Um time pequeno para três marcas. Não havia gente para manter três sistemas em paralelo, e não havia como parar os produtos para reconstruir a base.

O aplicativo decide quando atualiza. O sistema chega no produto como uma dependência versionada. Se subir de versão quebra a tela, ninguém sobe, e o sistema para de circular. Quem consome tem o poder de veto, e isso é saudável.

Marca de verdade, não tema claro e escuro. Cada produto precisa de identidade própria, não de um ajuste de matiz no mesmo azul.

Figma e código não podem divergir. Com duas fontes de verdade, em duas semanas ninguém sabe qual das duas está certa.

Eu sou o dono do sistema e desenho num dos produtos que consomem ele. Isso é um conflito de interesse permanente: o mesmo desenhista que pede é o que julga o pedido. Metade das decisões abaixo existe para tirar esse julgamento da minha memória e pôr num arquivo.

---

04 O problema em número

Antes, a pergunta "este componente está pronto?" não tinha resposta. Pronto no código não é pronto no Figma, e nenhum dos dois é pronto na documentação que o time consulta.

A auditoria que eu rodei em julho mediu o preço disso num dos produtos: 176 versões do sistema publicadas desde a última que aquele aplicativo tinha adotado, e nenhuma linha escrita dizendo o que havia mudado em cada uma.

Ninguém atualiza uma dependência sem saber o que vem dentro. O sistema tinha parado de circular, e nenhuma reunião havia decidido isso: foi só a consequência de não existir um registro.

Hoje o mesmo número, medido em 08/09/2026, é 2 versões de atraso num produto e 18 no outro, com registro de mudança por versão. É esse o número que diz se um design system está vivo, e é o mais fácil de esconder.

---

05 O que existia antes, e por que não servia

O mesmo problema apareceu quatro anos antes, no DPS, e foi resolvido à mão: doze paletas em claro e escuro, vinte e quatro telas desenhadas uma por uma no Figma. Este case é a segunda tentativa, na raiz.

O jeito comum de resolver marca em design system é o tema: o componente conhece as cores e você troca os valores de fora, por configuração.

Isso funciona enquanto as marcas são parecidas. Quando não são, começa a divergência: um produto precisa de um botão que os outros não têm, alguém copia o componente para alterar, e a cópia nunca volta. Foi exatamente esse o caminho que o DPS, o produto anterior da casa, tinha percorrido resolvendo doze marcas à mão no Figma.

Então a pergunta mudou. Em vez de "como configuro a cor deste componente", passou a ser "como faço o componente nunca precisar saber a cor".

---

06 Decisões

D1 · A marca é uma lista de cores, e nada além disso

O produto declara 55 cores obrigatórias e 7 opcionais. A partir delas o sistema calcula as 59 funções que os componentes usam, nos dois modos: cor de fundo, cor de texto, cor de erro, cor de sucesso, cor de superfície elevada, e assim por diante.

Nenhum componente conhece uma cor. Todos conhecem funções.

Consequência medida: a diferença entre um produto e outro são essas 55 cores. Zero alteração em componente, zero em teste.

Por quê: enquanto a cor mora dentro do componente, cada marca nova é uma alteração no componente. Quando ela mora fora, marca nova é preenchimento de formulário.

D2 · A árvore tem três degraus, e cada um declara só o que é dele

Dois degraus resolvem três produtos: a linguagem em cima, o produto embaixo. O terceiro apareceu quando um produto da casa virou base de uma família: a base branca e a identidade do primeiro produto moravam no mesmo lugar, então produto novo nascia vestido do primeiro. A regra do degrau do meio é uma frase: ele declara mecanismo, forma e composição, e nunca declara valor que só um produto decide. Cor crua, degrau de escala, valor de gradiente, caminho de imagem, nome de fonte.

O que faz a regra ser cobrável é a régua, e eu escrevi a régua errada primeiro. Régua que procura NOME de produto não vê identidade que subiu como valor. Uma lista de símbolos com o nome da marca fechava em zero enquanto treze degraus de texto daquela marca estavam dentro da base, porque degrau é número, não nome. Desde então a régua do meio tem duas colunas.

Abri mão de: simplicidade do desenho. Dois degraus eram mais fáceis de explicar, e o terceiro existe porque o negócio da casa pediu, não porque a arquitetura ficou mais bonita.

O que eu aprendi fazendo isso: o degrau já operava há três semanas sem estar escrito, e eu descobri isso lendo o meu próprio registro — uma linha de agosto pedia em nome de um produto que a lei não conhecia, e um defeito daquela mesma semana era uma marca ficando com a arte de outra, porque a chave guardava o nome do arquivo e não a marca. Degrau que não está escrito faz toda pergunta chegar como caso especial, e caso especial ninguém conta.

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

Se um produto não declara uma cor, ele herda a do sistema. Isso é conveniente e perigoso: a tela fica errada e ninguém percebe até alguém olhar.

Então existe um relatório que lista, para cada produto, o que ele declarou e o que herdou sem declarar.

Por quê: o modelo só é seguro se o esquecimento for visível. Sem o relatório, o valor padrão é uma bomba com atraso.

D4 · Extensibilidade por peça aberta, não por gancho de configuração

Quando um produto precisa de um componente que o sistema não tem, ele monta esse componente com as peças do sistema, que são públicas. A estrutura de uma superfície, por exemplo, é dividida em topo, conteúdo e base, e essas três partes podem ser usadas separadamente.

Por quê: configuração escondida é um contrato que ninguém lê. Peça aberta é um contrato visível.

Abri mão de: controle sobre o resultado final de cada produto. Em troca, os produtos param de copiar o sistema para alterá-lo.

D5 · Pronto tem seis lugares, e a verificação olha os seis

Um componente só conta como pronto quando fecha nos seis lugares: a especificação escrita, o código, o catálogo que o time consulta, o arquivo do Figma, a pintura que ele resolve em cada modo, e a volta, que é conseguir ler o desenho do produto e comparar com o que a linguagem manda. A verificação roda por linha de comando e devolve número, não opinião.

Consequência: no CPF Seguro, as 85 peças do contrato fecham os seis lados, e 38 delas foram comparadas com o desenho de verdade. As outras 47 têm um lado que não se aplica, com a razão escrita uma por uma.

O que eu aprendi fazendo isso: o primeiro número que eu publiquei era falso. O programa que contava pulava silenciosamente os casos que não sabia classificar, então o total parecia melhor do que era. Denominador honesto é pré-requisito de qualquer meta.

D6 · Pedido de produto vira arquivo com parecer, não conversa

Quando um produto precisa de algo que a linguagem não tem, ele escreve um pedido num formato fixo. Cada pedido entra num registro com quatro respostas possíveis, o motivo, e a versão em que ele entrou. Hoje esse registro tem 196 linhas.

A regra que ele sustenta é esta: uma variante só sobe para o sistema no segundo pedido. Duas equipes pedindo a mesma coisa é sinal de que falta palavra na linguagem; uma equipe pedindo é sinal de que falta peça no produto dela.

Por quê: sem registro do primeiro pedido, a regra do segundo nunca dispara, e a decisão volta a depender de alguém lembrar. Memória de pessoa não é procedimento.

Abri mão de: velocidade em cada pedido isolado. Escrever o parecer custa mais que responder no chat.

O que isso mudou em mim: está escrito nesse registro uma linha em que um produto provou que eu havia anunciado uma validação que não existia, e o parecer começa reconhecendo isso. O registro serve para me corrigir também, senão ele é teatro.

D7 · A mesma mudança tem que poder ser adotada em qualquer plataforma

Os produtos da casa não são só aplicativos: existe painel de operação e internet banking, que são web. Então a decisão não é "fazer uma versão web do sistema", é mais dura que isso: uma mudança na peça do sistema tem que poder ser adotada em qualquer produto que a use, independente de plataforma, pelo mesmo gesto de adoção que já existe hoje.

Estado medido: as 93 primitivas de cor já saem para web, e viram 162 variáveis de folha de estilo. A camada com que os componentes de fato pintam, as 59 funções, é calculada em Flutter e por isso ainda não existe fora dele. Esse é o furo, e ele está escrito na decisão em vez de descoberto na implementação.

Como eu decidi o tamanho do passo: medi o painel de operação antes de propor prazo. São 3.746 instâncias de componente no arquivo, 2.689 delas visíveis, e a contagem é feita pelo identificador do componente, nunca pelo nome da camada. Contar pelo nome inflava o número em quase 30%.

---

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

O sistema tem 36 ferramentas de linha de comando, e a verificação inteira roda em cinco minutos. Em agosto apareceu a pergunta de repartir isso entre agentes de inteligência artificial para ir mais rápido. Eu cronometrei antes de responder: as quatorze ferramentas do portão levam 15,2 segundos. Repartir quinze segundos não compra nada. O tempo estava no julgamento, e julgamento é serial, porque cada divergência que eu leio muda a pergunta da seguinte.

Então a divisão não é por assunto, é por direito de escrita. Um agente colhe fato e não tem permissão de concluir. Um agente mede um lado e devolve número, e nasce com o defeito construído de propósito: se ele não fica vermelho na frente do defeito, não entra. Um terceiro é o advogado do produto que vai receber a cobrança, e existe para matar a cobrança errada antes de ela sair de casa. Publicar, subir de versão e adotar no aplicativo seguem sendo gesto de pessoa.

Abri mão de: a velocidade que tinham me prometido. O motor continua levando cinco minutos, e eu escrevi isso no documento em vez de vender o contrário.

Consequência: de 88 entregas de código em quatro dias, 11 corrigiam uma medição minha que estava errada, 12,5%. Nenhuma foi pega por mim relendo: todas foram pegas por um portão que constrói o defeito, ou por uma segunda voz perguntando.

07 Craft

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

Onde isso ainda não vale: na aba de componentes o modo troca a moldura e as prévias continuam claras. É um furo do catálogo, não da linguagem, e está aqui escrito porque descobri gravando esta figura.

O que existe hoje, medido na versão 0.175.0:

• 128 peças com contrato escrito, uma por peça, e o contrato viaja dentro do pacote em vez de ficar só no repositório.
• 59 funções de cor nos dois modos, 355 ícones, e 21 grupos de variante gerados a partir da definição em vez de desenhados um por um.
• 516 entradas na lista única de token, que é a mesma cor escrita nas três grafias que o time usa: a do código, a do formato aberto de token e a do Figma.
• Os quatro estados que toda tela precisa resolver, vazio, erro, falha e espera, com a peça certa para cada um, mais as regras de inteligência artificial na interface: marcar, explicar, verificar e autorizar, por nível de risco.
• Os 216 nomes de componente dos dois produtos foram comparados um a um contra os 104 do sistema, e cada um recebeu um parecer. Nenhum ficou sem resposta.
• Existe um produto de teste, feito só para provar o modelo: uma paleta âmbar que depende apenas do sistema, sem nada próprio. Se esse produto nasce barato, o modelo funciona. É o critério de fechamento.
• A verificação rápida, para quem mexe em tela, roda em 16 segundos. A completa, em 2 minutos.
• Além dela, existem testes que comparam a imagem de cada tela, pixel por pixel, com a versão aprovada. É isso que permite afirmar "não mudou um pixel" sem depender da memória de ninguém.

---

08 Resultado

A atualização que ninguém viu. O sistema pulou treze versões de uma vez, com 1.022 arquivos alterados. No aplicativo que consome: as 24 imagens de tela continuaram idênticas, os 2.062 testes passaram, e a análise de código não apontou erro. Nenhum pixel mudou.

Esse é o resultado do sistema, não um efeito colateral. Um design system só circula se atualizar for barato e previsível. Quando não é, o produto congela numa versão antiga e o sistema morre de pé.

Por que esses números, e não outros. Duas coisas matam design system, e as duas têm nome. A primeira: ninguém sabe quanto do produto realmente usa o sistema, então adoção vira sensação. A segunda: ninguém escreveu quem decide o que entra, então o sistema deriva e vira uma biblioteca bonita que cada equipe contorna do seu jeito. Os números daqui são distância em versão e linha de registro justamente por isso. Eu prefiro dizer que um produto está 24 versões atrás do que dizer que tenho 128 componentes: o segundo número não responde nenhuma pergunta de quem paga a conta.

A circulação. 263 versões publicadas, e o pior atraso hoje é de 24 versões, contra as 176 da auditoria de julho. Cada versão tem registro de mudança. O atraso subiu de 18 para 24 desde ontem, e isso está aqui porque número que só aparece quando melhora não é medição, é propaganda: o produto que está para trás tem time próprio e decide quando sobe, e é ele que precisa de uma semana de adoção, não eu de um gráfico.

A verificação. No produto medido, as 85 peças do contrato fecham os seis lados, e 38 delas foram comparadas com o desenho, não só declaradas.

A régua da pintura. Comparando o desenho de um produto com o que a linguagem manda, 33 pares casam exatamente, 29 divergem, e 22 dessas divergências têm leitura campo a campo: qual cor deveria estar ali, qual está. Divergência com endereço é trabalho; divergência sem endereço é opinião.

Marca nova. O custo de entrada de um produto novo é uma lista de 55 cores.

Quem depende disso. Não é só o meu trabalho que passa por aqui. Três produtos consomem a linguagem, dois deles no ar com marcas de empresas diferentes, e o registro de pedidos tem 196 linhas com o produto que pediu, a decisão e a versão em que ela entrou. É a parte do trabalho que continua andando quando eu não estou na sala, e é por isso que ela existe em arquivo e não na minha cabeça.

---

09 O que eu faria diferente

Eu publiquei um número antes de conferir como ele era contado. O programa que media "componentes prontos" ignorava em silêncio os casos que não sabia classificar. O total parecia bom e não era. Hoje eu escrevo o teste do medidor antes de divulgar a medida.

Eu confiei em verificação que media presença, não a pergunta. Existe hoje um arquivo com vinte casos numerados em que uma verificação passou verde sobre um defeito real, ou vermelho sobre coisa que não era. A classe é sempre a mesma: presença é fácil de medir e quase nunca é a pergunta. O primeiro caso é exemplar, a verificação olhava a cor na árvore de componentes quando a pergunta era o pixel, e azul a 18% de opacidade tem outro valor final que azul cheio. Se eu voltasse, escreveria o caso de defeito antes da verificação, para cada uma delas.

Eu escrevi o registro de mudanças depois de precisar dele, não antes. A auditoria achou 176 versões sem uma linha de explicação. Isso não era burocrácia pendente, era a razão pela qual o sistema tinha parado de chegar nos produtos. Documentar o que muda é parte da entrega, não tarefa de depois.

---