Front end design no Claude Code: em que ordem pedir cada parte da tela?

front end design no Claude Code: ordem para pedir cada parte da tela
Resposta rápida

Front end design no Claude Code rende muito mais quando você pede as partes na ordem certa: primeiro o plano de design (propósito, público e uma direção estética assumida), depois a hierarquia de informação e a árvore de componentes daquele produto, uma rodada anti genérico revisando o plano contra o brief e só então o código da estrutura. Tipografia e cor entram guiadas separadamente (a orientação da Anthropic é evitar Arial e Inter e usar variáveis CSS), estados e responsividade vêm na sequência, e movimento fica por último, concentrado em poucos momentos de alto impacto.

Pedir o visual antes da estrutura é a forma mais rápida de jogar uma tela inteira fora

Fala aí, beleza? O Frontend Design é um plugin oficial da Anthropic, e a skill dele é acionada automaticamente quando o pedido é de interface, sem você precisar invocar nada à mão

E tem um detalhe que muda tudo: a skill exige um plano de design antes de escrever qualquer linha de código

Ou seja, a própria ferramenta já impõe uma ordem

O que falta é você transformar isso num roteiro de pedidos, do primeiro prompt até a última animação, e é exatamente isso que eu vou montar aqui

O que você precisa antes de pedir a primeira tela

O básico é ter o Claude Code rodando

O marketplace oficial (claude-plugins-official) é registrado sozinho na primeira execução interativa, então a instalação vira um comando só:

/plugin install frontend-design@claude-plugins-official

Next, next e finish, praticamente 🙂

O texto da skill não é caixa preta: ele vive no repositório anthropics/claude-plugins-official, no caminho plugins/frontend-design/skills/frontend-design/SKILL.md (o mesmo caminho também existe espelhado em anthropics/claude-code)

Vale a leitura antes de sair pedindo tela, porque ali está escrito o que a skill considera uma tarefa de frontend concluída

E se eu quiser adaptar o texto? No Claude Code, skills pessoais ficam em ~/.claude/skills/ e skills de projeto ficam em .claude/skills/

Formação Claude Code
Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

  • 118 aulas
  • 4 projetos
  • 9h 33min

Dá pra ter uma versão sua por projeto, com as regras da sua base de código dentro

Uma observação que economiza tempo: você não precisa chamar a skill

Pediu interface, ela entra

O roteiro de pedidos, passo a passo

A lógica do roteiro é simples: o que é caro de mudar depois vem primeiro

Hierarquia errada quebra o visual inteiro

Cor errada é um find and replace

  1. Peça o plano de design antes de qualquer código

A skill já cobra isso, mas escrever no prompt deixa o resultado muito mais afiado, porque você controla o que entra no plano

Antes de escrever qualquer código, me entregue só o plano de design desta tela.

No plano quero:
- propósito: que problema essa interface resolve
- público: quem usa e em que contexto
- direção estética: escolha UM tom e assuma ele até o fim

Não gere HTML, CSS ou componente nesta resposta.

O erro comum deste passo: aceitar um plano morno, do tipo "visual moderno e limpo"

Isso não é direção estética, é enfeite

A orientação da skill é escolher um tom extremo e assumir ele

  1. Exija hierarquia de informação explícita e árvore de componentes específica

Essa é a parte que ninguém pede e todo mundo sofre depois

Pelos critérios da própria skill, a tarefa só está completa se o objetivo do produto estiver claro, a hierarquia de informação estiver explícita e a árvore de componentes for específica do produto pedido, não genérica

Ainda sem código.

Liste a hierarquia de informação da tela: o que o usuário precisa ver
primeiro, segundo e terceiro, e por quê.

Depois liste a árvore de componentes desta tela, com nomes que só fazem
sentido neste produto. Nada de Card, Section, Wrapper genérico.

O erro comum deste passo: deixar a IA nomear tudo de Card e Container

Quando o nome é genérico, o layout também vai ser

  1. Rode uma rodada anti genérico antes de liberar o código

