Communitygithub.com

UI moderna mínima

Constrói sites pessoais, portfólios, landing pages e blogs sóbrios em HTML, CSS e JavaScript, com tokens partilhados, receitas de página, tipo legível, movimento contido e uma verificação real de acessibilidade.

O que é UI moderna mínima?

Uma skill de acabamento para sites pequenos de conteúdo. Escolhe uma direção calma, define tokens e componentes, e entrega capa, página pessoal, índice e artigo, rápidos e legíveis.

Funciona com✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/pkafel/minimal-modern-ui-skill/tree/HEAD

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

UI moderno minimalista: sites mínimos que parecem prontos

Para sites pessoais, portfólios, landing pages e blogs: sites pequenos e centrados em conteúdo onde a moderação e o detalhe fazem o trabalho. Não para web apps, interfaces de produto, dashboards ou ferramentas; seus problemas (estado de aplicação, densidade de dados, formulários complexos) precisam de orientação diferente.

Tudo aqui é HTML, CSS e um pouco de JS vanilla, então funciona em qualquer stack ou sem stack alguma. Onde o projeto já tem uma estrutura de build ou templating, use-a; os princípios não mudam.

É uma bússola, não um template: cada regra dá o porquê e um ponto de partida que deve se adaptar ao assunto e ao gosto do usuário. Itens marcados como Firme são as poucas coisas que não devem ser ignoradas.

