Responsividade móvel para UIs geradas por IA: uma auditoria de layout

O que geralmente quebra no móvel (em termos simples)

Quando alguém diz que uma página não é "mobile friendly", geralmente quer dizer algo simples: ela carrega, mas é irritante ou impossível de usar num celular real.

Você reconhecerá os sintomas:

• Dá para deslizar para o lado porque algo é mais largo que a tela
• Texto é cortado ou se sobrepõe
• Botões e links são pequenos demais, muito próximos ou parcialmente fora da tela
• O layout pula quando imagens carregam ou quando o teclado abre
• Menus, modais ou dropdowns aparecem no lugar errado e prendem você

Isso acontece muito em protótipos gerados por IA porque muitas ferramentas criam uma UI que parece ok na pré-visualização desktop e depois a seguram com CSS frágil: larguras fixas, posicionamento absoluto e espaçamentos pixel-perfect. Elas também assumem um único tamanho de fonte, um único comprimento de conteúdo e uma única viewport. Celulares quebram essas suposições rápido.

Um exemplo realista: uma tela de onboarding usa um layout de duas colunas dentro de um contêiner fixo de 900px. No desktop parece limpo. No celular, a coluna da direita passa da borda, criando scroll horizontal. O botão "Continuar" fica abaixo da dobra e um texto legal se sobrepõe a um input porque o teclado reduz a viewport.

Se você quer responsividade, não redesenhe primeiro. Faça a auditoria antes, depois corrija na ordem certa: encontre o que força a página a ser mais larga que a tela, remova o CSS que trava elementos no lugar e só então ajuste espaçamentos e alvos de toque.

Configure um teste rápido e realista

Teste em dispositivos reais quando puder. Redimensionar a janela do desktop ajuda, mas pode esconder incômodos que celulares reais criam: a UI do navegador ocupando espaço, renderização de fontes diferente, safe areas e como seu polegar realmente alcança botões.

Escolha de 3 a 5 telas que representem todo o app (não cada página). Um bom primeiro lote é início/dashboard, login, configurações/perfil e uma "tela de dinheiro" como checkout, upgrade ou reserva. Corrigir essas costuma facilitar o resto.

Escolha alguns tamanhos comuns e mantenha-os para comparar antes e depois. Você não tenta cobrir todos os dispositivos, apenas os que revelam decisões fracas de layout:

• Telefone pequeno: 360 x 800
• Telefone grande: 390 x 844
• Telefone plus: 414 x 896
• Tablet: 768 x 1024
• Um tamanho intermediário vindo da sua análise (se tiver)

Defina o que "bom" significa antes de mexer no CSS: sem scroll lateral, texto legível sem zoom, botões fáceis de tocar e fluxos principais completáveis com uma mão.

Uma regra prática: se você não consegue finalizar login e a ação principal num celular real em menos de um minuto, o layout não está pronto.

Encontre as fontes de overflow e scroll horizontal

Scroll lateral quase sempre significa que um elemento é mais largo que a tela.

Reproduza o problema numa viewport estreita. Se você consegue arrastar a página para os lados mesmo que um pouco, algo está estourando.

Uma forma rápida de achar o culpado é contornar temporariamente tudo com outlines, então rolar para o lado e ver o que aparece além da borda. Quando você achar o card ou botão "misterioso" espiando, inspecione sua largura, padding e qualquer conteúdo filho que possa estar forçando maior largura.

As mesmas causas aparecem repetidas vezes: larguras fixas (como um contêiner definido em 420px), imagens grandes ou SVGs que não encolhem, strings longas sem quebras (emails, IDs, chaves) que não podem quebrar, tabelas largas e elementos posicionados absolutamente que se estendem além da viewport.

O overflow frequentemente se esconde em componentes que flutuam acima da página. Modais, dropdowns e toasts podem ter seus próprios contêineres com larguras fixas, padding extra ou animações que os empurram para fora da tela. Um modal pode parecer centralizado no desktop e ainda assim criar scroll horizontal no móvel porque seu conteúdo interno se recusa a encolher.

Uma regra que economiza tempo: prefira tamanhos flexíveis antes de adicionar mais breakpoints. Antes de empilhar mais @media, remova a restrição rígida que força o layout a ficar largo.

Exemplo: uma tela de onboarding tem um modal "Verificar código". O modal tem 480px de largura e o input do código mostra um placeholder longo. Em um celular de 375px, o modal vaza. Mudar o modal para max-width: 90vw e permitir que o placeholder quebre remove o scroll sem redesenhar nada.

Remova CSS frágil que força o layout a quebrar

A maioria das falhas móveis em frontends gerados por IA vem de CSS que assume um único tamanho de tela. As vitórias mais rápidas geralmente vêm de remover essas suposições.

