Frontend design com Claude: como revisar o resultado visual sem abrir o Figma

Fala aí, beleza? A tela que o Claude te entregou parece boa no código, mas ninguém no time consegue dizer se ela está boa DE VERDADE

E aí acontece o de sempre: alguém olha o print, fala "ficou legal" e o PR passa

Aqui o assunto é julgar o resultado: um roteiro de revisão visual com critério objetivo (as regras do WCAG têm número, não têm gosto) usando ferramentas que já rodam do lado do Claude Code

Sem abrir o Figma e sem designer de plantão: a parte que tem número você prova, e o resto você julga com pergunta guiada em vez de "achei bonito" 🙂

O que você precisa antes de revisar

Primeiro problema: o Claude não vê a sua tela se você só descrever ela

Descrição de layout é péssimo canal de informação, você fala "tá desalinhado" e ele adivinha o quê?

Então dá olhos pra ele

As três formas oficiais de mandar imagem no Claude Code:

• arrastar e soltar a imagem na janela do Claude Code
• colar com Ctrl+V (no Windows e WSL é Alt+V)
• informar o caminho do arquivo direto no prompt

Só isso já resolve a revisão pontual: tira o screenshot, joga na conversa, pede a crítica

E quando print não basta?

Tem coisa que print não pega: foco de teclado, hover, estado desabilitado, layout que só quebra quando renderiza

Pra esses casos existem duas opções de inspeção ao vivo

O chrome-devtools-mcp é mantido pelo projeto Chrome DevTools e dá ao agente de código controle e inspeção de um Chrome real, com um guia de configuração por cliente no próprio repositório, incluindo Claude Code

Já o Playwright MCP trabalha por padrão com snapshot de acessibilidade em vez de pixel: o browser_snapshot devolve uma representação textual estruturada do DOM renderizado e é o que deve ser usado pra agir, enquanto o browser_take_screenshot serve pra verificação visual (a própria ferramenta avisa pra usar o snapshot quando a intenção é agir)

Se liga na diferença, porque ela muda seu roteiro: pixel serve pra julgar, snapshot serve pra mexer

Por que a saída já vem "com estética"?

Existe um plugin oficial da Anthropic chamado Frontend Design, listado em claude.com/plugins/frontend-design, feito pro Claude gerar interfaces com escolhas estéticas deliberadas (tipografia, paleta, animação, detalhe visual) em vez de cair no padrão genérico

A descoberta e a instalação de plugins acontecem pelo comando /plugin dentro do Claude Code, no marketplace claude-plugins-official, que o Claude Code adiciona sozinho na primeira execução interativa

E o conteúdo do skill é público: ele vive como um arquivo SKILL.md em plugins/frontend-design/skills/frontend-design/SKILL.md, no repositório anthropics/claude-code

Vale a leitura pra entender o que ele está otimizando antes de você criticar o que ele entregou

Como revisar o frontend que o Claude entregou, passo a passo

Bora ver na prática? A ideia é simples: um eixo por vez, sempre na mesma ordem

Revisão que pula de assunto não acha nada

1. Hierarquia: o que o olho lê primeiro

Abre o screenshot e responde uma pergunta só: qual elemento te puxou primeiro?

Se a resposta foi "sei lá" ou foi um elemento secundário, a hierarquia está furada

Depois confere se a escala tipográfica é coerente: título, subtítulo, corpo e legenda precisam parecer degraus de uma mesma escada, não quatro tamanhos aleatórios

Anexei o screenshot da tela.
Liste, em ordem, os 3 elementos que dominam a atenção visual
e diga qual deveria dominar, dado que o objetivo da tela é X.
Depois liste os tamanhos de fonte usados e aponte quebras na escala.

O erro comum deste passo: pedir "melhore a hierarquia" antes de nomear qual é o objetivo da tela

Sem objetivo declarado, hierarquia vira preferência pessoal

2. Cor, tema e espaçamento: variáveis CSS ou bagunça?

O cookbook oficial da Anthropic organiza a direção de frontend em dimensões separadas, e elas funcionam muito bem como eixos de avaliação: tipografia, cor e tema (com variáveis CSS pra manter consistência), motion (micro-interações, preferindo CSS puro em HTML) e backgrounds (camadas e profundidade em vez de cor sólida chapada)

Usa essas dimensões como checklist de leitura do código

Se a cor está hardcoded em dez lugares diferentes, não existe tema, existe coincidência

Leia o CSS desta tela e me diga:
1. quais valores de cor e espaçamento estão fora das variáveis CSS
2. quantos valores distintos de espaçamento existem (e quais são redundantes)
3. o background usa camadas/profundidade ou é cor sólida?

O erro comum deste passo: aceitar animação boba que só existe pra parecer moderna

Motion tem que comunicar alguma coisa (estado mudou, item entrou, ação foi aceita), senão é enfeite

3. Estados de componente: hover, foco, ativo e desabilitado

Agora sai do print bonito e vai nos estados, que é onde a IA costuma entregar menos

Aqui tem número oficial: o critério WCAG 1.4.11 (contraste de elementos não textuais, nível AA) pede no mínimo 3:1 contra as cores adjacentes pra informação visual que identifica componentes de interface E os estados deles

As exceções são componentes inativos e casos em que a aparência é definida pelo user agent e não foi alterada pelo autor

É neste passo que a inspeção ao vivo ganha do screenshot, porque você precisa navegar por teclado e ver o foco aparecer

Abra a página, percorra todos os controles interativos pelo teclado
e me devolva, por componente: estado default, hover, foco visível e desabilitado.
Marque como suspeito qualquer estado cujo indicador visual pareça
ter menos de 3:1 contra a cor adjacente.

O erro comum deste passo: remover o outline de foco porque "ficou feio"

