designdifferently/design-differently

Design Differently (edição gratuita)

Você está revisando um frontend que provavelmente foi construído com um agente de IA. Seu trabalho é encontrar o que o faz parecer e parecer gerado, e corrigir isso no código. Você muda apresentação, texto e interação. Você não altera lógica de negócio, dados, roteamento ou backend.

Conteúdo

1. Fluxo de trabalho: etapas 1 a 6
2. Regras: Tipografia, Cópia, Visual, Movimento e efeitos, Overlays, Tooltips, Teclado, Componentes, Imagens, Landing, Sugestões para o proprietário, Alvos de toque
3. Padrões de detecção
4. Armadilhas
5. Relatório

O quão estritamente seguir cada parte:

• Exato: padrões de detecção, a pergunta na etapa 3, o formato do relatório e seu rodapé. Não os altere.
• Firme: as regras. Aplique-as como escritas; pule uma apenas quando ela não se adequar ao projeto, e explique o motivo no relatório.
• Seu julgamento: escolha de fontes de substituição, redação de pequenas edições de texto, qual movimento manter.

Copie esta lista de verificação em sua resposta e marque-a conforme avança:

- [ ] 1. Mapear o projeto
- [ ] 2. Escanear e capturar "antes"
- [ ] 3. Listar correções e deixar o usuário escolher
- [ ] 4. Corrigir os itens escolhidos
- [ ] 5. Verificar e capturar "depois"
- [ ] 6. Travar as regras no repositório e relatar

---

1. Mapear o projeto

Antes de tocar em qualquer coisa, descubra:

• Framework e abordagem de estilização (Tailwind, CSS Modules, styled-components, CSS puro, um kit de UI como shadcn ou MUI).
• Onde os tokens de design residem (variáveis CSS, configuração do Tailwind, arquivo de tema). Se não houver nenhum, anote.
• Onde os componentes compartilhados residem (Button, Dialog, Tooltip, Dropdown, Badge, Banner). Liste duplicatas que você notar.
• Se o projeto é um aplicativo (ferramentas, dashboards, editores) ou um site (landing, marketing, blog). Algumas regras se aplicam apenas a um deles.
• Como executá-lo e como executar suas verificações (lint, typecheck, testes).
• Se você pode tirar capturas de tela aqui (Playwright, uma ferramenta de navegador, um painel de pré-visualização) e se pode mostrar imagens neste chat.

Use o que o projeto já tem e combine com seu estilo de código. Não adicione bibliotecas nesta edição, exceto arquivos de fonte.

2. Escanear e capturar "antes"

Execute as buscas nos Padrões de detecção e leia as telas principais. Se seu ambiente não puder executar comandos de shell (construtores hospedados como Lovable, v0, Bolt), abra os arquivos e procure pelos mesmos padrões lendo. Para cada ocorrência, registre arquivo, linha e qual regra ela quebra. Uma ocorrência é um candidato, não um veredito: leia o contexto antes de contá-la.

Se você puder tirar capturas de tela, capture as telas principais agora, antes de qualquer alteração: home ou landing, a tela de aplicativo mais movimentada, um diálogo, um formulário. Use 1440×900 e 375×812. Salve-as em .design-differently/before/ com nomes como home-1440.png. Anote a rota e o estado exatos de cada uma, para que possa repeti-los mais tarde. Não commit esta pasta.

3. Listar correções e deixar o usuário escolher

Não altere nenhum arquivo antes desta etapa ser respondida.

Mostre os achados como uma lista numerada, agrupada sob cabeçalhos de área (Tipografia, Cópia, Visual, Movimento, Overlays, Tooltips, Teclado, Componentes, Imagens, Landing). Os números são contínuos entre os grupos. Uma linha por item: o que está errado, onde, e o que você vai mudar. Deixe de fora áreas sem achados.

### Tipografia
1. Inter usada como única fonte (app/layout.tsx). Substituir por uma sans menos comum.
### Cópia
2. 14 travessões em texto de landing (components/Hero.tsx, Features.tsx). Substituir por pontos, vírgulas ou dois-pontos.
3. Linha separadora "Rápido · Privado · Código aberto" no hero (components/Hero.tsx). Transformar em uma linha FUD com ícones.
4. Descrições de opção repetem seus rótulos em Configurações (settings/page.tsx). Remover.

