[🤖] O design do resultado mudava sempre: por que eu precisava do DESIGN.md

✨ Resumo do GPT-5.6 Sol

O folder saía diferente a cada vez e isso me levou ao DESIGN.md, mas eu já sentia havia muito tempo a necessidade de consistência visual e a aplicava do meu jeito em outros projetos pessoais. Este é o registro de como conectei esses critérios dispersos em um formato que a IA pode consultar continuamente.

O design mudava toda vez que eu fazia um folder

Depois de voltar de um feriado prolongado, continuei o trabalho de produção de um folder na empresa atual. Depois de administrar coordenador e workers até não conseguir terminar o folder no prazo, simplifiquei a forma de trabalhar, mas o design ainda me incomodava. Mesmo dentro do mesmo PPT, o clima mudava de uma página para outra, e cada nova versão parecia gerar um design diferente.

Nos outros projetos não era muito diferente. Tentei criar consistência fazendo a IA buscar referências e bons exemplos de design ou compartilhando-os pessoalmente. Às vezes, eu simplesmente torcia para que a rodada aleatória da gacha desse um bom resultado. O que voltou foi apenas uma gacha de categoria D, sem consistência e transbordando cheiro de IA.

Eu não queria gerar uma tela mais ou menos bonita a cada vez. Queria que as mesmas cores, a mesma hierarquia tipográfica, os mesmos espaços e a mesma sensibilidade dos componentes continuassem na próxima página e na próxima versão. Mas o folder não tinha esse padrão. Sempre que recebia uma referência, a IA voltava a adivinhar o clima desde o início.

Não era a primeira vez que eu via esse problema

Olhando para trás, não foi desta vez que senti pela primeira vez a necessidade de consistência no design. Em julho de 2025, eu já havia escrito sobre como criar um sistema de design para vibe coding. Na época, eu já pensava em um fluxo de desenhar com Figma AI, salvar telas e código como referências, organizar tipografia e paleta de cores e depois comparar tudo com o resultado real.

No Tadak Bible, eu também não parei na ideia. A partir de janeiro de 2026, comecei a reunir cores, tipografia e temas em um só lugar. Documentei direções como azul pastel e lavanda, uma atmosfera calma e acolhedora e a legibilidade da tela de digitação da Bíblia. Depois criei BibleColors, BibleTypography e tokens de espaçamento, cantos, ícones e movimento, aplicando-os em várias telas. Também acrescentei verificações para impedir que novas telas voltassem a inventar cores e tamanhos de fonte arbitrários.

Ou seja, eu já sabia por que um sistema de design era necessário. Dentro do Tadak Bible, eu havia avançado bastante na direção de unir cores, fontes e componentes compartilhados do produto por meio de código e documentação.

O problema era que essa experiência não chegava aos outros projetos e resultados. Os padrões do Tadak Bible estavam espalhados entre seus documentos, o código Flutter e as verificações. Não havia um formato comum que uma IA, ao iniciar um novo projeto web ou PPT, pudesse ler imediatamente e usar para manter a mesma sensibilidade. Em cada projeto, eu buscava referências de novo, jogava novos exemplos e voltava a esperar um bom resultado.

Tentei conectar os critérios dispersos com DESIGN.md

Foi então que encontrei o catálogo ko/design.md, que organiza sistemas de design de serviços coreanos como contexto para LLM,¹ e o repositório DESIGN.md do Google Labs Code.²

Pelo nome e pelos exemplos, tive uma noção geral do tipo de arquivo. Parecia um lugar para registrar cores, fontes, espaços, componentes e a atmosfera geral, permitindo que a IA os consultasse sempre que criasse um design. Pensei que poderia transferir os padrões que já vinha construindo no Tadak Bible para uma forma que um Agent pudesse ler continuamente e administrar outros projetos da mesma maneira.

O problema é que, aqui também, passei por cima dos detalhes. Pedi à IA que descobrisse o que era DESIGN.md, estudasse os exemplos e criasse algo parecido. Depois simplesmente segui em frente, supondo que ela tivesse pesquisado e aplicado o suficiente. Não conferi pessoalmente o escopo descrito pela documentação oficial, se o arquivo criado respeitava esse escopo nem se o resultado real havia se tornado visualmente consistente.