A skill manda revisar o plano de design contra o brief antes de codar: se alguma parte parecer padrão genérico em vez de escolha feita para aquele brief, a parte é revisada e a mudança é justificada

Só então o código começa

Revise o plano contra o brief.

Aponte cada parte que é default genérico e não escolha para este brief,
troque essa parte e justifique a troca em uma linha.

Defaults que eu NÃO quero: kit de cartões de SaaS, conteúdo picado em
cartões arredondados idênticos, um único border-radius em tudo
ignorando a hierarquia.

O erro comum deste passo: pular ele porque "o plano já está bom"

O kit de cartões de SaaS é literalmente citado como antipadrão pela skill, e ele aparece sozinho se você não nomear

  1. Aí sim, libere o código da estrutura

Estrutura primeiro, nua

Sem cor de destaque, sem animação, sem ícone bonitinho

Plano aprovado. Agora gere só a estrutura da tela em código,
seguindo a árvore de componentes que você definiu.

Sem animação e sem refino visual ainda.

O erro comum deste passo: pedir estrutura e estilo no mesmo prompt

Quando vem tudo junto, você revisa o visual e deixa a hierarquia passar batido

  1. Guie tipografia e cor como dimensões separadas

A Anthropic aponta três estratégias que melhoram consistentemente o resultado visual: guiar as dimensões de design separadamente (tipografia, cor, movimento, fundos), citar referências de inspiração sem ser prescritivo demais, e nomear explicitamente os padrões genéricos que o modelo deve evitar

Na tipografia, a instrução é escolher fontes bonitas e distintivas, evitando genéricas como Arial e Inter

Na cor, a recomendação é assumir uma estética coesa com variáveis CSS para consistência, porque cor dominante com acento marcado funciona melhor que paleta tímida e distribuída de forma uniforme

Agora só tipografia: escolha fontes distintivas (nada de Arial ou Inter)
e defina a escala de tamanhos. Justifique a escolha em uma linha.

Depois disso, só cor: uma cor dominante e um acento marcado,
tudo em variáveis CSS. Nada de paleta uniforme.

O erro comum deste passo: mandar "deixa bonito" e receber a média da internet

O conjunto dessas orientações de design foi condensado pela Anthropic em um trecho de prompt de cerca de 400 tokens, então cabe fácil no seu contexto se você quiser colar por inteiro

  1. Peça estados e etapas intermediárias

Tela de produto real não tem só o estado feliz

Tem espera, tem vazio, tem erro

Para cada componente da árvore, descreva e implemente os estados que
esta tela realmente precisa, incluindo a etapa intermediária enquanto
o dado não chegou.

O erro comum deste passo: só descobrir que faltava o carregamento quando a API entra e a tela pisca

  1. Só depois, responsividade

Com a hierarquia travada, responsividade vira consequência: o que era primeiro continua primeiro na tela estreita

Adapte a tela para telas estreitas mantendo a mesma hierarquia de
informação que definimos. O que era primeiro continua primeiro.

O erro comum deste passo: pedir responsividade antes da hierarquia existir, e aí cada breakpoint inventa uma ordem diferente

  1. Movimento por último

Na orientação de movimento, a preferência é solução só com CSS no caso de HTML e a biblioteca Motion no caso de React quando disponível, concentrando esforço em momentos de alto impacto

Um carregamento de página bem orquestrado com revelações escalonadas entrega mais que microinterações espalhadas

Por último, movimento. Escolha no máximo dois momentos de alto impacto
nesta tela e trabalhe só eles. Sem microinteração espalhada.

O erro comum deste passo: aceitar que a IA instale uma lib de animação no meio do caminho sem você olhar

Se o projeto é React e a Motion vai entrar, trate como mudança de dependência mesmo, com o mesmo cuidado de pedir uma atualização de dependência sem quebrar o que já funcionava

Como essa ordem se comportou na prática

No vídeo abaixo, "Claude Design + Claude Code: Criei um SaaS COMPLETO em 20 Minutos", eu monto um SaaS do zero começando pela etapa de design e só depois levando pro Claude Code, e o roteiro do prompt foi basicamente esse daqui

