Killer Design

O que Killer Design faz?

O padrão é um site que as pessoas carregam e pensam "uau": algo que um estúdio de ponta poderia ter feito para este projeto. Limpo, correto e de bom gosto é o mínimo, não o objetivo. Uma página que apenas evita erros é esquecível. Três hábitos te levam até lá, e esta skill é construída em torno deles:

1. Decida o design antes de escrever código. Sites genéricos vêm de nunca tomar uma decisão. Fontes, cores e layout usam o padrão de todo template. Uma breve direção escrita, enraizada no assunto (ou na marca, se houver), dá a cada escolha posterior uma razão.
2. Crie um momento de impacto. Dê à primeira tela um ponto focal, enraizado no conceito, que faça alguém parar: uma demonstração ao vivo, tipografia ousada, luz que responde ao ponteiro, uma cena que se constrói conforme você rola. Execute-o com um alto padrão e mantenha tudo ao redor calmo para que ele tenha espaço. Veja references/motion-and-wow.md.
3. Olhe para o resultado. CSS escrito às cegas sempre sai errado: layouts móveis apertados, hierarquia fraca, texto cinza que ninguém consegue ler, animação que se arrasta. Renderize a página, incluindo a animação, olhe como um crítico, corrija os problemas e olhe novamente.

O trabalho segue seis etapas: entender o projeto, definir uma direção, escrever o conteúdo, construir, revisar as capturas de tela e corrigir, e finalizar e entregar. Redesenhos adicionam uma etapa de inventário primeiro (veja "Redesenhando um site existente").

1. Entender o projeto

Leia o que já existe antes de perguntar qualquer coisa. Isso inclui o README, documentação, metadados do pacote ou aplicativo, cópia existente, logotipos e arquivos de marca, capturas de tela e qualquer DESIGN.md. Descubra:

• O que é, em uma frase que um estranho entenderia.
• Quem chega, e o que eles precisam decidir ou fazer. Nomeie a única ação principal: instalar, pré-encomendar, inscrever-se, entrar em contato.
• Os detalhes: comandos reais, números, nomes, horários, lugares, funcionalidades, restrições, história. Esta é a matéria-prima para o conteúdo e visuais, e detalhes específicos são o que impedem um site de parecer genérico.
• Personalidade: três adjetivos, mais uma coisa que não é. "Preciso, tranquilo, confiável; não divertido."
• Restrições: hospedagem (por exemplo, GitHub Pages estático), qualquer coisa que deva permanecer e ativos de marca existentes.
• Intenção documentada: o que o README ou a documentação dizem que o site é para, e o que deliberadamente exclui ("uma página, um botão para o GitHub; a lista completa está em outro lugar"). Isso é uma decisão que alguém já tomou. Siga-a, e ofereça qualquer coisa além dela como uma proposta na entrega, em vez de construí-la.
• Se existe um sistema de marca: um guia de marca (BRAND.md, um guia de estilo, um repositório de marca), tokens de design, um DESIGN.md ou um conjunto consistente de artefatos de marca finalizados (cards sociais, banners, capas de README, o site atual). Se existir, o passo 2 funciona de forma diferente. Veja "Trabalhando dentro de uma marca existente" abaixo.

Pergunte ao usuário apenas por coisas que você não pode encontrar ou inferir sensatamente e que mudariam o design. O exemplo óbvio é o que o produto realmente faz. Para todo o resto, tome uma decisão razoável e liste suas suposições na entrega. Reagir a uma página real é mais fácil para eles do que responder a um questionário.

2. Definir a direção de design

Se o projeto já tem um sistema de marca, a marca é a direção. Avance para "Trabalhando dentro de uma marca existente" e volte para o passo 3. O que se segue é para projetos que precisam de um design inventado.

"Limpo e moderno" não é uma direção. É o que se obtém quando nenhuma decisão foi tomada.

