toothpick

Toothpick: remova o sabor de IA e entregue uma interface que se sustenta

O que é este guia

Aqui não existem regras como "sempre use esta fonte" ou "nunca use aquela cor". Você pode usar qualquer cor, tipo de letra ou layout.

Ele faz duas coisas:

1. Ajuda a reconhecer o sabor de IA: quais escolhas são padrões impensados de uma IA e por que as pessoas os identificam instantaneamente.
2. Ajuda a evitar falhas comuns: os erros que fazem uma interface parecer tosca, barata ou pouco profissional.

Há um teste: essa escolha foi feita para este produto, ou você a teria feito para qualquer produto? A segunda opção é o sabor de IA.

O estilo explícito do usuário, as diretrizes de marca e o estilo de código existente sempre vencem, mesmo quando o que ele pede é um dos "sabores de IA" listados abaixo.

---

O que é o sabor de IA

Em cada decisão de design, uma IA tende para a opção mais comum. Ele aparece em duas camadas.

Camada um, os velhos clichês: gradientes de roxo para azul, emojis como ícones, cartões arredondados idênticos com sombras cinzas, a página de destino "título centralizado mais três cartões de funcionalidades", textos como "desbloqueie possibilidades ilimitadas". Muitas pessoas já reconhecem esses.

Camada dois, fingindo ter bom gosto: quando instruída a "não parecer IA", a IA muda para outra roupa igualmente fixa:

• Fundo de papel creme, título grande em serifa, acento terracota ou vermelho escuro, posando como "aconchegante e de bom gosto"
• Fundo quase preto, um acento verde néon, âmbar ou vermelhão, monoespaçada em todo lugar, posando como "hacker"
• Traços finos pretos estilo jornal, raio de borda zero, colunas densas, posando como "suíço e profissional"
• Um rótulo em maiúsculas acima de cada título, strings com "·" (ponto médio) em todo lugar, "→" após cada link, monoespaçada para cada rótulo de dado pequeno, "01 / 02 / 03" em conteúdo que não é uma sequência
• Números decorativos enormes, assimetria por si só, um prompt "$" de terminal ou um ponto de status "●" usado como decoração

A camada dois é mais difícil de notar porque parece "projetada". É o mesmo problema da camada um: o estilo foi colocado, não surgiu do produto.

A lista completa, com por que cada item soa como IA e quando é realmente aceitável, está em references/ai-tells.md.

Como são as boas interfaces

references/benchmarks.md tem medições da Vercel, GitHub, ChatGPT, Google e Linear, além dos produtos chineses DingTalk, Juejin, WeChat Read e sspai, e como as interfaces chinesas diferem (títulos mais pesados, altura de linha maior, tamanhos menores). O que as referências em inglês compartilham:

• Muito poucas cores: quase inteiramente preto, branco e cinza, mais uma cor funcional
• Uma família tipográfica; títulos são grandes, mas não pesados
• Separação leve: espaços em branco, contornos finos pálidos, sombras muito fracas, não regras pretas e sombras pesadas
• O produto em si é o herói; decoração é quase zero
• Um ponto focal por tela

Estas são uma referência, não um modelo. Uma cafeteria não deve parecer a Vercel, mas deve ser igualmente contida e precisa, com o conteúdo à frente.

A referência pode se tornar o novo padrão. Se seus últimos projetos, com seus nomes cobertos, todos resultam em branco, cinza neutro, botões em pílula e painéis com bordas finas, a referência se transformou em modelo. Use-a para calibrar o ofício: quão leve é uma linha, quão suave é uma sombra, quão fino é um título. Cor, material e o herói vêm da lista na etapa 2.

---

Fluxo de trabalho

0. Primeiro, dimensione a mudança

Mudança	Exemplos	Quais etapas
Pequena	Uma alteração de cor, espaçamento ou texto; corrigir um componente; adicionar um botão	Leia o código relevante e as variáveis de estilo, altere no estilo existente, verifique as poucas entradas relevantes em references/ai-tells.md e entregue com uma ou duas frases (uma lista de placeholders apenas se houver placeholders)
Média	Uma nova página ou as telas de um novo recurso dentro de um produto existente	Etapa 1, um plano de três ou quatro linhas, depois etapas 5 a 7. Mantenha o estilo existente do produto; pule o inventário e a argumentação
Grande	Um novo produto, um site, uma landing page, um redesenho	Todas as sete etapas

Em caso de dúvida, escolha o tamanho menor; o usuário pedirá mais. Não escreva um plano de design para um único botão.

1. Entenda o que é isso: leia o projeto primeiro, depois o visitante

• Em um projeto existente, leia-o antes de tocar em qualquer coisa. Antes de qualquer plano ou código, descubra:

  • Quais recursos o projeto realmente tem (leia o README, rotas, páginas e API; não adivinhe a partir de títulos de página)
  • Componentes existentes, variáveis de estilo, conjunto de ícones e fontes. A nova IU os utiliza; não inicie um sistema paralelo
  • O modelo de dados e os campos reais que a API retorna. Construa a IU com base nesses campos
  • O vocabulário existente no texto. Mantenha o mesmo nome para a mesma coisa

  Escreva em algumas linhas "o que o projeto tem" e baseie o plano nisso. Para qualquer coisa que você não possa ler (por exemplo, o backend não está no repositório), pergunte ao usuário ou declare sua suposição claramente.