Procure por larguras e alturas fixas que "parecem bem" no desktop, mas não podem encolher. Ofensas comuns são width: 1200px, min-width: 900px, height: 100vh em contêineres que deveriam crescer, e inputs/botões com tamanhos codificados. Se um card precisa ter certa largura, ele empurrará todo o resto para o scroll horizontal.

Outro problema comum é wrapper sobre wrapper. Ferramentas de IA frequentemente empilham contêineres que cada um adiciona padding, max-width e centralização. Três wrappers com 24px de padding cada podem roubar uma quantidade surpreendente de espaço útil num telefone pequeno.

Se você vê padrões como posicionamento absoluto para alinhamento, "números mágicos" como left: 37px, margens negativas para ajustar elementos ou regras globais como white-space: nowrap, trate-os como suspeitos. Substitua por regras flexíveis que possam respirar: max-width: 100% em vez de larguras fixas, height: auto quando possível e gap em vez de empilhar margins manualmente.

Exemplo: uma tela de onboarding onde o botão "Continuar" está posicionado absolutamente no fundo de um card. Num dispositivo pequeno, o teclado abre e o botão sobrepõe o formulário. Mudar o card para uma coluna flex e empurrar o botão com margin-top: auto o mantém no lugar sem sobreposição.

Faça os layouts se adaptarem com flexbox e grid

Código gerado por IA muitas vezes "funciona" só porque o conteúdo de exemplo tem o comprimento perfeito. Num celular real, o texto fica maior, botões quebram linha e o layout colapsa em sobreposição ou scroll horizontal.

Uma regra simples ajuda: use flexbox para layout unidimensional (uma linha ou coluna) e grid para layout bidimensional (linhas e colunas que devem se alinhar). Forçar tudo a um só recurso costuma tornar o código frágil.

Use flexbox para navbars, toolbars, linhas de botões e linhas "ícone + texto + ação". Use grid para galerias de cards, páginas de configurações com rótulos/valores e dashboards onde colunas precisam se alinhar entre linhas.

Duas escolhas de CSS resolvem a maior parte do trabalho com conteúdo real: permitir wrapping e permitir que o texto encolha sem quebrar a linha.

/* Card rows that wrap without odd gaps */
.cards {
  display: flex;
  flex-wrap: wrap;
  gap: 12px;
}
.card { flex: 1 1 260px; }

/* Grid that adapts to screen size */
.grid {
  display: grid;
  gap: 12px;
  grid-template-columns: repeat(auto-fit, minmax(220px, 1fr));
}

/* Mixed content row: icon + long title + button */
.row { display: flex; align-items: center; gap: 8px; }
.title { min-width: 0; flex: 1; }
.action { flex: 0 0 auto; }

Exemplo concreto: uma tela de onboarding tem um nome de plano longo e um botão "Continuar". Se o título não pode encolher, ele empurra o botão para fora da tela. Definir min-width: 0 no título e manter o botão flex: 0 0 auto evita overflow sem redesenhar.

Melhore legibilidade e alvos de toque sem redesenhar tudo

A maior parte da dor móvel não é um problema complexo de layout. É texto pequeno demais, espaçamento que colapsa e controles difíceis de atingir com o polegar.

Comece com alguns padrões sem graça que deixam todas as telas mais calmas: texto do corpo em 16px com altura de linha entre 1.4 e 1.6, headings reduzidos para não dominarem, e padding consistente em contêineres de página (geralmente 16px) para que o conteúdo não fique colado nas bordas.

Alvos de toque são a próxima vitória rápida. Muitas UIs geradas por IA produzem botões bonitos que fisicamente ficam minúsculos no celular. Mire em pelo menos 44x44px para alvos interativos, mantenha 8 a 12px entre ações separadas e adicione padding em links de texto para torná-los tocáveis. Também garanta que estilos de foco permaneçam visíveis em vez de serem cortados.

Formulários quebram com mais frequência do que landing pages. Mantenha labels próximas aos inputs, evite linhas de formulário em duas colunas em telas pequenas a menos que realmente caibam, e torne inputs full width no móvel. Reserve espaço para mensagens de erro para que a página não pule quando a validação aparecer.

Mudanças de layout muitas vezes vêm de toasts, banners e validação inline. Se mensagens aparecem e desaparecem, tente manter a altura consistente ou use uma área sobreposta para que o conteúdo não salte.

Exemplo: uma tela de onboarding com "Nome" e "Sobrenome" lado a lado frequentemente aperta ambos os inputs a larguras inutilizáveis. Mudar para uma coluna única, manter labels acima dos campos e dar ao botão Continuar um tamanho real de toque pode fazê-lo parecer pronto sem mudar o design.

Domine componentes complicados: imagens, tabelas e modais