Arquivos de suporte (leia quando necessário):

  • references/snippets.md: blocos de construção prontos para copiar e colar (tokens, base, prosa, lista de posts, formulários, movimento).
  • references/interface-checklist.md: verificações detalhadas de interação, formulário, conteúdo e desempenho, adaptadas das Diretrizes de Interface Web da Vercel.
  • references/ship-checklist.md: SEO, preview social, RSS, analytics, hospedagem.
  • references/lessons.md: armadilhas e dicas de verificação em navegadores de projetos reais.
  • references/templates.md: medidas de 10 templates de landing page do Carrd (citados pelo número do template, ex. #304). Dados de referência para calibrar seu olho, não regras.

1. Fluxo de trabalho

  1. Entenda o trabalho. De quem é o site, para quem, a única coisa que um visitante deve fazer ou aprender, as páginas necessárias e o que significa "pronto". Pergunte quando a resposta altera a construção: o domínio final, se deve rastrear visitantes, quem é o dono do texto e se há conteúdo existente (posts, projetos) para trazer.
  2. Defina a direção (§2) e anote-a: tokens de cor, um par tipográfico, uma escala de espaçamento e raio, e uma personalidade de movimento, nas notas do projeto (CLAUDE.md, AGENTS.md ou README) para que sessões posteriores permaneçam consistentes.
  3. Configure as peças compartilhadas (§3) antes da primeira página: tokens, estilos base, primitivas de layout, componentes e uma fonte para o cabeçalho, rodapé e <head>. Cada página, incluindo a primeira, é construída a partir deles.
  4. Texto real primeiro. Texto placeholder esconde problemas de layout. Siga a receita da página (§4).
  5. Construa estático, responsivo e acessível, depois adicione movimento, depois polimento.
  6. Envie (§11), verifique em um navegador (§12), depois faça a passagem de moderação (§13).
  7. Itere em passos pequenos e visíveis. Uma mudança de cada vez, olhe para ela, peça opiniões de gosto em vez de adivinhar, diga claramente o que foi e não foi verificado, e só faça commit ou publique quando solicitado.

2. Escolha uma direção

O minimalismo é o padrão: conteúdo em primeiro lugar, um acento, espaço generoso, linhas finas em vez de caixas, pouco movimento. Cada elemento deve carregar significado; decoração que não carrega é removida.

FamíliaAparênciaGeralmente se encaixa em
Claro e silenciosoQuase branco, sem serifa neutro, divisores finos, um acento nítidoSites pessoais, blogs, escrita
Escuro e silenciosoQuase preto, tipo grande e leve, um acento, uma monoespaçada para metadadosSites de engenharia e pessoais, lançamentos
EditorialSerifada para exibição ou corpo, medida generosa, botões delineadosEscrita longa, livros, cultura; pode parecer datado para audiências de tecnologia, então mostre ao vivo primeiro
Brilho suaveBase silenciosa mais um gradiente sutil ou brilho radial, superfície fosca opcionalLanding pages que precisam de um pouco de calor
Um bloco ousadoBase silenciosa mais um bloco de cor sangrado ou foto emolduradaPortfólios, eventos, marcas pessoais
  • Tom vence novidade. Um assunto sério quer calma e credibilidade; fontes lúdicas e efeitos chamativos geralmente são rejeitados.
  • Combine com as convenções do público. Públicos de tecnologia tendem a esperar uma sem serifa neutra em quase branco ou quase preto com um acento nítido; outros públicos têm suas próprias convenções. Ao propor várias direções, faça com que elas difiram em layout e superfícies (página de lista, divisão fixa, grade de cartões, um bloco de cor), não apenas na fonte e na cor do papel, para que o usuário escolha entre alternativas reais.
  • Quando o gosto for desconhecido, teste ao vivo. Troque a fonte, o acento ou o espaçamento na página real e deixe o usuário reagir. Espere algumas rodadas.
  • O gosto do usuário está acima deste guia. Uma vez que ele aceite ou rejeite uma direção, anote-a nas notas do projeto e siga-a sobre qualquer padrão aqui.

3. Estilos e componentes compartilhados

Uma segunda página deve parecer com a primeira porque é construída a partir das mesmas peças, não porque os estilos foram copiados.

  • Uma fonte para tokens. Cores, escala de tipo, espaçamento, raios, sombras e temporizações de movimento são propriedades personalizadas em um arquivo. Páginas e componentes usam tokens, nunca valores brutos: um código hexadecimal ou tamanho de pixel avulso nos estilos de uma página é um bug a ser corrigido.
  • Estilize componentes, não páginas. .btn, .card, .field, .prose, .post-list, .site-header, não .about .blue-box. Variantes são modificadores (.btn--outline), nunca cópias editadas. Estilos de página apenas organizam componentes e permanecem curtos.
  • Camadas de CSS: tokens → base → primitivas de layout → componentes → arranjo da página, declaradas com @layer para que uma regra de página não possa silenciosamente superar um componente (veja snippets).
  • Escreva o cromo compartilhado uma vez. Cabeçalho, nav, rodapé, <head> e o script do site vêm de uma fonte: includes, parciais ou templates do projeto, ou um pequeno script de build. Cabeçalhos copiados à mão divergem; se a cópia for inevitável em um site de duas páginas, diga e verifique cada cópia após cada alteração. Marque a página atual na nav com aria-current="page".
  • Comportamento por marcação. Um script do site lida com revelações e disclosures através de atributos de dados e classes, para que uma nova página os receba sem JS por página.
  • Mantenha um inventário. Liste os componentes nas notas do projeto (nome, propósito, variantes). Em uma nova página, reutilize primeiro; qualquer coisa nova vai para os arquivos compartilhados e a lista, não para a página. Um styleguide.html mostrando cada componente em cada estado e tema é uma verificação rápida após alterações.
  • Apenas uma página hoje? Separe tokens e componentes dos estilos da página de qualquer maneira; a próxima página se torna montagem.

4. Receitas de página

Landing page

  • Hero: um título, uma frase de lead, a ação primária (ou o próprio formulário de inscrição) no primeiro viewport.
  • Em seguida, seções que respondem às perguntas do visitante em ordem: o que é, como funciona (passos numerados mais uma pequena imagem), prova (citações curtas, logotipos, números reais), FAQ, rodapé.
  • Não repita o pitch: se o hero contém o formulário, um bloco de fechamento repetindo-o não acrescenta nada.

Site pessoal / portfólio

  • Nome e uma linha sobre o que a pessoa faz, depois seções curtas: trabalho ou projetos, escrita, sobre, contato.
  • Listas com linhas finas são melhores que grades de cartões para projetos e posts; uma foto emoldurada é imagem suficiente.
  • Contato é um link simples (email, perfis), não um formulário, a menos que o usuário peça um.

Índice do blog

  • Uma lista, não cartões: título, data (<time datetime>), opcionalmente um resumo de uma linha. Agrupe por ano quando houver muitos posts. A linha inteira é o link, sem zonas mortas.
  • Sem thumbnails de stock. Paginação ou uma página longa funcionam; diga qual nas notas.

Post do blog

  • Uma coluna de leitura de cerca de 60–72 caracteres, corpo 17–19px com line-height 1.6–1.75 (§5).
  • Título, data e tempo de leitura opcional no topo; cabeçalhos com âncoras e scroll-margin-top; um índice apenas para posts longos.
  • Figuras com legendas podem quebrar mais largas que o texto; blocos de código rolam dentro de si, nunca a página.
  • Termine com um próximo passo: posts anterior/próximo ou uma lista curta de mais posts, mais o link RSS.

Compartilhado entre tipos

  • Cabeçalho: uma nav ou nada. Um único botão solitário oposto à marca parece inacabado.
  • Rodapé na parte inferior, também em páginas curtas (coluna flex de altura total), sem margem solta abaixo dele.
  • Projete cada estado: vazio (sem posts ainda), títulos muito longos, imagens ausentes, uma página 404 com a aparência do site.

5. Tipografia

  • Uma ou duas famílias: uma face de corpo neutra (uma pilha de sistema é suficiente) mais no máximo uma face de exibição. Uma monoespaçada para datas, código e metadados é uma terceira face apenas se merecer.
  • Cabeçalhos parecem modernos, grandes, leves e com tracking justo: cerca de 40–72px para o hero, peso 300–500, letter-spacing −0.02 a −0.05em para neo-grotesk, line-height 1.1–1.25, dimensionados com clamp().
  • Cabeçalhos de seção em uma página curta (site pessoal, índice do blog): cerca de 1.25× o corpo (≈20px), semibold, na cor do texto. Rótulos em maiúsculas claros são muito fracos; tamanhos de exibição competem com o hero.
  • Texto de leitura. 17–19px, line-height 1.6–1.75, medida de 60–72ch, parágrafos espaçados em cerca de 1em. Texto secundário usa uma cor neutra, não um tamanho menor.
  • Linhas limpas: text-wrap: balance em cabeçalhos, text-wrap: pretty em parágrafos para evitar palavras órfãs.
  • Detalhes tipográficos: aspas curvas (“ ”), o caractere de reticências (…), um espaço não separável entre um número e sua unidade (10&nbsp;MB), tabular-nums para datas e figuras em listas. Marque nomes de marcas e produtos com translate="no" para que a tradução do navegador os deixe intactos.
  • Wordmark: grande o suficiente para se sustentar ao lado de cabeçalhos de seção (geralmente 1.2–1.6×); um contraste de peso dentro de uma palavra (leve + extra-bold) adiciona caractere barato.
  • Texto justificado apenas com lang definido e hyphens: auto, e nunca em colunas estreitas.

6. Cor e superfícies

  • Tokens em :root: fundo, superfície, texto, neutro, uma cor de linha fina, um acento (opcional segundo ponto de gradiente) e uma cor sobre acento.
  • Contraste (Firme). Texto do corpo com pelo menos 4.5:1 (WCAG 2) na superfície real, verificado no ponto mais claro de superfícies translúcidas ou gradiente. Tipo de exibição leve precisa de mais. APCA é uma segunda opinião útil para tipo fino, não um substituto. Sempre defina cores de link; o azul padrão do navegador parece errado em quase todos os designs.
  • Acento para algumas marcas pequenas: uma palavra em um título, links, hover e focus, o item de nav atual. Não um bloco grande de cor, e não para numeração de lista.
  • Superfícies: planas com linhas finas por padrão. Sombras, quando usadas, têm duas camadas (ambiente suave mais uma direta mais justa); bordas podem ser semitransparentes para que as bordas permaneçam nítidas em qualquer fundo. Raios internos nunca são maiores que os do contêiner. Em um fundo colorido, tinge as bordas e sombras em direção ao seu matiz.
  • Hover e focus aumentam o contraste em relação ao estado de repouso.
  • Claro, escuro ou ambos. Decida cedo. Um esquema fixo é bom: defina color-scheme e theme-color para corresponder. Para ambos, redefina os mesmos tokens sob prefers-color-scheme: dark (mais uma substituição [data-theme] se houver um toggle) e verifique contraste, sombras, imagens e blocos de código em cada um.
  • Fundos: sólidos, ou um gradiente suave ou brilho; um padrão apenas com ≤10% de contraste. Nunca duas coisas altas.

7. Movimento

O movimento deve ajudar alguém a ver o que mudou ou para onde olhar. Nestes sites, menos geralmente é melhor.

  • Padrão: um fade-in curto do conteúdo principal no carregamento (alguns pixels de subida) e feedback de hover/focus. Uma página com apenas isso é um resultado completo e calmo.
  • Revelações de scroll são opcionais e permanecem sutis: opacidade mais 6–20px de movimento, ease, 0.3–1s, toque uma vez com cerca de 25% visível. Cascata por distância (cabeçalho move menos, botões mais); stagger de 100–150ms, limite de 6–8 itens. Nunca em conteúdo de leitura longa.
  • CSS primeiro, depois a Web Animations API, depois uma biblioteca JS apenas se realmente necessário.
  • Anime apenas opacity e transform, liste propriedades transformadas explicitamente (nunca transition: all), e defina transform-origin onde o movimento começa fisicamente. Para SVG, anime um <g> com transform-box: fill-box.
  • Interrompível: transições, não timelines fixas, para que um hover-out ou um segundo clique reverta suavemente.
  • Hover/focus: botões escalam cerca de 1.02–1.06 ou levantam; nav e links de texto recebem um sublinhado de 2px deslizando da esquerda, também em :focus-visible.
  • Movimento ambiente: no máximo uma volta lenta, ou nenhuma. Mídia em loop é um <video> silenciado, não um GIF, e movimento com mais de 5 segundos precisa de um controle de pausa.
  • Cintilação de vidro (Chrome): não faça fade dos filhos de um elemento backdrop-filter nem anime seu blur (veja lições).

8. Padrões de interação

  • Links são links. Navegação usa <a> para que nova aba, copiar link e clique do meio funcionem. Sem zonas mortas: se uma linha parece clicável, toda ela é.
  • Formulários (inscrição, contato): cada campo rotulado; type, name, autocomplete e inputmode corretos; spellcheck desligado para emails; validação nativa primeiro. Não bloqueie colar ou pressionamentos de tecla, e não desabilite o envio antes que o usuário tente. Erros ficam ao lado do campo, dizem como corrigir o problema, e o foco move para o primeiro erro ao enviar. Mais na checklist de interface.
  • Envio: o botão mantém seu rótulo e ganha um spinner, mostrado apenas após ~200ms e então por pelo menos ~400ms para que respostas rápidas não pisquem (veja snippets). Sucesso substitui o formulário por um próximo passo claro.
  • Divulgações (FAQ, "mostrar mais"): um <button aria-expanded aria-controls>, animado com o truque de grid-rows, estado fechado apenas quando JS executa.
  • Ajuda inline sobre tooltips. Explique no texto primeiro. Se uma tooltip for necessária, nunca confie em title; use uma personalizada em hover e focus, com um breve atraso antes da primeira e nenhum ao mover entre vizinhos.
  • Cópia: diga o que a página oferece nas palavras do visitante; botões dizem exatamente o que fazem ("Assine a newsletter", não "Enviar"); mensagens de erro dizem como se recuperar.

9. Linha de base de qualidade (Firme)

  • Movimento reduzido: com prefers-reduced-motion: reduce, revelações mostram instantaneamente e loops e scroll suave estão desligados.
  • Seguro sem JS: estados ocultos-ate-revelados vivem atrás de uma classe .js, para que nada permaneça invisível se JS falhar.
  • Teclado e foco: um link "Pular para o conteúdo", níveis de cabeçalho lógicos,

…

[truncado para tradução]

Habilidades Relacionadas