• Qual é o produto ou conteúdo? Para quem é? Se não estiver claro, faça uma suposição concreta, diga-a em uma linha e siga em frente em vez de perguntar repetidamente.

• Decida o modo desta página (julgue a página, não o produto: a página inicial de uma ferramenta de desenvolvedor é Persuadir, seu painel é Operar):

Modo	O que sucesso significa para o visitante	Exemplos	Para onde vai o esforço de design
Persuadir	Decide e age	Página inicial, landing page, campanha, preços	Um ponto de vista e impacto; persuadir com imagens reais
Operar	Conclui uma tarefa	Admin, painel, editor, configurações, ferramentas	Escaneável, consistente, eficiente; a personalidade vive em detalhes precisos
Ler	Entende o conteúdo	Documentação, artigos, central de ajuda, changelog	Estrutura clara, uma experiência de leitura confortável
Vitrine	Está imerso no trabalho	Portfólio, galeria, estudos de caso	O trabalho lidera, a interface recua

Referências correspondentes: Persuadir e Vitrine usam references/web.md, Operar usa references/app-desktop.md, mobile adicionalmente usa references/mobile.md. READMEs de projetos e os mapas mentais ou diagramas dentro deles usam references/readme.md.

• Refinamento ou redesenho? Um refinamento mantém o estilo, texto e comportamento existentes e altera apenas o que está no escopo. Um redesenho substitui a aparência geral, mas mantém fatos do produto, conteúdo e recursos. Não aplique um novo estilo pela metade sobre o antigo.

2. Inventarie o que pertence apenas a este assunto

Escreva de 8 a 12 coisas concretas que pertencem a este cliente e a nenhum concorrente: o nome e o que significa, a rua e a cidade, o número da porta e a placa da loja, materiais e cores, seus números (lugares, altitude, anos no mercado), suas restrições (um lote por mês, fechado no inverno), seus rituais (o forno é aceso às cinco), as coisas impressas do seu mundo (recibos, etiquetas, horários).

As ideias de design vêm desta lista, não de "como os sites deste setor geralmente são". Uma habilidade de código aberto que consultamos realizou testes cegos: as páginas vencedoras usaram itens de tal lista; as páginas perdedoras tinham boas composições baseadas em ideias genéricas do setor.

3. Escreva o argumento antes de escolher as seções

Cada seção de uma página de marketing deve ser uma afirmação mais sua evidência, uma linha cada:

Herói: três torras esta semana, enviadas na sexta → evidência: três sacos, a data da torra
Grãos: cada um tem uma origem e sabor claros → evidência: origem real, altitude, notas de degustação
...

Exclua qualquer seção sem uma afirmação. Isso o mantém fora da estrutura padrão "herói, parede de logotipos, três funcionalidades, depoimentos, preços, FAQ".

4. Escreva um plano curto

• Cor: 4–6 valores, cada um com onde é usado
• Tipo: quais tipografias e o que cada uma faz
• Layout: uma frase sobre a ideia, um wireframe ASCII simples se útil, e o alinhamento
• Herói: a coisa mais persuasiva nesta página e quais ativos você realmente tem (não projete em torno de imagens que não existem)
• Intensidade: contido (o padrão para Operar e Ler), um herói (o padrão para Persuadir: uma imagem ousada do inventário, todo o resto quieto), ou um conceito completo (veja "Quando se comprometer com um conceito forte" abaixo)

5. Verifique o plano: padrão ou escolha?

• Dado um briefing semelhante, eu chegaria aproximadamente ao mesmo plano? Se sim, essa parte é um padrão; volte à lista da etapa 2 para ideias.
• Isso atinge algo em references/ai-tells.md? Se sim, mude-o, ou seja capaz de dizer por que este produto precisa disso.
• Há mais decoração do que conteúdo?

Diga brevemente em sua resposta o que você mudou e por quê.

6. Construa

• Gerencie cores e espaçamento com variáveis CSS. Cuidado com a especificidade dos seletores para que as classes não se sobrescrevam (especialmente o padding das seções).
• O conteúdo de exemplo é real e específico, e os números somam.
• Quando a página mostra a interface do produto (por exemplo, o espaço reservado para captura de tela em uma página inicial de SaaS), construa-o como um fragmento real desse produto: dados reais, números que somam, uma descoberta clara. Não blocos cinzas e números falsos.
• Detalhes de ofício estão em references/craft-details.md.

7. Olhe o resultado, corrija em lotes, depois remova uma coisa

