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

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
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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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:
- O plano de design veio ANTES do código
- O objetivo do produto está claro no plano
- A hierarquia de informação está explícita, não implícita no layout
- A árvore de componentes é daquele produto e não genérica
- Tipografia e cor foram escolhas justificadas, não defaults (nada de Arial ou Inter por inércia, e cor em variáveis CSS)
- Os estados e as etapas intermediárias existem, incluindo a espera
- 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.
Formações
Formação Vibe Coding
Do Prompt ao Produto: Crie Software Real com IA
- 474 aulas
- 20 projetos
- 39h 27min
Blog | Mais populares
Skill de design serve para vários projetos ou tem que refazer em cada repositório?
Skills Claude Design funcionam em vários projetos ou é preciso recriar em cada repositório? Veja a diferença entre escopo pessoal e escopo de projeto.
Como criar uma skill de design para dashboards no Claude Code: regras de gráficos, tabelas e densidade
Aprenda a criar uma skill de design para dashboards no Claude Code: regras de gráficos, cor com significado (WCAG) e densidade de tabelas.
Dark mode em skill de design: como escrever as regras de tema sem duplicar tudo
Dark mode em skill de design sem duplicar paleta: contrato semântico, light-dark(), Tailwind v4 e a régua de contraste da WCAG explicados na prática.