Muito do que quebra no móvel vem de alguns repetidos culpados: imagens com tamanhos fixos, tabelas que assumem largura de desktop e modais que esquecem que celulares precisam rolar.

Imagens que estouram contêineres

Se uma imagem tem largura fixa (como 800px), ela pode forçar a página a ficar maior que o celular.

Deixe imagens reduzirem, mas não aumentarem. Na maioria dos casos, defina max-width de 100% do contêiner e deixe a altura seguir a proporção. Se o design precisa de um hero com altura fixa, recorte com segurança usando object-fit para que a imagem não estique.

Texto longo e sem quebras pode causar o mesmo scroll lateral. IDs de usuário, emails, links de convite, números de pedido e blocos de código frequentemente se recusam a quebrar. Aplique regras de quebra nas áreas de conteúdo para que strings longas quebrem linhas em vez de empurrar o layout.

Tabelas sem dor

Tabelas são difíceis em telas pequenas. Escolha uma estratégia por tabela baseado no que as pessoas realmente precisam fazer no móvel: permitir scroll horizontal da tabela dentro de seu próprio contêiner, empilhar cada linha em um layout estilo card ou mostrar um resumo curto com uma visão de detalhes.

Escreva qual escolha foi usada e por quê. Caso contrário, uma edição futura pode reintroduzir overflow silenciosamente.

Modais e drawers que permanecem utilizáveis

Modais geralmente quebram porque sua altura é fixa e a página atrás ainda rola. Um padrão mais seguro: limite a altura do modal à viewport, faça o corpo do modal rolar e mantenha o cabeçalho (título e fechar) visíveis.

Checagens rápidas que pegam a maioria dos bugs:

• O botão de fechar está visível e fácil de tocar em telas pequenas
• O conteúdo do modal rola, mas o fundo não
• O teclado não esconde o botão de ação primário

Exemplo: um modal de cadastro com um longo parágrafo de termos deve rolar dentro do modal, não expandir para fora da tela.

Uma auditoria de layout passo a passo que você pode repetir em cada página

Velocidade importa. O caminho mais rápido é auditar uma tela por vez e consertar a única coisa que tira o layout dos trilhos.

Escolha uma tela que claramente quebre num celular. Escreva os sintomas como um relatório de bug: "Tenho que rolar para o lado", "o botão primário está cortado", "o modal sai da tela", "o texto se sobrepõe ao input." Isso impede que você persiga mudanças CSS aleatórias.

Em seguida, isole o menor elemento que dispara a quebra. No DevTools, desative elementos até o problema desaparecer. Frequentemente é um filho com largura fixa, uma string longa sem quebras ou um componente que ignora seu contêiner.

Um fluxo repetível:

• Encontre o primeiro elemento que excede a largura da viewport
• Remova dimensionamento fixo (larguras em px, valores left/right fixos) e deixe o pai controlar a largura
• Prefira regras fluidas como max-width: 100% e width: 100% quando apropriado
• Adicione quebra para conteúdo longo (nomes, emails, textos de erro)
• Re-teste em um celular real e depois em uma largura de tablet

Exemplo concreto: uma tela de onboarding parece bem no desktop, mas no iPhone o botão "Continuar" sai da tela. Você inspeciona o footer e encontra um contêiner com width: 480px. Deletar essa regra e deixar o footer usar width: 100% corrige o scroll horizontal e traz o botão de volta.

Armadilhas comuns que fazem as correções falharem depois

As correções móveis mais rápidas muitas vezes parecem boas em um tamanho de tela, depois desmoronam quando conteúdo real aparece. Uma boa regra: se você teve que chutar um valor em pixels, provavelmente vai quebrar depois.

Um erro comum é adicionar mais breakpoints em vez de consertar o layout base. Breakpoints são úteis, mas se o layout base depende de larguras fixas ou de um wrapper desktop-first, você acaba corrigindo novos problemas em cada dispositivo. Comece com contêineres flexíveis primeiro, depois adicione um ou dois breakpoints para grandes mudanças.

Outra armadilha é usar overflow: hidden para fazer o scroll horizontal desaparecer. Isso pode esconder o sintoma enquanto corta botões, mensagens de erro ou outlines de foco. Em formulários, pode até ocultar texto de validação de modo que os usuários não consigam concluir o fluxo.

Alturas codificadas também são frágeis. Um card que parece perfeito em height: 420px vai cortar quando um nome for mais longo, uma mensagem de erro aparecer ou o usuário ativar um texto maior. Prefira fluxo natural de conteúdo e deixe a página rolar.

Regras de espaçamento conflitantes podem desfazer seu trabalho silenciosamente. Componentes gerados por IA frequentemente trazem suas próprias margins, paddings e line-heights, e então o CSS global adiciona mais. Quando um componente é enviado com suposições de espaçamento diferentes, o alinhamento deriva e o overflow volta.