• Olhe em tamanhos reais: desktop, telefone (cerca de 375px), modo escuro se você o construiu. Olhe uma vez, corrija tudo junto; não tire capturas de tela após cada ajuste.
• Percorra checklist.md.
• Como verificar o espelho antes de sair de casa, remova um acessório.
• Quando você não puder ver o resultado (o modelo não pode ler imagens, ou não há navegador): não finja que olhou. Em vez disso, revise o código: o texto mais longo cabe na coluna em cada ponto de quebra, qual é a taxa de contraste calculada a partir dos valores de cor, todos os estados de interação estão escritos? Diga em sua entrega que você não viu em um navegador e peça ao usuário uma captura de tela de desktop e uma de telefone para outra passagem.

Conter não é vazio

Remover decoração é apenas metade do trabalho. Uma página que perdeu rótulos, linhas e cartões e não ganhou nada em seu lugar parece magra, e pode perder para uma página mais rica que ainda tem algum sabor de IA. A outra metade é substância: escala tipográfica mais ousada, campos inteiros de cor, imagens reais do mundo deste assunto, cada seção preenchida com seu conteúdo completo.

Quando se comprometer com um conceito forte

Conter é o padrão, não o teto. Um conceito visual de página inteira (uma história em quadrinhos, um jornal, um desenho técnico, um ingresso) é adequado quando todos estes itens são verdadeiros:

• Tem uma fonte: o usuário pediu, ou o próprio mundo do assunto fala esta linguagem (os desenhos de um arquiteto, as provas de uma gráfica, um horário ferroviário) e você pode encontrá-la na lista da etapa 2
• Cada dispositivo mapeia para conteúdo: escreva o mapeamento, por exemplo "linhas de velocidade: solicitações se acumulando", "densidade de retícula: quão pesada é a fechadura". Descarte qualquer dispositivo que você não possa mapear
• Ainda lê com precisão: código, números, tabelas e botões ainda podem ser lidos e clicados sem erro. O conceito serve ao conteúdo e nunca faz as pessoas interpretarem mal
• Os fatos não mudam: um novo estilo mantém todos os fatos do produto, recursos, números e a lista de placeholders
• Sabe onde parar: use-o totalmente na linha principal e mantenha-se contido nos detalhes; não coloque um elemento temático em cada canto

Se falhar em algum destes, volte para um herói: use a linguagem apenas no herói ou em uma seção. A diferença de uma fantasia de estilo: uma fantasia serve a qualquer produto (creme e serifa, quase preto e néon, linhas finas de jornal); um conceito forte só faz sentido para este.

Ao entregar, explique a ideia de design em uma ou duas frases para que o usuário possa redirecionar facilmente, e anexe a lista de placeholders (veja "Não finja nada, não engane nenhum desenvolvedor").

Quando o usuário pede mudanças

O usuário diz	Significa
Mais ousado	Contraste de escala maior, campos inteiros de cor, um herói maior. Não mais decoração
Mais quieto / muito ocupado	Menos cores e menos movimento, menos tamanhos de tipo, remova elementos secundários
Simplifique	Exclua seções e elementos sem uma afirmação; mantenha o essencial
Mais polimento	Ofício: alinhamento, espaçamento, raio, sombras, estados, partes nativas do navegador
Está pronto para enviar?	Erros, estados vazios, conteúdo muito longo, outros idiomas, casos extremos

---

Não finja nada, não engane nenhum desenvolvedor

Usuários e desenvolvedores devem ser capazes de dizer o que é real e o que ainda não foi feito.

Nada falso na frente dos usuários finais

• Nenhum logotipo inventado, parede de logotipos de clientes ou selos de parceiros. Nenhum logotipo falso montado a partir de símbolos como "$", "▲" ou "●"; sem logotipo, o nome do produto em texto simples é suficiente.
• Nenhuma contagem de usuários, taxas de satisfação, números de crescimento, depoimentos ou menções à imprensa inventados.
• Verifique fatos profissionais (detalhes técnicos, padrões, regulamentações, medicina, finanças, estatística). A IA escreve estes fluentemente, e seus erros parecem igualmente fluentes:
  • Liste as afirmações profissionais na página. Consulte o que puder na documentação ou padrões e cite a fonte em um comentário de código
  • O que você não puder confirmar, deixe de fora ou liste sob "Não verificado" na lista de placeholders
  • Os números na página devem concordar entre si (70 solicitações por segundo durante 41 segundos são 2.870 solicitações)

Nada que engane o desenvolvedor

• Nenhum recurso inventado: todo recurso mostrado na interface existe no projeto ou foi explicitamente solicitado. Não adicione "recomendações inteligentes" ou "exportação com um clique" para fazer a página parecer melhor.
• Dados fictícios nunca se passam por dados reais: conecte a API real quando puder. Quando não puder, mantenha os dados fictícios em um lugar (por exemplo, mock/), com os mesmos campos da API real, e marque-os como fictícios no código. Não codifique números atraentes em componentes para que a página pareça "pronta".
• Nenhuma interação falsa: um botão, formulário ou link que não está conectado não deve ter uma animação de clique que finge que funciona. Desabilite-o e rotule-o como "não conectado", ou liste-o nas notas de entrega.
• Demonstrações e conceitos construídos do zero podem usar uma marca e dados fictícios, mas a página deve dizer que é um exemplo.

Anexe uma lista de placeholders

...

[truncado para tradução]