Foco invisível não é decisão estética, é componente quebrado pra quem navega por teclado

4. Tela estreita: 320px CSS é a régua

Esquece chutar breakpoint de cabeça

O critério WCAG 1.4.10 (Reflow, nível AA) diz que o conteúdo deve funcionar sem perda de informação e sem rolagem em duas direções a 320 pixels CSS de largura, o que equivale a uma viewport de 1280px com zoom de 400%

Existe exceção pra conteúdo que exige layout bidimensional, tipo tabela de dados, mapa e imagem complexa

Rolagem horizontal aparecendo junto com a vertical? Reprovou, e você nem precisa discutir gosto pra provar

O erro comum deste passo: testar só no DevTools em "modo celular" e achar que cobriu

O teste que decide é o de 320px CSS, com o conteúdo real, texto longo incluso

5. Contraste de texto: 4,5:1 e ponto

Aqui é o eixo mais fácil de verificar e o mais ignorado

O critério WCAG 2.2 1.4.3 (contraste mínimo, nível AA) exige 4,5:1 para texto normal e 3:1 para texto grande (18pt, ou 14pt em negrito)

E atenção: são limiares, não arredonda

4,499:1 NÃO passa

As exceções são texto decorativo, componente inativo, logotipo ou marca

Extraia do CSS todos os pares (cor de texto, cor de fundo) desta tela,
calcule a razão de contraste de cada par e classifique:
aprova em 4,5:1 (texto normal) ou 3:1 (texto grande, 18pt ou 14pt bold).
Não arredonde os valores.

O erro comum deste passo: revisar só o texto principal e deixar passar placeholder, legenda, texto sobre imagem e estado de erro

Cinza claro sobre branco é o campeão de reprovação

6. Fecha o loop de gerador e avaliador

A Anthropic descreve, no blog dela sobre melhorar design de frontend com skills, um loop em que um agente gera e outro avalia: o avaliador recebe screenshots via Playwright, estuda a implementação e devolve a crítica como entrada da próxima iteração

No experimento descrito nesse mesmo post foram de 5 a 15 iterações por geração

Ou seja: revisão não é evento único, é ciclo

O mesmo raciocínio de revisar código gerado fora antes do PR vale aqui, só que com pixel no lugar de diff

O erro comum deste passo: deixar o avaliador ser o mesmo contexto que gerou a tela

Quem escreveu tende a achar bom o que escreveu, e com modelo não é muito diferente 😛

Qual nível de revisão usar em cada situação

Não precisa montar a artilharia toda pra mudar a cor de um botão, beleza?

A regra prática: quanto mais a tela depende de interação, menos o print resolve

O que aprendi revisando telas geradas com design system pronto

Eu testei esse roteiro em cima do Open Design, uma alternativa que gera projeto partindo de um design system já definido

E a primeira coisa que mudou foi o ponto de partida da revisão: quando a estética já vem de um sistema pronto, você não gasta energia julgando tipografia e paleta do zero, isso já chega resolvido

O ganho é real, dá pra começar a revisão direto nos eixos que costumam falhar

Antes de gerar qualquer tela, a ferramenta fez um briefing curto comigo: superfície principal (desktop ou mobile), público alvo, tom visual com limite de duas escolhas, contexto de marca e um campo de observações

Eu escrevi nas observações que o site precisava estar em português, porque na minha experiência essas ferramentas às vezes entregam tudo em inglês sem perguntar

Durante a execução ela continuou me perguntando coisa (direção visual, por exemplo) e, quando eu não respondi uma das perguntas, ela seguiu trabalhando e entregou o resultado mesmo assim

Detalhe importante pra revisão: quando o agente decide sozinho, alguém precisa auditar a decisão depois

No fim eu abri a landing page inteira já funcionando em HTML dentro da própria ferramenta, sem Figma e sem outro editor visual

Da mesma tela eu vi o código fonte, deixei comentário e pedi alteração pontual em uma seção específica

E aqui o roteiro continuou pegando problema: design system pronto entrega coerência de tipografia e cor, mas não garante estado de foco visível, nem comportamento a 320px, nem contraste em texto secundário

Esses três você tem que ir lá checar na mão, sempre

Também dá pra exportar e compartilhar o código pra continuar na IDE, ou publicar direto na Vercel já que a entrega é HTML, e vale saber antes quem consegue abrir o arquivo exportado do outro lado

Depois eu reaproveitei o mesmo projeto pra gerar uma apresentação, descrevendo slide por slide, com opção de speaker notes

A interface muda pouco entre os tipos de projeto, o que é bom: o roteiro de revisão que você aprendeu numa tela serve na outra

Ah, e um bastidor: a instalação me deu erro de permissão e o que funcionou na minha máquina foi abrir o terminal como administrador, porque pelo terminal do VS Code não passou

Já me ferrei antes por não olhar isso primeiro 😀

No vídeo acima eu mostro a ferramenta rodando do briefing até a landing page pronta, e é fácil acompanhar os cinco eixos aplicados enquanto o resultado aparece na tela

Conclusão

Revisar frontend não é dizer se ficou bonito

É decidir com critério que tem número: 3:1 nos estados de componente, 320px CSS sem rolagem em duas direções, 4,5:1 no texto normal e 3:1 no texto grande

O resto (hierarquia, escala, variáveis CSS, motion com propósito) você julga com pergunta certa e screenshot na conversa

Próximo passo, na ordem: salva o roteiro de cinco eixos, roda ele inteiro na PRÓXIMA tela que o Claude te entregar e só depois de ter o roteiro azeitado você pluga o loop de gerador e avaliador

Quem automatiza a revisão antes de saber o que está revisando só automatiza o achismo, né? 🙂

até o próximo post!