WithZeng/design-skills

Design de site

Lições da reformulação do site Scientify (2026-10): o design só acertou depois que os rascunhos foram mostrados e aprovados, um sistema de página foi aplicado em cada seção e a verificação detectou bugs de contraste e marcação que as bibliotecas de movimento introduzem.

Fluxo de trabalho e gates

1. Briefing. Colete produto, público, seções, dados reais de exemplo e 1–2 sites de referência que o usuário goste. Se ele não tiver nenhum, escolha 2–3 que se encaixem no tipo de site a partir de references/ui-references.md (galerias, bibliotecas de UI de produtos reais, fontes de componentes) e mostre para aprovação. Faça capturas de tela das referências e salve-as como imagens --ref; quando for solicitado recomendações, mostre capturas de tela numeradas mais 2–3 combinações para escolher (método: ui-references, "Capturando referências").
2. Rascunhos antes do código. Nunca edite código para uma mudança visual até que o usuário aprove um rascunho. Use o skill image-gen. Ordem:
   1. Se a direção estiver em aberto, uma imagem de visão geral por direção (geralmente 2); o usuário escolhe uma antes de qualquer trabalho detalhado. Em seguida, uma imagem de página inteira longa (1024x1536) para fixar o sistema de página.
   2. Uma imagem de detalhe por seção/painel em resolução total.
   3. Subpáginas, depois storyboards de interação (3–4 quadros por interação) para movimento. Mostre cada lote, colete feedback, itere. Modelos de prompt: references/draft-prompts.md.
3. Construção apenas dos rascunhos aprovados, atrás de uma rota de pré-visualização até que o usuário diga para substituir a página ao vivo. Padrões: references/build-patterns.md.
4. Verificação antes de qualquer commit/PR: references/verification.md.
5. Mantenha rascunhos e capturas de tela na pasta scratch ignorada pelo git do projeto (ex.: tmp/design/vN/), uma pasta por rodada, prompts salvos junto com as imagens.

Sistema de página (o que removeu a "割裂感")

Uma página parece uma peça única quando cada seção reutiliza o mesmo sistema. Decida os valores do sistema a partir dos rascunhos aprovados e depois escreva-os em cada prompt e nos tokens de código:

• Um tratamento de fundo para a página inteira; evite seções que inventam suas próprias faixas ou gradientes.
• Um módulo de seção (container, raio, preenchimento, borda, padding, largura) e um conjunto pequeno de layouts dentro dele, reutilizado seção após seção.
• Uma escala tipográfica: o mesmo tamanho e peso para cada título de seção, um estilo de corpo, espaçamento consistente.
• Uma peça de assinatura carrega a direção de arte (geralmente no hero); todo o resto permanece mais quieto no layout, mas ainda responde à interação. O que é essa peça vem do briefing, não de um template: veja "Direção de arte" abaixo.
• Toda interface de produto mostrada é do MESMO aplicativo (mesma navegação, tema, dados), para que a página seja lida como um único produto.
• Uma paleta restrita o suficiente para manter o sistema coerente (um site usou monocromático puro); o logotipo mantém suas cores originais. Use o logotipo real da marca em todos os lugares, nunca um placeholder de letra em um quadrado.
• Conteúdo: dados realistas do domínio do produto (nomes, números e tempos plausíveis) e uma convenção de nomenclatura para arquivos e objetos, decidida por projeto; sem lorem, sem depoimentos ou estatísticas falsos, sem slogans de buzzword.

Interface do aplicativo e páginas de autenticação

Os mesmos gates se aplicam dentro de um produto, com referências e tokens diferentes:

• As referências vêm de UI de produtos reais (ex.: Refero, capturas de tela de produtos em sites comparáveis, documentação de componentes para telas de chat/agente), não de galerias de landing page.
• Reutilize os tokens e componentes do próprio aplicativo; não importe a paleta do site de marketing. Fixe primeiro um conjunto pequeno de primitivas compartilhadas (painel, larguras de container de página, larguras de diálogo, controle segmentado), depois reformate as telas com elas.
• Login/cadastro com um widget de autenticação hospedado (ex.: Clerk): estilize-o através de sua API de aparência e localização, e verifique as armadilhas em build-patterns ("Páginas de autenticação").

