Eu tinha um sábado marcado para redesenhar três produtos que envio sob marcas diferentes. Site de marketing para um. Telas de aplicativos móveis para outro. Uma apresentação para o terceiro. Três estéticas diferentes. Três públicos diferentes. Três pilhas diferentes. No ano passado, este teria sido um projeto de quatro semanas. No mês passado, com Claude Code e uma pilha de habilidades, foram três dias de trabalho árduo. Esta semana fiz isso antes do almoço.
O que mudou foi um único arquivo. Seiscentas e doze linhas de redução na raiz de cada projeto. Um nome que eu via aparecer no meu feed do Twitter há semanas, mas não me preocupei em usar. DESIGN.md. Ou, dependendo da transcrição que você lê, design.mmd. Mesmo arquivo. Teclas diferentes no mesmo instrumento.
Eu estava errado sobre isso por quase um mês. Achei que fosse outro YAML de token de design envolto em um ciclo de hype. Achei "ótimo, outra especificação para memorizar, outro padrão para abandonar quando o próximo for lançado em seis semanas". Sentei-me sobre as mãos e observei as estrelas GitHub subirem. O repositório oficial google-labs-code/design.md ultrapassou 10.000 estrelas oito dias depois que Google abriu o código-fonte da especificação em 21 de abril de 2026. A coleção VoltAgent/awesome-design-md dirigida pela comunidade ultrapassou 68.000 na mesma janela e agora está em algum lugar ao norte de 71k nesta semana. Números assim, em um mercado tão saturado, não acontecem para um arquivo YAML.
O que perdi foi que DESIGN.md não é realmente um formato de arquivo. É um protocolo. Uma maneira de ensinar sua marca a um estranho aproximadamente no tempo que leva para servir um café, onde o estranho é todo agente de codificação que você usará. Uma vez clicado, todo o meu fluxo de trabalho de design AI foi reestruturado em torno dele. Este artigo é a versão da explicação que gostaria que alguém tivesse me dado quatro semanas antes.
Deixe-me mostrar o que realmente acontece quando você para de lutar contra isso.
Por que "Just Prompt The Model" deixou de ser suficiente
Aqui está o modo de falha que cada edifício de designer com AI em 2026 atingiu pelo menos uma vez.
Você inicia um novo projeto. Você solicita Claude Code ou Cursor ou Codex com algo razoável: "construa para mim uma seção principal do painel para um aplicativo fintech, moderno e limpo." O modelo vai funcionar. Produz algo. O que ele produz está bom. Na verdade, é mais do que bom - é tecnicamente correto, usa padrões razoáveis, o espaçamento é uniforme, a escala tipográfica faz sentido. E ainda assim você dá uma olhada e já consegue sentir a sujeira.
Você não pode colocar o dedo nisso por um segundo. Então você pode. A sombra está errada. Não é errado no sentido de quebrado - errado no sentido de que todos os outros painéis gerados por AI na Internet têm exatamente essa sombra. O azul é o mesmo azul que Vercel usa, que é o mesmo design antigo do Stripe azul usado, que é o mesmo azul que todos os sites de marketing da empresa YC usaram em 2024. Você está olhando para uma média estatística vestindo uma fantasia de marca.
É sobre isso que ninguém avisa quando lhe vendem ferramentas de design AI. O modelo não está tomando uma decisão criativa. Está na média. Ele está calculando a média do seu prompt vago em relação a todas as outras interfaces que seus dados de treinamento já mostraram, e o resultado chega diretamente ao topo da mediana. Mediana UI. Espaçamento mediano. Marca mediana. A razão pela qual parece genérico é porque é.
Os designers vêm denunciando exatamente esse problema há quase um ano. Existe um termo circulando agora - "Claude slop", "Cursor slop", escolha seu modelo - e é mais feio do que o design em si. Diz uma coisa verdadeira: o gargalo não é mais o modelo. O gargalo é se o modelo tem alguma ideia de como deve ser o seu gosto.
Essa é a lacuna que o DESIGN.md preenche. Não por ser mais inteligente que o modelo. Por ser um contrato, o modelo pode realmente seguir.
Entraremos no formato em si em um momento. Mas primeiro preciso contar a vocês sobre o momento em que parei de ser cético.
A primeira vez que vi realmente funcionar
Eu tinha um site de marketing para um produto secundário. Vibração de fundador solo - uma daquelas páginas de destino minimalistas com um herói, três blocos de recursos, prova social, preços, perguntas frequentes. Eu tinha a marca esboçada em Figma mas ainda não havia implementado nada. Eu estava prestes a fazer o que sempre faço: codificar manualmente a primeira passagem e depois entregá-la a Claude Code para refinamento.
Em vez disso, tentei o caminho DESIGN.md. Escrevi um arquivo de 412 linhas descrevendo cada decisão de marca em inglês simples. Tokens coloridos com uma frase quando aplicados. Escala tipográfica com a justificativa de cada etapa. Sistema de espaçamento vinculado a uma base de 4px. Voz e tom. Uma seção dedicada aos “Antipadrões” listando os oito erros que qualquer agente nunca deve cometer neste projeto. Soltei o arquivo na raiz do projeto. Então abri Claude Code e digitei exatamente isto:
Leia DESIGN.md. Em seguida, crie uma landing page de marketing usando apenas os tokens, componentes e regras lá definidos. Hero, três blocos de recursos, faixa de prova social, preços, perguntas frequentes.
O que voltou quarenta e cinco segundos depois não foi um rascunho. Foi a página. Pixel próximo ao que esbocei em Figma sem nunca abrir Figma. O herói usou meu título com serifa personalizado no tamanho certo. O cartão de preços usava meu estilo de superfície "elevado" - o certo, não o modal - porque eu havia descrito no arquivo quando cada superfície foi aplicada. O estado de foco do botão foi a mudança de tom correta, com o tempo de transição correto, porque esse tempo existia na seção de movimento.
Fiquei lá por cerca de trinta segundos processando. Então tentei quebrá-lo. Pedi para adicionar uma seção de depoimentos. Ele usou o estilo de cartão certo. Pedi uma tabela comparativa com três concorrentes. Ele escolheu a variante certa de densidade de mesa. Eu pedi um modo escuro. Ele reaplicou cada token corretamente, sem que eu precisasse lembrá-lo dos planos de fundo coloridos da marca que defini para o conteúdo promovido.
A coisa toda levou quarenta minutos. O arquivo DESIGN.md levou cerca de três horas para ser escrito corretamente. Quarenta minutos para a página. Três horas para o arquivo que agora gera infinitas páginas consistentes. Essa matemática é o ponto principal.
Desde então, enviei esse fluxo de trabalho em quatro produtos separados, cada um com seu próprio DESIGN.md. A composição fica ridícula após o segundo projeto. No projeto três, eu tinha um modelo que copiei, colei e modifiquei e o arquivo fica pronto em vinte minutos.
Mas nada disso funciona se o arquivo estiver desleixado. Então deixe-me mostrar o que o arquivo realmente contém.
O que há dentro de um arquivo DESIGN.md, seção por seção
O formato Google de código aberto possui uma estrutura específica. Não é um ensaio de formato livre. A especificação atual define um corpo de marcação com seções predefinidas, material YAML opcional na parte superior para tokens legíveis por máquina e uma regra de ordenação estrita - as seções podem ser omitidas, mas as presentes devem aparecer na ordem das especificações.
Aqui estão as nove seções exigidas pelas especificações, com a forma como eu realmente uso cada uma delas:
1. Versão e Nome. Duas linhas. A tag de versão é atualmente alpha e existe para que as ferramentas futuras saibam qual edição de especificação o arquivo está direcionado. O nome é o nome do projeto. Você pensará que isso são metadados descartáveis. Não é. Quando você bifurca um DESIGN.md de um projeto irmão e se esquece de renomeá-lo, todos os agentes em sua cadeia de ferramentas acabam construindo com segurança o "AcmeBank" UI para uma marca de bem-estar. Eu observei isso acontecer.
2. Descrição. Um único parágrafo descrevendo o posicionamento e a personalidade do produto. Esta é a seção da “alma” sobre a qual a comunidade fonte continua falando. O meu parece mais um briefing criativo do que uma especificação - três frases sobre a quem se destina o produto, duas frases sobre que sentimento ele deve produzir, uma frase listando o que absolutamente não é. O modelo usa isso para romper laços em todas as decisões ambíguas a jusante. Se você pular esta seção, espere algo sem graça.
3. Visão geral. Um parágrafo de aparência holística. Onde a descrição é sobre posicionamento, a visão geral é sobre caráter visual. Este produto é quente ou frio? Denso ou arejado? Alto ou contido? Editorial ou utilitário? Esta é a seção onde vive o seu gosto na forma de linguagem. Eu mantenho o meu específico: "Silencioso editorial. Neutros quentes, uso de sotaque contido, espaços em branco generosos. As manchetes fazem o trabalho pesado; o texto de apoio recua. Sem gradientes no primeiro plano. Sem efeitos de vidro. Sem movimento gratuito."
4. Cores. Valores hexadecimais mapeados para nomes semânticos. O truque que levei três projetos para aprender: não nomeie as cores de acordo com sua aparência. Nomeie-os de acordo com seu trabalho. surface-base e não gray-50. action-primary e não indigo-600. status-warning-subtle e não amber-100. Cada token recebe uma descrição de uma frase de quando usá-lo. As descrições são o que impedem o modelo de pegar o azul errado às 2 da manhã.
5. Tipografia. Famílias de fontes, escala, pesos, alturas de linha, espaçamento entre letras. Doze a quinze tokens é o normal. O meu tem treze - display, título-xl, título-l, título-m, título-s, corpo-l, corpo, corpo-s, legenda, código, botão, rótulo, sobrancelha. Cada um com regras explícitas sobre onde aparece.
6. Layout. Grades, pontos de interrupção, escala de espaçamento base. Quer você use 4px ou 8px como unidade. Quão densa é sua página típica. Quer suas calhas aumentem com ponto de interrupção ou permaneçam fixas. É aqui que você codifica o ritmo da marca.
7. Elevação e Profundidade. Sombras, camadas de índice z, as regras de estratificação visual do sistema. Esta é a seção que a maioria das equipes esquece que existe. É mais importante do que você pensa - metade do desperdício que você vê no UI gerado por AI vem do modelo que escolhe valores de sombra das médias dos dados de treinamento. Se o seu arquivo não especificar a elevação, o modelo irá adivinhar e a estimativa será semelhante a qualquer outro painel gerado.
8. Componentes. Padrões para botões, cartões, formulários, navegação, com todas as variantes e estados. É aqui que o arquivo fica longo. Para um projeto sério, descrevo cerca de quinze a vinte componentes primitivos, cada um com seus adereços e a regra de uso para cada variante.
9. O que fazer e o que não fazer. Regras explícitas. "Nunca use cinza bruto para o corpo do texto - sempre use um token de conteúdo." "Nunca anime mais de 240 ms no primeiro plano UI." "Evite imagens sem margens no site de marketing; em vez disso, use o componente de mídia emoldurada." Esta seção é sua última linha de defesa contra a média. O modelo trata essas restrições como restrições rígidas. Quanto mais você tem, mais sua marca sobrevive.
Essa é a estrutura. As especificações completas estão documentadas no repositório google-labs-code/design.md e são fáceis de ler de ponta a ponta em cerca de vinte minutos – muito menos tempo do que você gastou lutando contra resultados ruins.
Há mais uma coisa que as especificações sugerem, mas não abordam totalmente, e é onde muitas pessoas ficam presas. Deixe-me mostrar o que tive que descobrir da maneira mais difícil.
A tensão tokens versus prosa sobre a qual ninguém avisa
Aqui está a parte do DESIGN.md que demorei mais para internalizar. O formato tem duas vozes. O YAML no topo é para máquinas. A prosa abaixo é para humanos e modelos de linguagem. Você precisa de ambos e precisa que eles concordem.
A maioria das equipes erra em uma das duas direções.
O primeiro modo de falha: muito YAML, pouca prosa. Seu arquivo se parece com uma configuração do Tailwind. Cada token tem um nome e um valor. Não há descrição circundante. O modelo lê o arquivo, trata os tokens como dados brutos e acaba cometendo os mesmos erros de média que teria cometido sem nenhum arquivo. Os tokens são o quê. Sem o quando, o modelo ainda está adivinhando.
O segundo modo de fracasso: muita prosa, falta de fichas. Seu arquivo parece um PDF do brand book. Lindas frases sobre a alma do produto. Nenhum valor legível por máquina. O modelo capta a vibração, mas não consegue definir qual código hexadecimal exato está em um botão primário. Você acaba com uma saída que parece correta e quebra todas as verificações de acessibilidade.
O truque é o casamento. Tokens com frases. Frases que resolvem em tokens. Cada valor tem uma descrição de trabalho. Cada descrição de trabalho aponta para um valor.
Eu escrevo os meus em tabelas. Aqui está uma parte real dos meus tokens de superfície, retirados de um dos meus projetos ao vivo com os detalhes da marca trocados:
| Token | Hex | Dark | When to use |
|--------------------|----------|----------|-------------------------------------------------|
| surface-base | #FAF9F6 | #0E0E10 | The page background. Nothing sits behind this. |
| surface-raised | #FFFFFF | #161618 | Cards, list rows — one layer above base. |
| surface-elevated | #FFFFFF | #1C1C20 | Modals, popovers, menus. Floating UI only. |
| surface-sunken | #F2F1ED | #08080A | Input fields, inset wells, read-only regions. |
| surface-brand | #F4EFE8 | #221C12 | Brand-tinted backgrounds for promoted content. |
Essa quarta coluna é o que faz o arquivo funcionar. Um modelo que lê "usar superfície elevada apenas para UI flutuante" nunca pode usá-lo acidentalmente para um plano de fundo de página. O token é um valor. A sentença é a restrição. Juntos eles são uma instrução.
Este padrão se alinha com as recomendações do W3C Design Token Community Group, as referências de especificação Google e mapeia claramente para as ferramentas existentes - exportações style-dictionary, plug-in de tokens de design do Tailwind, o formato de exportação DTCG que reside no design.md CLI. Nada disso é novo. A novidade é ter um único arquivo canônico onde os tokens e a lógica convivem, controlados por versão, ingeridos por cada agente de codificação que toca no projeto.
Se você leu meu artigo anterior sobre o fluxo de trabalho do sistema de design AI com Claude e Figma MCP, você já viu o padrão de token de quatro colunas. DESIGN.md é o formato que finalmente o padroniza. O formato que eu estava procurando é o formato que Google acabou sendo enviado.
Até agora falamos sobre o arquivo. Agora deixe-me falar sobre a parte que transforma a lima em um fosso.
Habilidades, pacotes de remix e a combinação de sabores
A inovação não foi apenas o DESIGN.md. A inovação foi o DESIGN.md mais a camada que cresceu sobre ele quarenta e cinco dias após a queda das especificações.
A comunidade mudou rapidamente. No início de maio de 2026, três coisas entraram em produção:
A incrível coleção de design-md. Um repositório com curadoria da comunidade em VoltAgent/awesome-design-md que envia mais de cinquenta arquivos DESIGN.md extraídos de marcas do mundo real — Stripe, Vercel, Notion, Supabase, Linear, NVIDIA, Apple, x.ai. A coleção passou de zero para 35 mil estrelas em dez dias, depois para 68 mil no final de abril e depois passou de 71 mil. A proporção do fork está acima de 12%, o que é incrível – para fins de contexto, o awesome-go está em 7,8%, o awesome-python está em 9,5%. As pessoas não estão apenas marcando esses arquivos como favoritos. Eles os estão puxando para projetos.
A integração do Claude Design. Quando o Anthropic lançou o Claude Design em 17 de abril de 2026 – quatro dias antes do Google abrir o código-fonte do formato – ele obteve profunda compatibilidade com o DESIGN.md. Você pode inserir um arquivo DESIGN.md no Claude Design e obter um andaime UI completo em uma única tentativa. Tokens, escala de tipo, botões, cartões, navegação, kit de visualização funcional. Abordei a primeira olhada em [minha análise do design Claude] (/claude-design-anthropic-first-look) - a integração com DESIGN.md é a parte que envelheceu melhor.
Remixagem baseada em habilidade. É aqui que as coisas ficam interessantes. A comunidade começou a distribuir “habilidades” – pequenos plug-ins de markdown focados que são colocados em cima de um DESIGN.md para empurrá-lo em uma direção específica. Tratamentos de superfície skeuomórficos. Efeitos de destaque estilo laser. Regras de composição editorial-impressa. Padrões de interação 3D baseados em WebGL. No início de Maio, havia mais de sessenta competências públicas disponíveis e o número aumenta semanalmente.
O fluxo de trabalho resultante é algo ao qual ainda estou me adaptando. Você escreve sua base DESIGN.md uma vez. Você aplica habilidades como sobreposições. As habilidades não substituem seus tokens — elas os estendem, adicionando camadas modulares que o agente pode compor com sua base. Você escolhe duas famílias estéticas que não deveriam funcionar juntas. Você deixa o modelo remixá-los por meio da camada de habilidade. Você itera no resultado.
Este é o ciclo que a comunidade fonte descreve como “iteração vs. remix”. Iteração é o refinamento lento de uma única direção de design – mover um botão dois pixels, apertar um trapo de parágrafo, ajustar um estado de foco. Remix está criando uma direção totalmente nova, combinando dois arquivos DESIGN.md não relacionados ou colocando uma habilidade em camadas sobre uma já existente. Ambos são importantes. A iteração produz polimento. Remix produz novas categorias.
Aqui está o que ninguém conta no texto de marketing. Produtos maduros estão executando milhares de iterações. Não estou exagerando. As equipes com quem conversei que usam essa pilha seriamente estão relatando de 4.000 a 10.000 iterações orientadas por prompt por área de superfície polida antes de serem enviadas. O custo é real – em termos de token, de tempo e de atenção. O resultado, quando bem feito, é o tipo de qualidade de design que você costumava precisar de um estúdio de seis pessoas para produzir.
Se isso parece caro, é. Se parece mais lento do que colocar um modelo em um projeto, também é isso. O que mudou foi o teto. Com um DESIGN.md e uma biblioteca de habilidades sensata, um operador solo agora pode atingir a qualidade do design de produção em tantos produtos quanto seu julgamento puder sustentar.
Qual é a verdadeira conversa. Deixe-me começar.
Gosto é o novo fosso - e quase ninguém acredita ainda
Se você é um designer que está lendo isto e está nervoso com seu trabalho, quero lhe apresentar a versão do futuro em que realmente acredito.
O envio de pixels desapareceu. O trabalho exaustivo de documentação – cada token descrito, cada variante de componente catalogada, cada estado elaborado à mão – esse trabalho agora é um custo único pago em um arquivo de descontos. O item de linha “20 horas de manutenção do sistema de design por semana”, que costumava estar no roteiro de cada equipe de produto, está caindo para zero. Equipes reais estão relatando reduções de 60 a 80 por cento na manutenção do sistema de design no primeiro trimestre após a adoção adequada do DESIGN.md.
O que não desaparece – o que se torna mais valioso, e não menos – é o julgamento que decide o que deveria estar no arquivo em primeiro lugar.
O DESIGN.md que você escreve é o ideal. É o fosso. O arquivo de 412 linhas na raiz do meu projeto de marketing? Esse arquivo é a marca do produto. Cada variação, cada página, cada e-mail, cada tela que o modelo gera rastreia isso. O arquivo está a montante de tudo. E o arquivo é exatamente tão bom quanto o gosto de quem o escreveu.
Esta é a parte que ainda não está chegando para a maioria das pessoas. Eles olham para o design do AI e veem a democratização – qualquer um pode enviar um UI polido agora. Essa parte é verdade. Mas a democratização é um nivelador na parte inferior da curva, não no topo. A parte inferior da curva fica dramaticamente melhor. O topo da curva também fica melhor, mais rápido e se mantém diferenciado, porque as pessoas no topo são aquelas cujo gosto está informado o suficiente para escrever um DESIGN.md que produza algo que a mediana não consegue.
O futuro do trabalho de design, conforme leio dentro do fluxo de trabalho, é aproximadamente este:
Mais julgamento por minuto. Você gastará menos tempo empurrando pixels e mais tempo decidindo o que deveria existir. A unidade de trabalho muda de “produzir” para “decidir”.
Saturação de referências como uma prática real. Você precisa de um segundo cérebro para projetar. Uma biblioteca de referências – capturas de tela, filmes, páginas de revistas, embalagens, estudos de movimento – que você realmente internalizou, não apenas marcou. Os agentes farão a síntese. Seu trabalho é saber o que vale a pena sintetizar em primeiro lugar.
Gosto de nicho autêntico em vez de domínio genérico. Um designer com gosto profundo em uma estética específica - Y2K, suíço, minimalismo japonês, web brutalista, Memphis, editorial - superará um generalista usando as mesmas ferramentas. Os agentes tendem para a média. O DESIGN.md que você escreve é o que os afasta dele.
Operadores individuais que executam vários produtos. Conheço três pessoas que agora administram de quatro a sete produtos em paralelo como fundadores individuais, cada um com seu próprio DESIGN.md, cada um com sua própria marca. Nenhum deles estava fazendo isso há dois anos. O gargalo costumava ser a produção. O gargalo agora é o gerenciamento de portfólio.
Marketing como uma extensão do julgamento de design. Quando o arquivo gera páginas de destino, criativos de anúncios, cartões sociais, apresentações de argumentos de venda, todos a partir da mesma fonte de verdade - a linha entre "projetar o produto" e "comercializar o produto" entra em colapso. O mesmo gosto que escreveu o DESIGN.md é o gosto que molda cada ponto de contato com o cliente.
Quero ser honesto sobre a parte sobre a qual ainda estou errado. Ainda não sei se as agências vão se adaptar. Ainda não sei se a educação em design irá recuperar o atraso. Ainda não sei se a especificação em si será válida - a especificação do Google está em alpha e já existem pelo menos três formatos concorrentes no ecossistema (a variante do Anthropic, a versão da equipe do Cursor, algumas das primeiras alternativas locais de BYOK). Um deles provavelmente se consolidará. Eu apostaria, hoje, nos Google, porque o impulso do código aberto e a liderança em ferramentas estão muito à frente para que um fork os alcance. Mas já me enganei sobre esse tipo de aposta.
O que não estou errado é a direção. Se você está gastando seu tempo empurrando pixels manualmente em 2026, você está fazendo o trabalho que os arquivos markdown agora fazem de graça.
Como realmente começar, sem queimar um fim de semana
Quero deixar para vocês a versão de “primeiros passos” que gostaria que alguém tivesse me entregado há um mês. Pule os longos tutoriais de integração. Aqui está o que fazer esta semana.
Primeiro dia, noite. Escolha o menor projeto ao vivo que você tem. Site de marketing. Produto secundário. Até mesmo uma única página de destino. Leia três arquivos DESIGN.md reais de VoltAgent/awesome-design-md - Linear, Stripe e um cuja estética realmente corresponda à sua. Leia-os com atenção. O formato ficará óbvio em cerca de vinte minutos.
Segundo dia. Escreva seu próprio DESIGN.md do zero, à mão, em um editor de texto simples. Não use um gerador. O objetivo do arquivo é que ele força você a tornar explícitas as decisões de nível de gosto. Um gerador esconde essas decisões. Apontar para 300 a 600 linhas. Gaste mais tempo nas seções Descrição, Visão geral e O que fazer e o que não fazer. Estas são as seções que o modelo usa para desempate.
Dia três. Coloque o arquivo na raiz do seu projeto. Abra Claude Code, Cursor, Codex ou qualquer agente que você esteja usando. Diga-lhe para ler DESIGN.md e reconstruir uma única página ou componente usando apenas os tokens e regras lá definidos. Observe o que volta. Observe onde as coisas estão erradas - esses erros apontam para lacunas em seu arquivo, não no modelo.
Quatro dias em diante. Itere no arquivo. Cada vez que o agente errar algo de uma forma que você não esperava, pergunte por quê. Quase sempre a resposta é que seu arquivo não especificou isso. Adicione a regra. O arquivo fica melhor a cada correção. Dentro de duas semanas de uso regular, ele se estabiliza — nesse ponto, a produção do agente começa a parecer distintamente sua, e não genérica.
Se você deseja uma rampa de acesso mais rápida, o site getdesign.md lista guias de instalação para Claude Code, Cursor, Kiro, Windsurf e Stitch. A especificação oficial está em github.com/google-labs-code/design.md. A CLI para validação, comparação e exportação para Tailwind ou DTCG reside no mesmo repositório. Nada disso está protegido por um acesso pago. A especificação é Apache 2.0. Os arquivos da comunidade são de código aberto. A camada de habilidades é quase toda gratuita.
Tenho uma confissão para te deixar. No sábado que descrevi no início deste artigo - os três produtos em três horas - eu já estava trabalhando a partir de três meses com esse formato. A primeira vez que tentei escrever um DESIGN.md demorei uma tarde inteira e o resultado foi medíocre. O segundo demorou três horas e foi utilizável. O quinto durou vinte minutos e foi excelente.
O formato é simples. O sabor necessário para enchê-lo bem não é. Essa é a parte que não se democratiza. Essa é a parte que se torna mais valiosa, e não menos, quanto melhores esses agentes se tornam.
Escreva seu arquivo. Sem pressa. A próxima década de trabalho de design será posterior à redução que você escreverá esta semana.
Perguntas frequentes
Qual é a diferença entre DESIGN.md e design.mmd?
Eles se referem ao mesmo formato. DESIGN.md é o nome de arquivo canônico Google enviado na especificação em github.com/google-labs-code/design.md. A grafia design.mmd aparece em alguns vídeos e artigos da comunidade como uma transcrição alternativa. O conteúdo do arquivo é idêntico - corpo de marcação com assunto inicial do token YAML opcional, seções na ordem das especificações. Use DESIGN.md para compatibilidade com as ferramentas oficiais.
Preciso de um designer para escrever um arquivo DESIGN.md?
Não, mas você precisa de gosto. O arquivo força cada decisão de marca a uma linguagem explícita – lógica de cores, hierarquia tipográfica, lógica de espaçamento, regras de uso de componentes. Se você não puder responder a essas perguntas sozinho, o arquivo que você escrever produzirá uma saída genérica, independentemente de qual agente o lê. Um não designer com gosto forte e saturação de referência vencerá um designer que copia um modelo. Veja a seção "Taste Is The New Moat" acima para o argumento completo.
Quais agentes AI suportam atualmente DESIGN.md?
Claude Code, Cursor, GitHub Copilot, Codex, Gemini CLI, Kiro, Windsurf e Anthropic do Claude Design, todos leem DESIGN.md nativamente. A maioria lê o arquivo como uma marcação simples – nenhum plugin é necessário. A ferramenta Google Stitch era a proprietária do formato original e ainda possui a integração mais profunda. Alguns agentes também oferecem suporte à exportação de token YAML opcional gerada pela CLI design.md.
Quanto tempo leva para escrever um DESIGN.md utilizável?
Três a seis horas para uma primeira versão séria de um projeto real. Vinte a quarenta minutos para projetos subsequentes, uma vez que você tenha seu próprio modelo. As seções Descrição, Visão Geral e O que fazer e o que não fazer levam mais tempo e são as partes de maior aproveitamento do arquivo – invista nelas antes de ficar obcecado com a contagem de tokens.
DESIGN.md substituirá Figma?
Não. DESIGN.md substitui o documento de transferência entre design e código e a camada de dados de treinamento entre sua marca e um agente. Figma continua sendo o local para exploração visual, prototipagem de movimento e revisão de design. O padrão para o qual a maioria das equipes está convergindo em maio de 2026: explorar em Figma, codificar em DESIGN.md, criar scaffold com um agente, refinar o código. O arquivo é a fonte da verdade que viaja entre todas as ferramentas.
Vamos trabalhar juntos
Procurando construir sistemas AI, automatizar fluxos de trabalho ou dimensionar sua infraestrutura tecnológica? Eu adoraria ajudar.
- Fiverr (compilações e integrações personalizadas): fiverr.com/s/EgxYmWD
- Portfólio: mejba.me
- Ramlit Limited (soluções empresariais): ramlit.com
- ColorPark (design e marca): colorpark.io
- xCyberSecurity (serviços de segurança): xcybersecurity.io
