Mobile-first e breakpoints pensando em conteúdo

Desenhar primeiro pro espaço grande (desktop) e "encolher" depois pro celular costuma resultar em telas cheias de elementos que não cabem de verdade em pouco espaço — a solução vira empilhar tudo em uma coluna infinita, sem nenhuma decisão real sobre prioridade. Desenhar mobile-first inverte isso: você começa pelo espaço mais restrito, que naturalmente força a pergunta "o que é essencial aqui?".

Por que a restrição ajuda a priorizar

Numa tela de 375px de largura, não cabe tudo que cabia numa tela de 1440px — e essa limitação é uma vantagem disfarçada. Ela obriga a decidir, por exemplo, que uma barra lateral de filtros vira um botão que abre um painel só quando necessário, que uma tabela densa vira uma lista de cards com a informação mais importante visível e o resto atrás de um "ver mais". Fazer esse exercício de priorização primeiro, e só depois adicionar elementos extras conforme o espaço cresce, tende a produzir uma versão desktop mais enxuta também.

Breakpoint decidido pelo conteúdo, não pelo dispositivo

Uma tentação comum é escolher breakpoints com base em dispositivos específicos ("largura de iPhone", "largura de iPad"). O problema é que existem centenas de tamanhos de tela reais, e novos aparelhos surgem o tempo todo — não dá pra cobrir todos com breakpoints fixos por dispositivo. A alternativa mais estável é deixar o conteúdo decidir: aumente a largura da janela gradualmente e observe em que ponto o layout começa a ficar estranho (texto espremido, cards apertados demais, muito espaço vazio sobrando) — esse ponto, não um tamanho de aparelho, é o breakpoint certo.

.cards {
  display: grid;
  grid-template-columns: 1fr;
  gap: 16px;
}

/* em vez de "@media (min-width: 768px)" porque é a largura de um tablet
   específico, o valor abaixo foi escolhido observando que, a partir de
   640px, os cards já cabem lado a lado sem espremer o texto */
@media (min-width: 640px) {
  .cards {
    grid-template-columns: repeat(2, 1fr);
  }
}