O fato de a IA ler um link e produzir um arquivo convincente não era a mesma coisa que eu ter o padrão de design que queria. Não verificar essa diferença foi erro meu.

Quase coloquei todo o planejamento do produto dentro do DESIGN.md

Sem verificar corretamente o escopo do DESIGN.md, tentei organizar nele todas as telas e os fluxos por usuário, estados, permissões e recuperação do próximo planejamento de produto. O Codex ampliou minhas palavras como estavam e começou a criar arquivos DESIGN.md por função e regras separadas.

Algo parecia errado. A UI não estava sendo tratada de verdade, então pedi novamente que começasse verificando o exemplo do Google Labs Code que eu havia indicado como o mais importante.

Depois de ler o material original, a fronteira ficou muito mais clara. O DESIGN.md do Google Labs Code é um formato que comunica continuamente a identidade visual de um produto a um Agent de programação. O YAML pode conter tokens de design precisos, enquanto o corpo em Markdown explica por que aquelas cores, fontes e formas são usadas e como o design geral deve parecer, ser sentido e se comportar.³

A palavra comportar-se não significava absorver todo o planejamento do produto. Funções de usuário, jornadas, permissões, exceções, recuperação, estrutura de telas e verificação ainda precisavam ser detalhadas na documentação normal do produto. Os detalhes por função que eu havia tentado criar não eram conteúdo descartável; apenas pertenciam ao docs/, e não ao nome DESIGN.md.

Seguir o formato não é copiar o design

Depois de corrigir essa fronteira, havia mais uma coisa a verificar. Usar o Google Labs Code como referência não significava copiar o design de exemplo do repositório e aplicá-lo a todos os projetos.

O Google forneceu o formato DESIGN.md e uma maneira de interpretá-lo, não o conteúdo do design. As cores, fontes e atmosferas dos exemplos pertencem apenas à identidade visual daqueles exemplos. O DESIGN.md de um projeto real deve conter critérios visuais derivados de seus usuários, ambiente, marca e das referências que eu escolher. O catálogo ko/design.md também é material de consulta e comparação; copiar qualquer design não o transforma automaticamente na identidade do nosso produto.

Por isso, corrigi as regras comuns e o Skill de planejamento de produto. Um DESIGN.md seria criado apenas quando a identidade visual realmente fizesse parte do escopo, enquanto funções, jornadas, permissões, recuperação e design detalhado de telas permaneceriam na documentação normal do produto. Removi a direção de DESIGN.md por função que eu havia inventado no começo, e o modelo final passou pela validação oficial do Google.

Desta vez, encontrei o DESIGN.md para reduzir a gacha de design, mas também entreguei o próprio significado do DESIGN.md à gacha da IA. Se eu fornecer um link, disser “pesquise e aplique” e confiar no resultado só porque um arquivo apareceu, a IA preencherá à sua maneira todos os espaços que eu não conferi.

Um arquivo DESIGN.md não produz automaticamente um bom design. Em um PPT, especialmente, ainda é preciso criar mestres de slides e exemplos de layout reais e conferir se o resultado renderizado segue esses padrões. Mas, se eu deixar no DESIGN.md a fonte canônica dos critérios visuais que aceitei para cada produto, pelo menos a IA terá menos oportunidades de sortear novamente a atmosfera a partir de uma tela em branco.

Eu já entendia havia muito tempo a necessidade de consistência visual. No Tadak Bible, já estava construindo um sistema de design. Só agora encontrei um formato legível por um Agent que podia levar essa experiência a outros projetos e resultados, e finalmente o conectei ao nome DESIGN.md.

Referências

1. ko/design.md, catálogo de sistemas de design de serviços coreanos. Ele oferece os designs característicos de serviços coreanos como contexto para LLM. ↩

2. Google Labs Code, DESIGN.md. Apresenta um formato de identidade visual que Agents de programação podem consultar continuamente. ↩

3. Google Labs Code, especificação do DESIGN.md. Define a estrutura, as seções padrão e as regras de validação para tokens de design em YAML e justificativas em Markdown. ↩