Design para Web (Web Design)

O que Design para Web (Web Design) faz?

UI gerada falha de maneiras previsíveis: as mesmas fontes, o mesmo gradiente violeta, cards dentro de cards, um hero centralizado com três tiles de ícones, decoração tomando o lugar de um ponto de vista. Esta habilidade substitui defaults por decisões e depois verifica o resultado renderizado.

<skill-dir> abaixo significa a própria pasta desta habilidade. Execute seus scripts a partir da raiz do projeto para que os resultados caiam no projeto, não na habilidade instalada.

1. Carregar ou criar o contexto de design

Procure por DESIGN.md (também docs/DESIGN.md, BRAND.md). Se existir, leia-o antes de tocar na UI; seus tokens e regras vencem seu gosto pessoal. Se não existir e o trabalho for mais que um pequeno ajuste, crie um a partir do modelo lendo o código: tokens reais da configuração CSS/Tailwind, fontes reais, componentes reais. Marque qualquer item que você inferiu como inferido.

Atualize o DESIGN.md quando uma sessão tomar uma decisão duradoura (um novo token, uma direção rejeitada e o porquê). Assim a próxima sessão evita regredir para defaults.

2. Decidir a direção

Nomeie o modo primeiro. Ele define o quanto de ousadia a superfície merece:

• Persuadir (landing, pricing, páginas de lançamento): o design é o produto; comprometa-se com um ponto de vista.
• Operar (UI de app, dashboards, configurações, formulários): precisão e parcimônia; padrões familiares merecem seu lugar; a marca vive nos detalhes.
• Ler (docs, artigos, changelogs): estrutura para compreensão, depois torne a leitura agradável.
• Experimentar (portfólios, showcases, jogos): o trabalho lidera; a interface recua.

Refinando ou redesenhando? Refinar mantém a identidade, cópia e comportamento atuais e melhora dentro deles. Redesenhar mantém os fatos e a função do produto, mas substitui totalmente a aparência. Nunca divida a diferença polindo um visual que você pretende descartar.

Depois planeje em duas passagens antes de escrever código.

Passagem um, o plano:

• Trabalho: quem está aqui, o que precisa primeiro, a próxima ação.
• Paleta: quatro a seis valores hexadecimais nomeados, com onde o acento é permitido.
• Tipografia: faces e seus papéis, a escala, numerais.
• Layout: uma frase e um wireframe ASCII aproximado; alinhamento declarado.
• A única coisa ousada: o elemento memorável único. Tudo ao redor permanece quieto.

Passagem dois, o teste genérico: você teria produzido este plano para qualquer briefing semelhante? Verifique contra os atuais looks padrão de IA, que mudam ao longo do tempo. Fundo creme com display serifado e acento terracota, quase preto com um acento ácido, e traços finos de jornal são os clusters de hoje, assim como gradientes roxos no ano passado. Se uma parte do plano corresponde a um default que o briefing não pediu, substitua-a e anote o que mudou e por quê. As próprias palavras do briefing sempre vencem, inclusive quando ele pedir um desses looks.

Escolha a partir do mundo do assunto: seus materiais, lugares, artefatos e vocabulário. O site de um passeador de cães e o dashboard de um analista não devem conseguir trocar paletas.

Quando o usuário fornecer referências, estude-as adequadamente: estudo de referência extrai estilos computados dos sites ao vivo para que você tome emprestadas relações (escala, ritmo, densidade), não decoração superficial.

3. Construir no sistema do produto

• Use tokens, primitivos e componentes existentes. Adicione um token antes de adicionar um valor avulso.
• Conteúdo real apenas: nomes reais, nomes longos, números reais, dados vazios. Nunca lorem ipsum, nunca métricas inventadas para preencher um layout.
• Projete os estados junto com a tela: carregando, vazio, erro, sucesso, desabilitado, estouro. Um estado vazio que parece quebrado é um bug.
• Esconda o que não tem nada a dizer. Linhas com zero, saldos zero e gráficos vazios se tornam um estado vazio honesto ou desaparecem; nenhuma parede de zeros.
• Cabeçalhos são rótulos. Um subtítulo que reexplica o cabeçalho é deletado.
• Mobile é seu próprio layout: reordene por prioridade, use rails de snap horizontal onde desktop usa grids, dvh/svh em vez de 100vh, inputs com 16px ou maiores, alvos de toque com 44px.

Mantenha a linha no piso de qualidade (craft floor) enquanto constrói, não como uma passagem final. Para qualquer animação ou transição, leia motion primeiro: um momento orquestrado, um pequeno sistema de temporização, seguro para interrupção, movimento reduzido tratado, e assistido como um filmstrip.

4. Olhar para ele

node <skill-dir>/scripts/shoot.mjs http://localhost:3000/page --full          # 390 + 1440, light + dark
node <skill-dir>/scripts/shoot.mjs http://localhost:3000/page --widths 320,390,768,1440 --themes light
node <skill-dir>/scripts/shoot.mjs http://localhost:3000/page --click '[aria-controls=menu]' --widths 390

Abra cada screenshot e realmente leia. Depois percorra, nesta ordem:

1. Primeira leitura: aperte os olhos. A coisa mais importante é a mais proeminente? Dá para saber o que é e o que fazer em três segundos?
2. Quebrado: estouro, texto cortado, camadas sobrepostas, palavras perdidas, foco invisível, contraste no modo escuro. shoot.mjs sinaliza vários destes; verifique sua saída.
3. Hierarquia e ritmo: mais espaço acima de um título do que abaixo dele; espaçamentos consistentes dentro de grupos, maiores entre grupos; uma ação primária por visualização.
4. Genérico: execute a varredura deslop ou verifique anti-padrões. Um estranho adivinharia este produto a partir de um screenshot com o logotipo removido?
5. Qualidade: alinhamento ao pixel em 2x, equilíbrio ótico de ícones e texto, números tabulares em colunas.

Corrija o pior problema, tire novo screenshot, repita. Compare com referências na mesma largura e estado. Dois ou três ciclos completos é normal para trabalho novo.

5. Finalizar

Relate as telas e estados que você inspecionou (larguras, temas), as decisões que tomou, e o que não foi inspecionado (estados autenticados que você não conseguiu acessar, dados reais que você não tinha). Commit as alterações do DESIGN.md junto com a UI.

Regras

• O briefing do usuário e o DESIGN.md vencem esta habilidade. Se a marca é gradientes roxos, são gradientes roxos.
• Nenhuma nova biblioteca de UI, conjunto de ícones ou fonte para uma alteração local.
• Não invente prova social, depoimentos, logotipos, contagens de usuários ou "confiado por".
• Não simule atualização em tempo real: sem pontos pulsantes de "Ao vivo", tickers ou atividade a menos que haja dados reais nessa cadência ("Atualiza a cada 10s" quando for verdade).
• Nunca colapse estados distintos (submetido, aceito, confirmado) em um único tick de sucesso.