Eu defini primeiro a quantidade de telas e o objetivo do produto: 2 telas, home e resultado

Só depois desci pro conteúdo de cada uma, na ordem em que o usuário percorre a tela

Na home: hero com título e subtítulo, campo de input pra colar a URL, exemplos em chips clicáveis logo abaixo e por último a faixa explicando as categorias avaliadas

Na tela de resultado: URL analisada no topo, estado de carregamento enquanto a IA não responde, nota geral, 4 cards de categoria (SEO, conteúdo, performance e um último juntando UX e acessibilidade) e no fim os botões de copiar relatório ou analisar outro site

O estilo visual eu deixei pro final do prompt, depois de toda a estrutura: tema escuro com fundo quase preto, laranja vibrante como destaque de CTA, tipografia moderna e limpa, cards com cantos arredondados sutis

E olha o que voltou: 3 etapas, as duas telas que eu pedi mais uma etapa intermediária de carregamento que apareceu a partir do fluxo

Confesso que de início achei que as duas telas estavam iguais, aí percebi que aquilo era o skeleton animado 😅

A parte que interessa pro assunto deste post: depois do design base existir, eu pedi 2 ajustes na segunda rodada

Compactar o hero da home, pro usuário focar no input e enxergar os cards de categoria sem rolar muito

E colocar a nota geral dentro de um círculo com a cor variando conforme a nota, que é mais ou menos como o Google Analytics apresenta performance, dá mais peso visual e deixa a tela mais memorável

Dois ajustes

Não uma refação

É isso que a ordem compra: quando a hierarquia entra antes do visual, a segunda rodada vira acabamento

O contexto de stack eu só acrescentei na hora de levar pro código, pedindo um projeto Next.js integrado à API da Anthropic, e não lá no design

Sair de um design e cair numa ferramenta de linha de comando não é exclusividade de um combo só: dá pra ver quais CLIs aceitam esse fluxo e escolher a sua

Ah, e um aviso honesto: os 20 minutos do título são o tempo do projeto completo, não uma medição que eu fiz trecho por trecho

Repara no vídeo na ordem do prompt: quantidade de telas e objetivo primeiro, conteúdo de cada tela na sequência em que o usuário percorre, estilo visual só no fim

Sinais de que você inverteu a ordem (e como sair)

Tela bonita que não responde a pergunta do usuário

Causa: estética antes do propósito

O plano de design ou não existiu ou veio com "moderno e limpo" no lugar de propósito e público

Solução: volta pro plano e reescreve objetivo e público antes de tocar no código de novo

Pelos critérios da skill, sem objetivo claro a tarefa nem está concluída

Como prevenir na próxima tela: primeiro prompt sempre pede plano, e proíbe código na resposta

Conteúdo picado em cartões arredondados iguais

Causa: default genérico aceito sem revisão

É o kit de cartões de SaaS que a própria skill nomeia como antipadrão: cartões idênticos e um único border-radius em tudo, independentemente da hierarquia

Solução: rodada anti genérico, revisando o plano contra o brief e citando o antipadrão pelo nome, pedindo justificativa de cada troca

Como prevenir na próxima tela: já entrar no brief com a lista do que você NÃO quere ver, porque nomear o default a evitar é uma das três estratégias que a Anthropic aponta

Animação em tudo e nada em destaque

Causa: movimento pedido junto com a estrutura

Aí cada componente ganha seu microefeito e o olho do usuário não sabe pra onde ir

Solução: cortar as microinterações dispersas e concentrar em poucos momentos de alto impacto, tipo um carregamento de página bem orquestrado com revelações escalonadas

Como prevenir na próxima tela: movimento é sempre o último prompt, nunca o mesmo prompt da estrutura

O que revisar antes de dar a tela por pronta