Não pule testes em modo escuro e com zoom alto. Checagens rápidas que pegam falhas cedo: aumente o tamanho do texto para 200% e reverifique formulários e modais, ative o modo escuro e procure bordas invisíveis e textos de ajuda, e teste uma largura de celular pequena e uma grande.

Checklist rápido de usabilidade móvel

Use isso depois de corrigir overflow e CSS frágil. Ele pega as coisas que fazem a página parecer quebrada num celular real, mesmo que pareça bem no desktop.

Certifique-se de que a página nunca força movimento lateral. Abra suas telas-chave (landing, login, dashboard, configurações) e tente deslizar para esquerda e direita. Se algo se mover, algo ainda é mais largo que a viewport.

Então faça uma varredura de legibilidade e interação: parágrafos devem quebrar naturalmente, headings não devem ser cortados, você não deve precisar dar zoom para ler labels ou erros e botões não devem parecer apertados.

Um conjunto simples de checagens:

• Sem scroll horizontal nas telas-chave (incluindo dentro de modais)
• Texto quebra naturalmente (sem headings cortados ou blocos de texto com largura fixa)
• Alvos de toque seguros (botões e links não estão apertados)
• Formulários permanecem utilizáveis (inputs, dropdowns e estados de erro ficam na tela)
• Fluxos com uma mão funcionam (menus e modais não exigem taps de precisão)

Após qualquer mudança de UI, re-cheque apenas algumas coisas: uma viewport de 320px ainda funciona, com o teclado aberto você alcança o próximo campo e o botão de envio, estados de erro permanecem visíveis, estados de carregamento não esticam contêineres e o modo escuro continua legível.

Exemplo: se uma página de configurações gerada por IA adiciona um novo pílula "Upgrade to Pro", isso pode discretamente acionar overflow. Pegue cedo repetindo o teste de deslizar e a checagem em 320px.

Exemplo: resgatando uma tela de onboarding quebrada

Um caso comum: a tela de onboarding parece bem no desktop, mas no iPhone o card é cortado, a página rola para o lado e o botão "Continuar" fica embaixo do teclado.

Em um resgate, três causas principais criaram a maior parte do dano. O card principal tinha largura fixa (como 520px) e uma margem esquerda fixa, então não podia encolher. O campo de email permitia endereços longos que ultrapassavam o card porque a linha do input não podia encolher corretamente. E um modal de "Termos" usava altura fixa sem rolagem interna, então transbordava a viewport.

A auditoria começa reproduzindo o problema em tamanhos de dispositivo real, então encontrando o primeiro elemento que aparece além da borda. A partir daí, suba pela árvore de pais até achar o contêiner que se recusa a encolher.

As correções foram pequenas e focadas em remover dimensionamento forçado. O card passou de largura fixa para max-width com tamanho fluido, margens tornaram-se responsivas (centralizadas com margens laterais automáticas), a linha do input recebeu regras que permitiram encolher sem empurrar os elementos irmãos e o modal mudou de altura fixa para max-height baseada na viewport com rolagem interna.

Checagens de aceitação em celular e tablet foram diretas:

• Sem scroll horizontal em nenhum lugar, mesmo ao focar inputs
• O botão primário permanece visível acima do teclado
• O modal cabe na tela e rola dentro de seu próprio conteúdo
• Texto permanece legível sem zoom e alvos de toque são confortáveis

Próximos passos se sua UI gerada por IA continuar quebrando

Se problemas móveis voltam, o projeto normalmente carece de regras de layout compartilhadas. Algumas decisões agora previnem a próxima rodada de correções desfazerem as anteriores. Seja específico em uma nota "regras móveis":

• Sem larguras fixas em contêineres de nível de página (prefira max-width e dimensionamento fluido)
• Qualquer componente que possa transbordar deve lidar com isso de propósito (wrap, clamp ou scroll)
• Um sistema de espaçamento (um pequeno conjunto de gaps e tamanhos de fonte)
• Botões e inputs devem permanecer utilizáveis com polegares (altura confortável e rótulos claros)

Depois, corrija em uma ordem que crie estabilidade: elimine scroll horizontal primeiro, conserte formulários em seguida (inputs, erros, comportamento com teclado) e só então dê polimento às telas secundárias.

Se você herdou um front-end gerado por IA e continua batendo nas mesmas falhas de layout, pode ser mais rápido obter um diagnóstico claro do que realmente está forçando overflow e posicionamento frágil. FixMyMess (fixmymess.ai) foca em reparar apps gerados por IA de ferramentas como Lovable, Bolt, v0, Cursor e Replit, e uma auditoria rápida de código pode dizer exatamente o que está quebrando em dispositivos reais antes de você gastar tempo remendando sintomas.