Direção de arte (dimensão e movimento)

Projete as partes dimensionais e móveis a partir dos próprios requisitos do site, depois rascunhe-as como qualquer outro visual. Não reutilize uma receita ou valores fixos de um site anterior.

1. Derive do briefing. Qual é a única ideia que um visitante deve captar (o produto em ação, uma transformação, escala, precisão, calma)? Quem é o público, qual é o tom da marca, quais dispositivos e orçamento de desempenho? A peça de assinatura deve mostrar essa ideia, idealmente com o produto real.
2. Explore 2–3 opções que se encaixem no sistema de página e no tom, ex.: uma janela de produto em perspectiva, profundidade em camadas com parallax, uma cena conduzida por scroll que conta o fluxo de trabalho, uma ilustração ou objeto 3D, uma metáfora visual/de dados, ou uma página plana e calma com micro-interação rica. Rascunhe cada uma como uma imagem e, para movimento, como um storyboard; o usuário escolhe.
3. Especifique, depois construa. Escreva para a opção escolhida: o que se move, o que o aciona (carregamento, scroll, ponteiro, tempo, clique), o estado de repouso, a versão de movimento reduzido e a versão para dispositivos móveis. Ajuste ângulos, temporizações e intensidades contra os rascunhos aprovados no navegador, não a partir de um template.
4. Verifique o custo. Não deve prejudicar legibilidade, contraste, estabilidade de layout ou tempo de carregamento; deve degradar graciosamente sem JS e com movimento reduzido.

Interação rica, a partir de bibliotecas

Páginas estáticas parecem baratas. Use bibliotecas de componentes e animação ativamente para fazer cada interação parecer viva:

• Cada estado recebe feedback: hover, pressionar, foco, carregando/executando, sucesso/erro, aparecer/desaparecer, mudança de layout. Planeje esses nos storyboards de interação, não como um pensamento posterior.
• Prefira um componente pronto bem construído a um efeito feito à mão. Mapeie cada interação para um padrão, depois escolha o componente das bibliotecas escolhidas para este projeto (references/ui-references.md, "Padrões de interação").
• Demonstrações de produto se movem: tarefas reais progredindo, resultados chegando, números mudando, cenas alternando.
• Mantenha-o proposital: o movimento explica o estado ou atrai o olhar para o que mudou. Efeitos decorativos pesados pertencem a páginas de marketing, não a telas de trabalho. Respeite o movimento reduzido em todos os lugares.

Escolhendo bibliotecas

Escolha bibliotecas de componentes e animação para o projeto; nenhuma é obrigatória.

• Projeto existente: use o que já tem; adicione uma biblioteca apenas para uma lacuna e nunca uma que sobreponha uma existente.
• Novo projeto: escolha pelo tipo de projeto, framework e necessidades (critérios e candidatos em references/build-patterns.md, "Escolhendo bibliotecas"). Mantenha um sistema base de componentes e uma biblioteca principal de animação, a menos que haja um motivo claro.
• Prefira fontes que instalem como código-fonte editável no projeto (registry/CLI ou cópia) em vez de pacotes opacos, para que os componentes sigam os tokens do projeto.

Regras arduamente conquistadas (detalhes em build-patterns)

• Cada tom de texto deve passar 4.5:1 na superfície em que está; verifique o token mais claro no preenchimento do painel, não apenas no fundo da página.
• Sem fade de opacidade em entradas acima da dobra e sem escurecimento por opacidade para estados "inativos" — auditorias axe durante a animação e sinalizam contraste. Use entradas apenas com transform e mudanças de cor.
• Wrappers de animação não devem ficar entre <ul>/<ol> e <li>; anime dentro do <li>.
• Pills deslizantes: coloque o rótulo em um span relative acima de uma pill absoluta; sem -z-10 + isolate.
• Contadores renderizam o valor final no servidor e animam apenas quando estão na viewport.
• Em sites multilíngues, toda string visível passa por i18n, incluindo UI de demonstração dentro de janelas mock e sessões reproduzidas.
• Grades precisam de uma coluna única explícita / faixas minmax(0,1fr) e a raiz da página precisa de overflow horizontal oculto para evitar overflow em dispositivos móveis.