Encontre o conceito no assunto. Pergunte em que mundo o projeto vive. Uma oficina de reparo de violinos sugere abeto e verniz, etiquetas escritas à mão, desenhos medidos. Um portal de dados abertos de uma cidade sugere mapas de trânsito, sistemas de sinalização e horários. Uma academia de escalada sugere mapas topográficos, giz e graus de rota. Vá além da primeira associação para algo específico: "papel e tinta" se aplica a quase tudo, enquanto "um pacote de sementes de um catálogo dos anos 1950" não. O conceito deve moldar o tipo, a paleta, a textura e o layout. Não deve se transformar em clip-art ou trocadilhos.

Esboce três direções genuinamente diferentes em uma ou duas linhas cada, variando o conceito, o tipo, a temperatura de cor e a atitude do layout. Em seguida, escolha a que melhor se adequa ao público e à personalidade. A primeira ideia que vem à mente é geralmente a mais genérica, e é por isso que você escreve três. Verifique a direção escolhida em relação a "O que faz um site parecer feito por IA" perto do final deste arquivo. Se ela se resumir a uma das paletas padrão mais as seções usuais, vá mais longe.

Escolha o momento de impacto. Pergunte qual é a única verdadeira coisa mais interessante sobre o projeto, e como a primeira tela poderia mostrá-la em vez de dizê-la. Escreva dois ou três momentos candidatos e escolha aquele que é mais conceitual e que você pode executar lindamente. Leia references/motion-and-wow.md para o menu de técnicas e receitas testadas. Em seguida, pergunte honestamente se alguém que visse isso diria "uau" ou "legal". Se a resposta for "legal", seja mais ousado: aumente a escala, faça um contraste mais forte, torne o momento mais vivo.

Escreva a direção em DESIGN.md na raiz do site, usando o modelo abaixo. O arquivo mantém as páginas futuras e as sessões futuras consistentes. Se um DESIGN.md já existir, siga-o e estenda-o em vez de inventar uma nova aparência, a menos que o usuário tenha pedido uma nova direção.

Antes de escolher tipo e cor, leia references/typography.md e references/color.md. Eles contêm pares de fontes e um método de paleta que evitam os padrões usuais. references/layout.md cobre composições além de "herói mais três cards".

# Design: <projeto>

## Conceito
Uma ou duas frases: o mundo em que isso vive e a sensação com que um visitante deve sair.

## Público e ação principal
Quem chega, o que eles precisam saber, a única coisa que queremos que eles façam.

## Tipo
Display: <família, pesos>, e por quê. Texto: <família, pesos>, e por quê. Mono, se houver.
Escala: tamanho base e proporção (de scripts/scale.mjs).

## Cor
Papel -> valor: bg, surface, ink, ink-muted, line, accent, on-accent, focus.
Regras de uso (por exemplo, "accent apenas na ação principal e estados ativos").

## Layout
Grade e larguras, ritmo de seção, atitude geral (editorial, denso, arejado, assimétrico...).

## Assinatura
O movimento ou dois pelos quais as pessoas lembrarão este site.

## Momento de impacto
O que faz alguém parar na primeira tela e como funciona. Também como fica sem JS, com movimento reduzido e em um telefone.

## Imagens e textura
Quais são os visuais e como são feitos, dados os ativos existentes.

## Movimento
O que se move, como e quanto. Respeita movimento reduzido.

## Voz
Como a cópia soa; palavras a serem usadas e palavras a serem evitadas.

## Alternativas consideradas
As outras duas direções, uma linha cada, para que o usuário possa redirecionar.

Escolha uma direção e construa-a. Não pare para perguntar ao usuário para escolher entre abstrações. Liste as alternativas na entrega para que eles possam redirecionar depois de verem uma página real.

3. Escreva o conteúdo primeiro

O layout segue o conteúdo. Um design desenhado em torno de lorem ipsum produz caixas genéricas, e uma cópia genérica faz até mesmo um bom layout parecer um template. Escreva as palavras reais antes de dispor qualquer coisa:

• Título: o que é, ou o que muda para o visitante, em palavras simples. Específico vence inteligente. "Reserve uma quadra em qualquer clube de tênis público em Leeds" vence "Seu jogo, elevado."

• Use os detalhes do projeto: comandos reais, números reais, nomes reais, os horários e lugares reais.

