Se você usou qualquer ferramenta de IA para gerar UI — Cursor, Claude Code, v0, Bolt, Lovable, Windsurf, seja qual for — você esbarrou nesta parede: a IA gera algo funcional, mas visualmente genérico. Você descreve “um dashboard com as cores da minha marca” e ela devolve uma paleta padrão do Tailwind com botões azuis. Você ajusta tudo manualmente, faz um novo prompt, e o próximo componente sai com uma linguagem visual completamente diferente.
O problema não é a IA. O problema é que sua IA não tem ideia de como se parece seu design system.
Google acabou de fazer open-source a solução. Ela se chama DESIGN.md.
O Que É DESIGN.md
DESIGN.md é uma especificação de formato — um arquivo markdown que descreve sua identidade visual de uma maneira que agentes de codificação IA podem ler, entender e aplicar consistentemente. Nasceu dentro do Google Stitch, o canvas de design nativo de IA do Google Labs, e desde esta semana a spec é open source sob licença Apache 2.0.
O repo: github.com/google-labs-code/design.md
O conceito é simples mas poderoso: combinar design tokens legíveis por máquina (front matter YAML) com lógica de design legível por humanos (prosa markdown). Os tokens dão ao agente valores exatos. A prosa diz por que esses valores existem e como aplicá-los.
Asim é como fica um arquivo DESIGN.md:
---
name: Heritage
colors:
primary: "#1A1C1E"
secondary: "#6C7278"
tertiary: "#B8422E"
neutral: "#F7F5F2"
typography:
h1:
fontFamily: Public Sans
fontSize: 3rem
body-md:
fontFamily: Public Sans
fontSize: 1rem
rounded:
sm: 4px
md: 8px
spacing:
sm: 8px
md: 16px
---
## Overview
Architectural Minimalism meets Journalistic Gravitas. The UI evokes a
premium matte finish — a high-end broadsheet or contemporary gallery.
## Colors
- **Primary (#1A1C1E):** Deep ink for headlines and core text.
- **Tertiary (#B8422E):** "Boston Clay" — the sole driver for interaction.
- **Neutral (#F7F5F2):** Warm limestone foundation, softer than pure white.
Um agente que lê este arquivo produz uma UI com títulos em tinta escura usando Public Sans, um fundo tipo pedra calcária morna, e botões de ação em Boston Clay. Toda vez. Em cada componente que gera.
Este é o desbloqueio: consistência visual sem correção manual em cada prompt.
Por Que Importa Agora
O timing não é coincidência. Estamos em um momento em que as ferramentas de IA geram UI a partir de texto em uma velocidade impressionante — mas cada ferramenta tem seu próprio jeito de entender a intenção de design. Você monta algo no Stitch, quer continuar no Claude Code, e recomeça do zero com a linguagem visual. Você prototipa no v0, muda para Cursor para o código de produção, e gasta uma hora re-explicando sua paleta de cores.
DESIGN.md se propõe a ser o contrato universal entre seu design system e qualquer agente IA que toque seu código. Um arquivo. Você joga na raiz do seu projeto. Todas as ferramentas leem.
O formato é deliberadamente simples: é markdown. Você não precisa de exports do Figma, nem schemas JSON proprietários, nem tooling especial. Markdown é o formato que os LLMs leem melhor — não há nada para fazer parsing ou configurar. E como a lógica de design vive ao lado dos tokens, a IA não apenas sabe que sua cor primária é #1A1C1E — ela sabe que se chama “Deep Ink” e é usada para títulos, não para fundos.
O Fluxo de Trabalho Prático
Asim é como você a usaria na prática:
Opção 1: Comece pelo Stitch. Você projeta sua UI no Google Stitch, e quando termina, exporta o DESIGN.md. Isto lhe dá um arquivo com todos os tokens, funções de cor, tipografia, spacing, e a lógica de design já escrita para que a IA a entenda. Depois você joga no seu projeto de código.
Opção 2: Escreva na mão. Se você já tem um design system ou brand guidelines, você pode escrever o DESIGN.md você mesmo. O front matter YAML cobre tokens (cores, tipografia, spacing, border-radius), e a prosa em markdown descreve a filosofia, os do’s/don’ts, e os padrões de componentes. A spec tem documentação clara sobre o que incluir.
Opção 3: Extraia de um site existente. Já se formou um ecossistema de ferramentas ao redor deste formato. Há uma extensão do Chrome (DESIGN.md Style Extractor do TypeUI) que extrai variáveis CSS e estilos computados de qualquer site e gera um DESIGN.md. Há CLIs como dembrandt que rastreiam uma URL com Playwright e produzem design tokens em formato DESIGN.md. E há um repositório inteiro curado — awesome-design-md — com arquivos DESIGN.md pré-montados modelados a partir do Stripe, Vercel, Linear, Notion, Airbnb, e dezenas de outros design systems conhecidos.
Uma vez que você tem o arquivo, o uso é idêntico em todas as ferramentas:
project/
├── DESIGN.md ← sua spec de design system
├── src/
│ ├── components/
│ └── pages/
└── package.json
Você diz ao seu agente IA: “Construa uma página de settings seguindo o design system em DESIGN.md.” O agente lê o arquivo, aplica os tokens, segue a lógica de design, e gera código que realmente parece sua marca.
Agent Skills: Indo Mais Fundo
Google também mantém uma biblioteca de skills — google-labs-code/stitch-skills — que se complementa com DESIGN.md. Os skills são pequenos conjuntos de instruções que ensinam aos agentes de codificação como realizar workflows específicos. O skill design-md, por exemplo, diz ao seu agente como analisar um projeto do Stitch e gerar um DESIGN.md completo a partir dele.
Eles são instalados assim:
npx skills add google-labs-code/stitch-skills --skill design-md --global
Outros skills da coleção incluem stitch-loop (gera um site multi-página a partir de um único prompt), react:components (converte telas do Stitch em sistemas de componentes React com consistência de design tokens), e enhance-prompt (transforma descrições vagas de UI em prompts detalhados e otimizados para Stitch).
Esses skills seguem o padrão aberto Agent Skills, o que significa que funcionam com Claude Code, Cursor, Windsurf, Gemini CLI e outros agentes compatíveis — não apenas com ferramentas do Google.
E a Acessibilidade?
Um detalhe do post do blog do Google que vale a pena destacar: DESIGN.md não apenas captura tokens visuais — pode codificar intenção de acessibilidade. Em vez de um agente adivinhar se uma combinação de cores atende aos requisitos de contraste WCAG, a spec permite que você declare papéis de cor com seu propósito semântico. O agente pode então validar suas decisões contra regras de acessibilidade antes de gerar código.
Isso é significativo porque a UI gerada por IA tem um problema conhecido de acessibilidade. Quando o agente não conhece o papel intencional de uma cor, não consegue verificar se aquele laranja brilhante sobre fundo branco atende ao contraste AA. Com os papéis semânticos de cor do DESIGN.md, a informação está lá para que o agente faça essa verificação.
O Ecossistema que Já Está se Formando
A spec tem um dia em sua forma open source e já acumula ~1.600 estrelas no GitHub (com um ritmo de crescimento acelerado). Mas o sinal interessante é o ecossistema que está se formando ao redor:
- awesome-design-md — uma coleção curada pela comunidade de arquivos DESIGN.md para marcas populares (Stripe, Binance, Airbnb, Meta, etc.)
- DESIGN.md Style Extractor — uma extensão do Chrome que gera o arquivo a partir de qualquer site que você está navegando
- dembrandt — uma CLI que faz crawl de sites com Playwright e gera DESIGN.md, tokens DTCG e até PDFs de brand guide
- design-md-generator — usa extração com Playwright + Claude Code para a escrita semântica do DESIGN.md
- Shuffle.dev — já suporta export de DESIGN.md a partir de seu UI builder
- MindStudio — publicou um workflow para encadear Stitch → DESIGN.md → Claude Code
Para algo que acaba de ficar open source, essa curva de adoção é notável. Sugere que o formato está atacando uma lacuna real no pipeline de design-para-código que os desenvolvedores vinham resolvendo com soluções ad-hoc.
A Avaliação Honesta
O que funciona bem:
- O formato em si é elegante: YAML para máquinas, markdown para humanos, ambos no mesmo arquivo. Não é necessária nenhuma ferramenta nova.
- Agnóstico de agente por design. Funciona com Claude Code, Cursor, Windsurf, Gemini CLI, Codex — qualquer ferramenta que leia markdown.
- A combinação de tokens exatos + lógica de design é mais inteligente do que apenas tokens. Saber que
#B8422Eé “Boston Clay, o único driver de interação” dá ao agente mais informações do que simplesmenteaccent: #B8422E. - Licença Apache 2.0. Não há lock-in com o ecossistema do Google.
O que observar:
- A spec ainda é um draft. Funciona, mas mudanças estruturais são possíveis conforme mais ferramentas a adotam.
- A geração a partir de sites existentes (via extensões do Chrome ou CLIs) produz aproximações, não documentação oficial de design system. Os valores computed de CSS nem sempre capturam a intenção de design.
- Se isso se tornar um verdadeiro padrão da indústria ou continuar um formato originado pelo Google que outros toleram depende da adoção por Figma, Storybook e do ecossistema mais amplo de ferramentas de design.
- Ainda não há alinhamento com o W3C Design Tokens Community Group. O DTCG tem sua própria spec de formato de tokens. Se DESIGN.md e DTCG convergem ou competem está por se ver.
Como Começar
O caminho mais rápido para testar DESIGN.md:
- Vá ao repo: github.com/google-labs-code/design.md
- Revise a pasta
examples/para arquivos DESIGN.md de exemplo - Copie um como ponto de partida, edite com os tokens da sua marca
- Coloque na raiz do seu projeto
- Na sua ferramenta IA preferida, referencie-o: “Siga o design system em DESIGN.md”
Ou, se quiser extrair a partir de um site existente:
# Usando dembrandt
npx dembrandt seusite.com --design-md
Ou navegue a coleção pré-montada em awesome-design-md para inspiração.
Já está usando DESIGN.md ou algo similar para manter a consistência na sua UI gerada por IA? Qual é sua estratégia para manter coerência visual quando codifica com IA? Conte-nos nos comentários. ![]()