Termine a lista exatamente com esta pergunta:

Responda "todos" para aplicar todas as correções, ou liste os números que deseja (por exemplo 1, 3, 5-9).

Em seguida, pare e aguarde a resposta.

4. Corrigir os itens escolhidos

Aplique apenas os itens que o usuário escolheu, uma área de cada vez, nesta ordem: Componentes, Overlays, Tipografia, Visual, Movimento, Tooltips, Teclado, Imagens, Cópia, Landing.

Altere componentes compartilhados e tokens primeiro, para que uma correção repare todas as telas que os usam.

Após cada área, execute as verificações do projeto (lint, typecheck, testes, build). Se uma verificação falhar, corrija-a antes de passar para a próxima área. Se a correção exigir alterações de backend ou lógica, desfaça esse item e marque-o como ignorado.

5. Verificar e capturar "depois"

Sua primeira passagem é um rascunho. Verifique-a com evidências externas, não com sua memória do que mudou:

• Se você puder tirar capturas de tela, repita cada captura "antes" com a mesma rota, estado e tamanho, e salve-a em .design-differently/after/ com o mesmo nome. Fotografe também qualquer outra tela que tocou. Olhe para cada uma. Se algo estiver cortado, sobreposto, ilegível ou pulando, volte para a etapa 4 para aquela área.
• Execute os padrões de detecção novamente. Se um padrão ainda ocorrer fora de uma exceção permitida, volte para a etapa 4.
• Releia cada string que você editou em relação às regras de Cópia. Se uma ainda quebrar uma regra, ou se você mudou mais do que a regra exigia, volte para a etapa 4.

6. Travar as regras no repositório e relatar

As correções devem sobreviver a futuros "vibecoding". Qualquer agente que editar este projeto mais tarde deve ver as regras antes de escrever código, ou trará os artefatos de volta.

1. Crie DESIGN_RULES.md na raiz do projeto. Escreva-o para um agente de IA, curto e imperativo, com menos de 150 linhas. Inclua apenas o que se aplica a este projeto:
   • As fontes escolhidas, seus arquivos e onde são declaradas, e o caminho da fonte do logotipo (A ou B), se aplicável.
   • Onde os tokens residem e a regra de que cores, raios, espaçamento, sombras e tamanhos de fonte vêm apenas deles. As cores primária, secundária e de acento opcional pelo nome do token, e a regra de que cores destrutivas e de sucesso são apenas para esses estados.
   • Onde os componentes compartilhados residem (Button, Dialog, Tooltip, Dropdown, Badge, Banner) e a regra de reutilizá-los, nunca duplicá-los.
   • Cada regra desta skill que você aplicou, como uma linha cada, com o detalhe concreto deste projeto (por exemplo "Tooltips: usar components/ui/Tooltip.tsx, 2 ou 3 palavras mais atalho").
   • A lista banida: fontes, emoji, travessões, separadores decorativos, aspas para ênfase, vidro em grandes superfícies, fade-in e blur-in padrão, caixas de ícone com fundo colorido, chamadas com barra de acento, sobrancelhas em letras maiúsculas espaçadas, pontos de status ao vivo, controles e scrollbars padrão do navegador.
   • Uma última linha: "Antes de finalizar qualquer alteração de UI, verifique-a em relação a este arquivo."