• Corte linguagem de marketing padrão: desbloquear, elevar, contínuo, capacitar, revolucionar, turbinar, sem esforço, de ponta, robusto, alavancar, mudança de jogo, "leve X para o próximo nível", "no mundo acelerado de hoje". Se uma frase pudesse aparecer em qualquer site, reescreva-a.

• Evite formas de frase de IA, bem como palavras de IA. Cuidado com:

  • cada título de seção construído na mesma fórmula de duas batidas ("Um binário. Escolha como obtê-lo.", "Recupere-o, agora ou então.");
  • "Sem X. Sem Y. Apenas Z.";
  • trigêmeos de adjetivos;
  • um trocadilho em cada título.

  Um rótulo simples ("Instalar", "Restaurar um snapshot") é frequentemente mais forte do que uma linha inteligente, e dá ao único título que é elaborado espaço para se destacar.

• Os rótulos dos botões dizem o que acontece: "Baixar o aplicativo", "Reservar uma mesa", "Agendar um reparo", não "Começar" ou "Saiba mais".

• Nunca apresente fatos inventados como reais. Sem preços, endereços, horários, estatísticas, depoimentos, logotipos de clientes ou "confiado por 10.000 equipes" inventados. Estes são os próprios projetos do usuário, e alegações fabricadas são um risco que tende a ser enviado por acidente. Quando uma seção precisar genuinamente de um fato que você não tem, coloque um substituto visível, como <span class="todo">[preço]</span> estilizado para se destacar, e liste cada um na entrega.

4. Construir

Tokens primeiro. Antes de qualquer componente, defina o sistema como propriedades personalizadas CSS no topo de styles.css: funções de cor, etapas de tipo, etapas de espaço, raios, sombras, medida de texto e temporizações de movimento. Gere a escala de tipo e espaço fluidas com:

node <skill-dir>/scripts/scale.mjs --min-ratio 1.2 --max-ratio 1.333   # escolha proporções para adequar à direção

Depois disso, use tokens em vez de números codificados. Números codificados se desviam, e o desvio é o que faz o espaçamento parecer ligeiramente errado em todos os lugares.

Os scripts precisam do Node 20 ou mais novo. Se node não estiver no PATH, execute-os com ~/.cache/killer-skills-node/node.exe em vez disso: o instalador do Windows coloca o Node lá quando está faltando.

Fontes. Auto-hospede-as a partir do pacote de fontes killer-skills, que tem cada face que references/typography.md nomeia:

node <skill-dir>/scripts/fonts.mjs list                       # famílias, com seus pesos ou eixos
node <skill-dir>/scripts/fonts.mjs add path/to/site "Newsreader" "IBM Plex Mono" --weights 400,600

add copia os arquivos e suas licenças para assets/fonts/ e escreve assets/fonts/fonts.css. Vincule essa folha de estilo antes de styles.css, e pré-carregue apenas a face da qual a primeira tela depende (o script imprime a linha). Não precisa de rede, e o site finalizado não solicita nada de um host de fontes. Se o pacote não estiver instalado ou não tiver a face, carregue-a do Google Fonts como references/typography.md descreve.

Arquivos. Para um novo site, a menos que o projeto determine o contrário:

site/            (ou onde o usuário ou projeto quiser)
  index.html
  styles.css
  DESIGN.md
  icon.svg, favicon.ico, apple-touch-icon.png, icon-192/512.png, icon-maskable-512.png, manifest.webmanifest
  assets/        (svg, images, fonts/)
  script.js      (o momento de impacto e pequenas interações; mantenha curto)

HTML. Use landmarks semânticas (header, nav, main, section com títulos, footer), um h1 e títulos em ordem. Use <button> para ações e <a> para navegação, e dê a cada campo de formulário um <label>. Cada página precisa de lang, a meta tag viewport, um <title> real, uma meta description, tags Open Graph e um conjunto completo de favicon e ícones de aplicativo.

CSS. CSS moderno simples, mobile first:

• grid e flex para layout, com padrões intrínsecos como repeat(auto-fit, minmax(min(100%, 18rem), 1fr)).
• Tokens fluidos via clamp(), e uma medida de leitura em torno de 60–70ch.
• Estilos :focus-visible que combinam com o design. Efeitos de hover vão dentro de @media (hover: hover).
• text-wrap: balance em títulos e text-wrap: pretty em parágrafos.
• @media (prefers-reduced-motion: reduce).