Checklist curto, roda antes de considerar o trabalho fechado:

  1. O plano de design veio ANTES do código
  2. O objetivo do produto está claro no plano
  3. A hierarquia de informação está explícita, não implícita no layout
  4. A árvore de componentes é daquele produto e não genérica
  5. Tipografia e cor foram escolhas justificadas, não defaults (nada de Arial ou Inter por inércia, e cor em variáveis CSS)
  6. Os estados e as etapas intermediárias existem, incluindo a espera
  7. O movimento está concentrado em poucos momentos, não espalhado

Um lembrete operacional pra quem adapta a skill: editar o texto do SKILL.md é detectado dentro da sessão, sem reiniciar

Porém, mudanças em hooks, .mcp.json, agents e output-styles de uma pasta que também é plugin exigem /reload-plugins

Já me ferrei achando que tinha recarregado tudo só porque salvei o arquivo 😛

Conclusão

A ordem dos pedidos é o que separa ajuste de refação

Estrutura e hierarquia primeiro porque são caras de trocar, estados e responsividade no meio, detalhe visual e movimento no fim porque são baratos de trocar

Inverteu isso, a tela fica bonita antes de fazer sentido, e aí não tem prompt que salve

Próximo passo bem concreto: instala o plugin com /plugin install frontend-design@claude-plugins-official, escreve um brief de UMA tela só e pede o plano de design antes de qualquer código

Se quiser se aprofundar nas dimensões de design, o material da Anthropic sobre a skill é curto e direto

Bora testar? 😀

Até o próximo post!

Perguntas frequentes

Preciso instalar alguma coisa antes de pedir a primeira tela no Claude Code?

Só o plugin oficial. O marketplace claude-plugins-official já é registrado sozinho na primeira execução interativa, então basta rodar /plugin install frontend-design@claude-plugins-official. A skill entra automaticamente quando o pedido é de interface, sem precisar invocar nada à mão.

Como recarregar a skill de frontend design depois de editar o SKILL.md do projeto?

Se você mexeu no texto do SKILL.md, não precisa recarregar nada: o Claude Code detecta a mudança dentro da própria sessão, sem reiniciar. É por isso que dá pra manter sua versão adaptada da skill em ~/.claude/skills/ (pessoal) ou .claude/skills/ (projeto) e ir ajustando o texto conforme você testa as telas.

Quantas telas dá pra pedir seguindo esse roteiro num projeto de exemplo?

No exemplo usado aqui foram pedidas 2 telas, home e resultado, com a tela de resultado trazendo 4 cards de categoria: SEO, conteúdo, performance e um último juntando UX e acessibilidade. O design final saiu em 3 etapas: as duas telas mais uma etapa intermediária de carregamento.

Quanto tempo leva pra rodar todo esse roteiro do plano de design até o resultado final?

No projeto completo usado como referência, o vídeo Claude Design + Claude Code: Criei um SaaS COMPLETO em 20 Minutos, o total foi de 20 minutos, do plano de design até o SaaS rodando.

Depois que a IA entrega o design base, ainda preciso pedir ajustes?

Sim, é normal. No exemplo deste roteiro, depois que o design base ficou pronto eu pedi 2 ajustes na segunda rodada, refinando pontos que só aparecem quando você vê a tela de verdade.

O que é o antipadrão do kit de cartões de SaaS que a skill do Frontend Design evita?

É quando o conteúdo vira uma sequência de cartões arredondados idênticos, todos com o mesmo border-radius, ignorando a hierarquia da informação. A própria skill cita esse padrão como algo a evitar, por isso vale nomear ele explicitamente no prompt de revisão anti-genérico.




Escrito por | Matheus Battisti

Matheus Battisti
Fundador da Hora de Codar

Programador apaixonado pelo mundo das tecnologias, sempre buscando em aprender e se aprofundar em linguagens, frameworks e o que mais for necessário para executar um bom trabalho. Agora tem uma nova missão que é de passar seu conhecimento adiante para formar novos programadores e especializar mais os que já são.

Subscribe
Notify of
guest

0 Comentários
Oldest
Newest Most Voted

Formações

Formação Vibe Coding

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

  • 474 aulas
  • 20 projetos
  • 39h 27min

Blog | Mais populares