2. Aponte cada arquivo de instrução de agente no projeto para ele. Adicione uma linha, Siga DESIGN_RULES.md para cada alteração de UI, texto ou estilo., a cada um destes que existir: CLAUDE.md, AGENTS.md, .cursorrules, .cursor/rules/*.mdc, .windsurfrules, .github/copilot-instructions.md, replit.md. Se nenhum existir, crie AGENTS.md e CLAUDE.md com essa linha. Não altere mais nada nesses arquivos.
3. Se DESIGN_RULES.md já existir de uma execução anterior, atualize-o em vez de criar um novo. Mantenha regras que o usuário adicionou manualmente.

Em seguida, publique o relatório de Relatório como sua mensagem final no chat.

Se o usuário corrigir uma de suas correções durante a sessão, adicione uma linha em Armadilhas neste arquivo descrevendo a correção, para que a próxima execução não a repita.

---

Regras

Tipografia

Ferramentas de IA recorrem ao mesmo punhado de fontes, então essas fontes por si só fazem um projeto parecer gerado. Não use nenhuma fonte desta lista, em qualquer função, a menos que faça parte de uma diretriz de marca que o usuário lhe forneceu ou as regras de fonte do logotipo abaixo se apliquem:

Função	Fontes banidas
Sans	Inter, Inter Tight, Geist, Roboto, Open Sans, Poppins, Montserrat, Lato, Manrope, DM Sans, Plus Jakarta Sans, Outfit, Figtree, Urbanist, Sora, Lexend, Nunito, Nunito Sans, Raleway, Work Sans, Rubik, Onest, Space Grotesk, Satoshi, General Sans, Cal Sans, Bricolage Grotesque, Syne, IBM Plex Sans, Source Sans 3, Arial, Helvetica como face escolhida
Serif	Playfair Display, Instrument Serif, Fraunces, DM Serif Display, Lora, Merriweather, Cormorant Garamond, EB Garamond, Libre Baskerville
Mono	JetBrains Mono, Geist Mono, Fira Code, Fira Mono, Space Mono, Roboto Mono, IBM Plex Mono, Source Code Pro, Ubuntu Mono
Padrão	Um system-ui puro ou pilha padrão do Tailwind usado porque nada foi escolhido

Fonte primária. A fonte primária é a fonte definida no logotipo, ou uma fonte que o usuário definiu. O resto do sistema tipográfico segue a partir dela.

Fonte do logotipo. Se o logotipo estiver definido em uma fonte (um logotipo de texto, um componente de marca nominativa, ou uma fonte nomeada no CSS ou SVG do logotipo), essa fonte permanece no logotipo mesmo que esteja na lista banida. Em seguida, escolha um dos dois caminhos e diga qual no relatório:

• A. Seguir o logotipo. A fonte do logotipo torna-se a fonte primária para o site e você deve usar exatamente essa fonte.
  • Logotipo em uma serifada: use exatamente a mesma serifada para títulos. O corpo do texto é uma sans.
  • Logotipo em uma sans: títulos podem usar uma serifada apenas se o caráter da marca claramente se adequar, o que é uma escolha arriscada. Caso contrário, os títulos permanecem sans, idealmente exatamente a fonte do logotipo ou uma muito próxima a ela.
• B. Apenas logotipo. A fonte do logotipo permanece apenas no logotipo e você escolhe as fontes para o resto. A fonte do logotipo ainda conta para o limite de fontes abaixo.

As regras de fonte do logotipo se aplicam apenas a um logotipo projetado de propósito. Se o logotipo for gerado por código (veja Sugestões para o proprietário), seu texto é apenas a fonte padrão, então dê a ele sua nova fonte de título e adicione o logotipo à seção Para você.

Regras de pareamento.

• Uma ou duas fontes em todo o site, logotipo incluído. Nunca mais.
• Nunca duas serifadas.
• Fonte primária é uma serifada: toda serifada no site é essa mesma serifada, e o corpo do texto é uma sans. No máximo duas fontes.
• Fonte primária é uma sans: todo texto no site usa essa mesma sans. Você pode adicionar uma segunda sans apenas como uma distinção para alguns títulos.
• Blocos de código, se o produto os tiver, usam a pilha monoespaçada do sistema (ui-monospace, SFMono-Regular, Menlo, monospace), que não conta como fonte escolhida.

Escolhendo fontes. Quando não houver fonte de logotipo e nenhuma fonte do usuário, escolha a fonte primária você mesmo e aplique as regras de pareamento:

• Leia o produto primeiro: o que faz, quem usa, que tom a cópia tem. Escolha uma face cujo caráter se encaixe nisso, e escreva uma frase no relatório sobre o motivo.
• Evite a segunda escolha óbvia. Se uma fonte é a primeira que você pensa para este tipo de produto, provavelmente está a caminho da lista banida. Escolha uma face menos comum com a mesma função.
• A licença deve permitir uso comercial gratuito na web (SIL Open Font License ou similar). Fontes: Google Fonts além dos primeiros resultados, Fontshare, Velvetyne, Collletttivo, The League of Moveable Type, famílias gratuitas de fundições.

Para cada fonte no site:

• No máximo três pesos por família.
• As fontes vivem no repositório. Baixe os arquivos woff2 para o projeto (por exemplo public/fonts/) e carregue-os com @font-face, next/font/local ou pacotes @fontsource/* empacotados no momento da construção. Nunca carregue fontes em tempo de execução do Google Fonts, Adobe Fonts, Bunny ou qualquer outro host externo, porque cada visualização de página envia dados do visitante para esse host. Remova todo link fonts.googleapis.com, fonts.gstatic.com, use.typekit.net, @import e importação next/font/google, incluindo para fontes que você mantém. Use font-display: swap.
• Mantenha uma pilha de fallback sensata após a face escolhida.
• Defina as fontes em um só lugar (tokens, fontFamily do Tailwind, CSS raiz) e remova toda outra declaração de fonte.

Cópia

Edite o texto com mão leve. Não reescreva textos, mude seu significado, tom ou extensão, ou adicione novas frases. Remova as marcas de IA listadas abaixo e suavize a sintaxe apenas onde a remoção a deixe quebrada. Se uma frase ficar legível depois que a marca for removida, pare por aí.

O que remover:

• Travessões e meios-traços espaçados (—, –). Substitua por um ponto, vírgula ou dois-pontos, o que mantiver a frase mais próxima do original.
• Aspas usadas para ênfase, ironia ou paráfrase. Remova-as e mantenha as palavras. Aspas permanecem apenas ao redor de uma citação exata, palavra por palavra.
• Separadores decorativos como ·, •, | ou / usados para unir frases. Remova-os completamente. Nunca os substitua por pontos ou outra pontuação. O que acontece com as frases depende de onde estão:
  • Hero, cards de preço, linhas-chave de venda: transforme as frases em uma linha FUD, uma fileira horizontal de itens curtos, cada um com um pequeno ícone antes de seu rótulo. Use o conjunto de ícones do projeto, ou SVG inline se não houver nenhum. Um tamanho e uma cor sólida para todos os ícones, sem caixa de fundo atrás deles (veja regras Visuais). A linha quebra de forma limpa no celular.
  • Parágrafos secundários, texto de ajuda, legendas, rodapés: exclua os separadores. Mantenha as frases apenas se elas ainda fizerem sentido como texto simples sem eles; caso contrário, mantenha a frase mais importante e descarte o resto.
• Construções "Não apenas X, mas Y" e seus parentes: "Não é X, é Y", "Mais que X", "X, sem o Y". Mantenha a metade positiva.
• Descrições que repetem o rótulo, e descrições sob opções que não precisam de uma. Remova-as.
• Descrições de venda ou sugestivas em UI funcional. Torne-as curtas e neutras, como no macOS ou Photoshop: diga o que é ou faz.

Exemplos:

Antes	Depois
Feito para equipes — não apenas para indivíduos.	Feito para equipes.
Hero: Rápido · Privado · Código aberto	Linha FUD de três itens: ícone de raio + Rápido, ícone de cadeado + Privado, ícone de código + Código aberto. Ícones SVG do conjunto do projeto, nunca emoji
Ajuda: Atualizado diariamente · 2 min de leitura	Atualizado diariamente
Seu "segundo cérebro" para notas	Seu segundo cérebro para notas
Não é um app de tarefas, é um sistema.	Um sistema para suas tarefas.
Modo escuro — Mude para um tema mais escuro que é mais suave para seus olhos à noite.	Modo escuro sem descrição
Salvamento automático: Nunca mais perca seu trabalho com salvamento automático contínuo!	Salvamento automático: Salva alterações conforme você digita.

…

[truncado para tradução]