JavaScript. Use-o onde melhora a experiência: o momento de impacto, efeitos de ponteiro, um interruptor de tema que varre, uma demonstração ao vivo, uma alternância de navegação móvel (um <button aria-expanded>, ou <details>). Mantenha-o vanilla e escrito à mão nos próprios arquivos do site: sem frameworks, sem CDNs, nada carregado de outro lugar, e geralmente menos de cem linhas. Construa-o como um aprimoramento. O conteúdo deve ser visível sem JS. Nunca esconda seções em opacity: 0 enquanto espera um script revelá-las, porque quando o script falha, o conteúdo desaparece. Prefira CSS para qualquer coisa que CSS possa fazer (entradas, efeitos de digitação, cenas acionadas por rolagem).

Movimento. Movimento em todos os outros lugares permanece rápido e silencioso: transições de hover e foco de 150–250ms, pequenas entradas. Essa calma é o que permite que o momento de impacto se destaque. Cada animação fica dentro de @media (prefers-reduced-motion: no-preference) ou atrás de uma verificação matchMedia, e a versão de movimento reduzido é um design estático finalizado. Receitas e regras de desempenho estão em references/motion-and-wow.md.

Favicon e ícones de aplicativo. Projete o favicon tão a sério quanto o herói: é a peça mais vista do design. Em 16px, uma marca de palavra vira borrão, então a maioria das marcas precisa de uma versão reduzida para tamanhos pequenos, como uma letra em negrito ou uma forma, em um ladrilho que seja legível tanto em guias claras quanto escuras. Leia references/favicons.md. Em seguida, construa o conjunto a partir de um SVG e verifique-o:

node <skill-dir>/scripts/icons.mjs build mark.svg --out path/to/site --bg "#hex" --name "Site" --theme-color "#hex"
node <skill-dir>/scripts/icons.mjs audit path/to/site     # folha de pré-visualização: guias em 1x/2x, claro/escuro, telas iniciais

Visuais sem fotos de stock:

• Software: construa a interface real do produto em HTML e CSS, como uma sessão de terminal estilizada com comandos reais e saída, ou uma janela de aplicativo com dados realistas. É mais convincente do que qualquer ilustração e permanece na marca.
• Tipografia como imagem: títulos grandes, numerais, citações em destaque, um menu configurado como um cartão impresso.
• SVG e CSS: formas geométricas, diagramas, mapas, gráficos, padrões, textura de grão (um filtro SVG feTurbulence em baixa opacidade), ícones simples embutidos com uma largura de traço consistente.
• Cuidado ao desenhar coisas reais à mão. Comida, pessoas, animais, plantas, edifícios e ferramentas são onde o SVG codificado à mão falha com mais frequência. As proporções se desviam, e um detalhe (uma marca de risco em um pão, um destaque, uma mão) é lido como outra coisa e atrai o olhar pela razão errada. Uma ilustração desajeitada prejudica uma página mais do que não ter nenhuma. Portanto:
  • Prefira os visuais que o código faz bem: diagramas, layouts tipográficos, formas, padrões.
  • Se um conceito pede uma ilustração que o código não pode fazer bem (por exemplo, "um close de um violino"), e nenhum ativo de marca existe, coloque um espaço reservado visible como <div class="todo">[foto: close do violino]</div> estilizado para se destacar, e liste-o na entrega.

Enquanto constrói, não pare para pedir aprovação. Se uma escolha não pode ser inferida do que existe, faça a melhor escolha e anote-a para o usuário na entrega. O primeiro feedback útil vem de uma página renderizada.

5. Revisar e corrigir

Quando o HTML, CSS, JS, conjuntos de ícones e fontes estiverem montados, faça a página ser visualizada:

npx playwright install chromium 2>/dev/null; node <skill-dir>/scripts/capture.mjs path/to/site/index.html --out path/to/site/screenshots

Isso abre a página no Chromium, captura capturas de tela em três larguras (375, 768, 1280), imagens de layout completas (desktop e celular), e grava um GIF de 4 segundos em cada largura se houver qualquer animação declarada em CSS. As imagens vão para uma subpasta screenshots/ ao lado do HTML, e a ferramenta escreve um relatório screenshots/review.md com o resumo de cada largura e, para cada uma, uma pausa no layout da página encontrada.

Agora atue como revisor:

1. Leia o relatório de captura de tela em screenshots/review.md.
2. Abra cada captura de tela e GIF de layout completo em sua ferramenta de visualização. Olhe verdadeiramente para eles. Não assuma que o que você escreveu em CSS é o que renderizou. Encontre problemas reais.
3. Corrija cada um: ajuste CSS, quebras de linha, JS, conteúdo. O layout pode exigir voltar ao DESIGN.md. Execute novamente o script de captura para verificar suas correções.
4. Repita até que todas as capturas de tela estejam limpas: sem vazamentos, sem sobreposições, legíveis, o momento de impacto funcionando. Você pode notar que uma correção em uma largura quebra outra; essa iteração é o trabalho.
5. Quando as imagens estiverem prontas, faça o commit de tudo, incluindo screenshots/ e screenshots/review.md, para que o usuário possa ver o histórico de revisão.

Checklist de revisão:

• O título da página funciona? Soa específico? Está quebrado em um ponto de vista estranho?
• A hierarquia visual corresponde à hierarquia de conteúdo? O que é mais importante parece mais importante?
• O texto tem uma medida de leitura razoável (60–70 caracteres)?
• As proporções de contraste WCAG AA são atendidas (4.5:1 texto normal, 3:1 texto grande)? O contraste de foco é suficiente?
• Tudo que é clicável/tocável é grande o suficiente (~44px)?
• O layout do celular é bem espaçado? Nada está espremido ou estourado.
• O momento de impacto funciona sem JS e com movimento reduzido? Parece bom em todas as larguras?
• A animação é suave e não causa enjoo?
• A página parece completa: sem espaços reservados, sem lorem ipsum?
• A página carrega sem erros de console?
• O favicon e vários ícones de aplicativo estão presentes e corretos?

6. Finalizar e entregar

Comprometa tudo exceto screenshots. A menos que o usuário peça o contrário, screenshots são para iteração e revisão, não para o produto final. Se o site estiver sendo construído em um repositório, mova ou remova screenshots/ antes do commit final.

Produza a entrega como um arquivo HANDOFF.md na raiz do site com:

# Entrega: <projeto>

## O que foi construído
Breve descrição.

## Suposições
- Quaisquer decisões tomadas sem informação suficiente (por exemplo, "assumiu que o público principal são desenvolvedores porque o README começa com instruções de instalação").
- Quaisquer suposições que a direção de design fez que podem estar erradas.

## Por que essa direção
Por que a direção escolhida das três opções? Uma linha ou duas.

## Alternativas consideradas
As outras duas direções, bastante brevemente.

## Coisas a fazer (se houver)
- Conteúdo que precisa ser fornecido (preços, endereço, depoimentos, data de lançamento).
- Quaisquer imagens, logotipos ou marca real que devam substituir espaços reservados.
- Quaisquer recursos que o usuário possa querer adicionar (análises, um formulário, um blog).

## Detalhes de implantação
Dica rápida ou comando se o usuário perguntou sobre implantação. Por exemplo, para GitHub Pages, o site na está na pasta `docs/`.

## Notas técnicas
- Fonte: Newstrader e IBM Plex Mono, auto-hospedadas.
- O momento de impacto usa scroll-driven animation com fallback Intersection Observer.
- Sem dependências de runtime ou rede.

Se o repositório do usuário já tiver uma página GitHub Pages implantada (docs/ ou root), mova os arquivos do site para lá, certifique-se de que index.html esteja no nível correto e atualize o DESIGN.md para refletir o caminho final.

---

Redesenhando um site existente

Comece com uma etapa de inventário antes da etapa 1 acima.

Faça o inventário do que já está lá. Abra a página real (não o código) e observe-a com um olhar crítico, depois leia seu código. Trabalhe a partir de e compare capturas de tela para referência. Capture:

• Layout em várias larguras.
• Seções, seu propósito e quais podem ser consolidadas, cortadas ou movidas.
• Hierarquia de conteúdo: o que é mais importante?
• O que funciona bem e deve permanecer.
• O que está quebrado, desatualizado ou confuso.
• Conteúdo que deve ser mantido (texto real, marcas, etc.).
• A base de código: HTML semântico? CSS moderno? Dependências desnecessárias? Frameworks? JS personalizado?
• Presença e qualidade de favicon, ícones de aplicativo, meta tags, Open Graph.
• Desempenho e acessibilidade (problemas óbvios).

Anote o escopo aceito. O que o usuário especificamente pediu para ser redesenhado versus o que está sendo mantido, e por quê. Ofereça propor mudanças maiores na entrega, mas não as construa.

Planeje a migração de conteúdo. Se o site tiver páginas existentes além de index.html, planeje como o novo design se aplica a elas (um sistema de tema compartilhado, um arquivo CSS central) sem reescrever cada página, a menos que o escopo inclua isso.

Então prossiga com o passo 1: o conteúdo e a estrutura do site existente contam como "o que já existe".

---

Trabalhando dentro de uma marca existente

Quando uma marca existe, a direção de design não é inventada; ela é extraída. O trabalho muda:

• Extraia o sistema da marca (paleta, tipografia, tom, padrões de layout) do guia de marca, artefatos existentes e o código do site atual. Documente-o em DESIGN.md usando o mesmo modelo acima, mas rotulado como "Marca extraída", com quaisquer adaptações notadas.
• Siga a marca, mas aplique o hábito 2. Crie um momento de primeira tela que seja da marca e surpreendente. A marca fornece os materiais; você ainda precisa do design.
• Não invente uma nova marca paralela. Não adicione uma segunda paleta de cores, segunda tipografia ou segunda voz. Isso dilui a marca em vez de fortalecê-la.
• Quando a marca for insuficiente (por exemplo, apenas um logotipo e uma cor primária, sem tipografia, tom ou valores), trate-a como restrições parciais e preencha as lacunas com uma direção de design que complemente o que existe. Documente quais partes da marca foram inferidas.

Redesenhando um site de marca existente: Siga o processo de redesenho acima, começando com um inventário. O guia de marca é sua restrição primária. Mantenha ou coloque em conformidade todos os ativos de marca existentes. Se o site existente se desviar da marca, realinhe-o na reformulação.

---

O que faz um site parecer feito por IA

Os marcadores mais comuns de design de IA atualmente:

• Paletas previsíveis: verde-menta + roxo-ameixa, laranja-queimado + azul-marinho, qualquer combinação com violeta claro. O violeta claro é um dos sinais mais fortes de que o design não foi pensado.
• A silhueta de página genérica: herói grande, seção de recursos de três cards, seção de depoimentos, CTA, rodapé. Não importa quão bem executado, alguém que navegou nos últimos anos reconhece a estrutura imediatamente.
• Texto centralizado em todos os lugares, especialmente em layouts de desktop onde corpos longos de texto são centralizados e difíceis de ler.
• Fotos de stock como o único conteúdo visual, sem personalização ou sobreposição conceitual.
• Ícones em caixas circulares, especialmente quando a cor de fundo é um gradiente suave.
• A escolha de fonte padrão: Inter para texto, alguma variável serif para títulos, ou o que está na moda atualmente no momento do treinamento do modelo.
• Sistemas de design que parecem bootstrapped: bordas arredondadas em tudo, uma sombra consistente, sem variação de tom.
• Conteúdo que soa como se um modelo de linguagem o tivesse escrito (consulte a lista de palavras e padrões de IA acima).
• Uma completa falta de conceito subjacente e personalidade. O site não parece ser sobre nada.

Para se diferenciar: escolha um conceito específico e execute-o profundamente. Use uma paleta que não seja uma combinação comum de IA. Varie a silhueta. Escreva conteúdo específico do projeto. Faça uma escolha tipográfica ousada e bem pensada, e uma escolha de layout que se desvie do padrão. Adicione textura e, acima de tudo, o momento de primeira tela que faça alguém parar.