Como verificar um design responsivo
Uma lista de verificação de design responsivo deve mostrar se a pessoa consegue concluir uma tarefa em diferentes tamanhos de tela. Uma captura de tela organizada da versão móvel é uma evidência útil, mas não revela se o menu fecha, se a comparação continua compreensível ou se o botão de envio desaparece atrás do teclado.
Comece pela tarefa e examine o layout enquanto a executa. Em uma página de marketing, isso pode significar entender a oferta, comparar planos e encontrar o próximo passo. Em uma interface de produto, pode ser localizar um registro, alterar um valor e confirmar o resultado. Use a mesma tarefa em todas as larguras para distinguir as mudanças que ajudam daquelas que apenas deslocam o problema.
Prepare uma página capaz de revelar os problemas
Escolha uma página com variedade suficiente para tornar a revisão significativa. Uma landing page quase vazia pode passar facilmente enquanto a página de preços falha. Prefira uma página que tenha navegação, um título de tamanho considerável, uma imagem, conteúdo repetido e pelo menos uma ação importante. Se o site tiver formulário ou tabela de dados, inclua também uma página com esse padrão.
Antes de verificar, substitua conteúdos de exemplo convenientes demais. Um card chamado “Equipe” provavelmente não revelará os mesmos problemas que “Operações regionais e atendimento ao cliente”. Use descrições realistas, o rótulo comum mais longo da navegação e uma imagem com um elemento principal claramente visível perto de uma das bordas. São entradas de teste, e não uma tentativa de provocar falhas com conteúdo absurdo.
Registre o que deve continuar sendo possível fazer. Em uma página fictícia de inscrição em workshop, o visitante deve conseguir ler a data, entender o local, comparar as sessões e iniciar a inscrição. Se o layout estreito esconder o local para economizar espaço, o design terá perdido uma informação necessária à tarefa, mesmo que a composição visual pareça mais limpa.
Use larguras de referência e examine também os intervalos
As prévias para desktop, tablet e celular são um ponto de partida prático. Elas não abrangem todas as condições em que a página será usada. Uma janela redimensionável, um tablet com a tela dividida ou uma página ampliada podem produzir larguras que não aparecem em nenhuma predefinição de dispositivo.
Escolha uma largura estreita, uma intermediária e uma ampla como referências. Os números específicos importam menos do que cobrir as condições relevantes para o público. Em uma primeira revisão, você poderia examinar aproximadamente 360, 768 e 1440 pixels CSS e depois redimensionar a janela gradualmente entre esses valores.
Observe especialmente os pontos próximos às mudanças de estrutura. O cabeçalho pode caber com folga na largura ampla e se recolher corretamente na estreita, mas ficar apertado pouco antes dessa mudança. Uma seção de três colunas pode precisar de mais espaço do que seu contêiner oferece em uma largura intermediária. O problema costuma aparecer antes do ponto de quebra, e não exatamente nele.
As orientações de design responsivo do web.dev recomendam definir as mudanças de layout conforme as necessidades do conteúdo, em vez de se basear em categorias de dispositivos. Aplique esse princípio registrando a primeira largura em que um componente deixa de funcionar confortavelmente. Isso dá uma justificativa para a mudança e um ponto útil para repetir o teste depois.
Uma referência útil: o GOV.UK preserva a tarefa de leitura
As orientações de layout do GOV.UK partem de uma única coluna em telas pequenas e recomendam uma coluna de leitura com dois terços da largura em muitas páginas mais amplas. O exemplo oficial de dois terços e um terço mostra o mesmo conteúdo se transformando em uma sequência vertical quando o espaço diminui.
O que vale aproveitar é a relação entre os conteúdos, e não a fração. A explicação principal continua vindo primeiro, seguida do material de apoio. Na sua página, uma condição legal exigida antes do pagamento não é secundária só porque se encaixa bem na barra lateral. Defina seu papel antes de copiar um layout que lhe atribua menor prioridade.
Isso produz um teste mais preciso do que simplesmente verificar se “as colunas ficam empilhadas”. Escolha uma frase na coluna de apoio e identifique a ação à qual ela impõe uma condição. Depois do empilhamento, o leitor consegue chegar à ação sem nunca ver essa frase? Se sim, a implementação responsiva pode estar geometricamente correta e editorialmente errada. Mova a condição junto com a ação ou deixe explícita essa dependência.
Outro teste útil é percorrer a página com o teclado. Uma reorganização visual pode manter intacta a ordem dos elementos no código-fonte. Se a tela parece colocar um controle depois da explicação, mas o foco chega a ele antes dela, a revisão precisa de evidências tanto do layout quanto da ordem de leitura. Uma captura de tela, sozinha, não resolve essa divergência.
Baseie os testes de design responsivo em tarefas
Use as verificações abaixo como registro inicial e remova as linhas que não se aplicam à página. Escreva o resultado esperado antes da revisão; caso contrário, é fácil justificar um defeito depois de vê-lo. Os exemplos abaixo são condições de teste, não configurações universais de pontos de quebra.
| Condição | O que fazer | Um resultado de aprovação útil |
|---|---|---|
| Pouco antes de o cabeçalho se recolher | Abrir todos os níveis de navegação | Os rótulos, o controle de fechamento e o destino final continuam acessíveis |
| Largura de conteúdo de 320 pixels CSS | Ler e concluir a tarefa principal | Textos e controles comuns cabem; qualquer região bidimensional tem rolagem dentro da própria área |
| Texto ampliado no navegador | Ler o título mais longo e a próxima ação | A seção cresce sem cortar nenhum dos dois |
| Erro recuperável de formulário | Enviar dados incompletos e depois corrigi-los | A mensagem permanece associada ao campo e os dados preenchidos são preservados |
| Ação fixa visível | Alcançar a última linha do conteúdo | Nenhuma informação necessária à decisão fica coberta |
| Teclado virtual aberto | Editar o último campo em um dispositivo | O campo e o caminho para concluir continuam utilizáveis |
Não reúna todas essas observações em um único percentual de aprovação. Uma legenda decorativa cortada e uma ação de pagamento inacessível não são falhas equivalentes. Corrija primeiro o que impede a conclusão de tarefas, depois as informações incorretas ou ausentes e, por fim, o conforto de leitura e o acabamento visual. Essa ordem dá a uma equipe pequena uma base viável para decidir sobre o lançamento, sem fingir que uma revisão incompleta comprova suporte a todos os dispositivos.
Percorra a página durante o uso
Navegação: abra, escolha, feche e abra novamente
Abra cada controle de navegação que muda com o layout. Um ícone de menu pode estar perfeitamente alinhado e revelar um painel inutilizável. Examine o estado aberto, selecione um destino, feche o painel e abra-o novamente. Se houver navegação com vários níveis, teste um item mais profundo em vez de parar no primeiro nível.
No exemplo do workshop, o cabeçalho amplo poderia mostrar Sessões, Palestrantes, Local e Reservar uma vaga. A versão estreita pode mover os três primeiros links para um painel. Confira se Local continua disponível, se o rótulo é legível e se fechar o painel devolve o visitante à página sem deixar uma camada transparente bloqueando a interação.
Observe a relação entre o menu e o restante da tela. Um painel alto pode precisar de rolagem própria ou de permitir a rolagem da página. Seja qual for a abordagem, o visitante deve conseguir alcançar o último item e o controle de fechamento. Um painel que só funciona quando a área de visualização é alta o suficiente continua sendo um problema de responsividade.
Repita a tarefa com o teclado. O objetivo é verificar se a mudança de layout deixou algum controle inacessível ou escondeu o foco atual. Registre a sequência exata que provoca o problema para que a correção seja direcionada a ele.
Ordem de leitura: acompanhe a sequência no celular
Quando as colunas se transformam em uma pilha única, a sequência de leitura merece uma nova revisão. A versão para desktop pode depender de relações espaciais que deixam de existir. Um preço que ficava ao lado de uma explicação pode acabar várias telas distante dela. Uma legenda pode parecer descrever a imagem seguinte, em vez da anterior.
Leia a página estreita de cima a baixo sem consultar o layout de desktop. Pergunte o que cada seção prepara o leitor para entender em seguida. Em uma página de inscrição, os detalhes das sessões devem aparecer antes de se esperar que o visitante escolha uma delas. Colocar uma grande imagem decorativa entre a escolha e sua explicação pode fazer a ação parecer desconectada.
Preste atenção às seções alternadas no desktop. Uma seção com imagem à esquerda e texto à direita, seguida de outra com imagem à direita e texto à esquerda, pode gerar uma ordem inconsistente no celular se a implementação simplesmente empilhar os elementos do código-fonte. Decida se cada imagem introduz o texto ou o ilustra depois e mantenha essa relação consistente quando o conteúdo cumprir a mesma função.
Conteúdo que ultrapassa os limites: descubra a causa antes de escondê-lo
Percorra toda a página e procure conteúdo que ultrapasse seu contêiner. Alguns sinais comuns são texto de botão cortado, borda de card que sai da tela e link no rodapé que empurra o conteúdo vizinho para fora do lugar. Confira também as sobreposições e os conteúdos expandidos: a página em repouso pode caber, enquanto um controle aberto não cabe.
Diferencie um transbordamento acidental de uma região de rolagem intencional. Uma tabela comparativa larga pode ter rolagem horizontal dentro da própria área. Toda a página se mover para os lados por causa de uma ilustração grande demais é outro problema. Quando a rolagem horizontal é intencional, o visitante precisa perceber que há mais conteúdo e manter a referência do que está lendo.
Não considere concluída uma correção só porque uma regra global passou a esconder o conteúdo que ultrapassa os limites. Ela pode deixar a borda externa limpa enquanto corta o elemento que causou o problema. Primeiro identifique o responsável e depois decida se é preciso alterar largura, quebra de linha, posição ou contêiner. Após a mudança, verifique se nenhum conteúdo útil simplesmente desapareceu.
Na página do workshop, imagine um card de ingresso com um nome de local longo. Uma correção útil pode ser permitir que o nome quebre em mais linhas e que o card cresça. Reduzir todos os textos do card também faria o conteúdo caber, mas prejudicaria a legibilidade de informações que não estavam causando o problema.
Verifique se cada recorte preserva o sentido da imagem
Uma imagem pode estar tecnicamente contida e ainda assim não comunicar o necessário. Observe o que permanece visível quando seu formato muda. Se ela deve mostrar uma entrada, essa entrada precisa continuar aparecendo. Se explica um recurso, a parte relevante da interface não deve ficar pequena demais para ser reconhecida.
Em uma fotografia editorial, pode ser possível mudar o recorte e preservar o assunto principal. Em uma captura de tela instrutiva, cortar os rótulos pode eliminar a explicação. Esses dois materiais pedem decisões diferentes. Revise a finalidade da imagem antes de escolher entre um recorte mais fechado, outro arquivo ou uma seção exclusiva maior.
Use o texto ao redor como referência. Se a frase diz “Escolha a sessão destacada”, mas o destaque não pode ser visto no tamanho de exibição, a ilustração deixou de apoiar essa frase. Uma ampliação do controle relevante pode ser mais útil do que uma captura da tela inteira reduzida para caber.
Examine o arquivo efetivamente entregue ao navegador, em vez de julgar apenas pelas dimensões do original. Um arquivo de alta resolução pode ficar ilegível se for exibido pequeno demais; uma imagem com tamanho adequado pode parecer desfocada se a variante errada for carregada. Registre qual dessas condições você observou. A distinção ajuda quem implementa a correção a escolher entre mudar o layout e mudar o arquivo.
Mantenha decisões e controles juntos
Um layout responsivo deve preservar a ligação entre a informação e a ação que ela orienta. Em uma seção de preços, isso significa que nome do plano, limites relevantes, preço e ação continuam identificáveis como uma única opção. Em um formulário de inscrição, significa que a sessão escolhida permanece clara quando o visitante chega à ação final.
Confira com cuidado os botões repetidos. Três rótulos idênticos de “Continuar” podem se confundir facilmente se os cards que os contêm ficarem visualmente fragmentados. Talvez seja necessário reforçar o agrupamento, identificar melhor os planos ou tornar a ação mais descritiva. Comece pela mudança menos invasiva que restabeleça a relação, em vez de acrescentar uma decoração pesada a cada item.
Teste os controles quando os rótulos quebram em mais de uma linha. Um botão de duas linhas pode ser aceitável se o espaçamento interno, o alinhamento e os controles vizinhos continuarem coerentes. O que importa é que o usuário consiga distinguir a ação e acioná-la confortavelmente. Um rótulo cortado depois da primeira palavra é uma falha mais grave do que um botão um pouco mais alto.
Inclua os elementos fixos nessa revisão. Uma barra fixa de inscrição pode ajudar a manter a ação principal disponível, mas também cobrir uma observação de preço ou o último campo do formulário. Role até o final, abra uma seção expansível e coloque o foco em um campo. O elemento precisa justificar o espaço que ocupa nesses estados, e não apenas na captura inicial bem acabada.
Teste os formulários depois de mudanças de estado
Os formulários merecem uma revisão separada porque a interação altera a quantidade de conteúdo. Uma mensagem de erro, uma opção selecionada ou uma confirmação podem aumentar a altura e mudar a relação entre os campos. Revise o formulário com dados realistas e pelo menos um erro recuperável, em vez de examinar apenas campos vazios.
Em uma tela estreita, abra o teclado virtual em um dispositivo real sempre que possível. Confira se o campo ativo continua visível e se é possível alcançar a próxima ação. A prévia de desktop ajuda com o layout, mas não comprova, por si só, como todos os navegadores móveis lidam com o teclado e a área de visualização.
Use um valor mais longo em um campo que normalmente aceite esse tipo de entrada. O nome completo de uma organização, um sobrenome composto ou um endereço de e-mail longo podem revelar cortes que um exemplo curto não mostra. O objetivo não é alterar a política de validação do aplicativo durante a revisão visual, mas garantir que os dados aceitos continuem compreensíveis na interface.
Depois de um erro, confirme que a página ainda comunica o que precisa ser corrigido. A mensagem não deve se separar do campo porque outra seção mudou de lugar. Se o formulário usar um resumo, examine a ligação entre ele e cada campo. Registre se o problema está no layout, no texto, no comportamento do foco ou na própria validação, para que a pessoa responsável possa resolvê-lo.
Separe problemas de espaço de problemas de conteúdo
Algumas falhas que parecem de responsividade vêm de conteúdo pouco claro, e não de falta de espaço. Um parágrafo que repete o título pode alongar desnecessariamente a página no celular. Uma fileira de seis ações pode revelar uma prioridade ainda não definida. Antes de comprimir o design, pergunte se o conteúdo tem uma função clara.
Outras falhas são, de fato, problemas de layout. Condições importantes não devem ser apagadas só porque o componente atual é rígido demais. Uma condição de cancelamento em uma página de inscrição pode ser essencial, mesmo que complique a composição. A resposta adequada pode ser uma posição melhor, uma explicação expansível ou mais espaço vertical, dependendo de quando o visitante precisa dessa informação.
Uma distinção útil é perguntar se a informação deveria estar disponível em todas as larguras. Se sim, trabalhe na apresentação. Se a relevância realmente depender da tarefa ou do estado atual, uma exibição condicional pode fazer sentido. A largura, por si só, é uma justificativa fraca para remover uma informação que apoia a mesma decisão em qualquer dispositivo.
A visão geral de design responsivo da MDN trata a responsividade como uma combinação de layout flexível, mídia, tipografia e comportamento da área de visualização. É um lembrete útil ao distribuir as correções: uma falha em tela pequena não significa que seja preciso gerar a página inteira de novo.
Transforme observações em revisões pequenas e testáveis
Mantenha cada apontamento concentrado em uma falha. Descreva o componente, a condição e o comportamento esperado. Por exemplo: “Na largura intermediária da prévia, Local se sobrepõe a Reservar uma vaga. Recolha esse cabeçalho antes de os itens se tocarem; preserve os rótulos e o destino da reserva.” É um pedido de revisão mais útil do que “Melhore o layout de tablet”.
Se você trabalha no OpenDesign, as prévias de desktop, tablet e celular podem oferecer a comparação inicial. É possível usar comentários ou enviar a observação ao chat e depois revisar o HTML atualizado. Edições manuais dos textos, links, imagens e estilos compatíveis são úteis quando a mudança necessária é específica.
Para mudanças estruturais, identifique o que deve permanecer estável. Se o cabeçalho precisa de outro layout, mantenha o conteúdo e os destinos durante essa revisão. Se uma imagem precisa de um recorte melhor, evite mudar ao mesmo tempo o texto ao redor. Preservar essas variáveis facilita avaliar se a alteração resolveu o problema registrado.
Teste novamente primeiro a condição que falhou e depois as larguras vizinhas e os estados relacionados. Uma correção que faz o menu caber em determinada largura pode deixar o cabeçalho apertado demais em outra. Um botão mais alto pode revelar um card de altura fixa. Essa breve verificação de regressão faz parte da correção original, e não de uma rodada opcional de acabamento.
Termine com um registro de revisão que outra pessoa consiga usar
Antes de considerar concluída a revisão responsiva, repita a tarefa principal do começo ao fim em cada largura de referência. Leia o conteúdo, abra os controles e chegue ao resultado. Depois examine pelo menos uma largura entre essas referências em que o layout mude. Salve evidências dos estados abertos ou expandidos importantes, em vez de apenas três imagens atraentes da página em repouso.
A nota final pode ser breve: quais páginas foram verificadas, quais larguras e navegadores foram usados, quais tarefas foram concluídas e quais condições continuam sem teste. Se não havia um dispositivo móvel real disponível, informe isso. Se uma tabela tem rolagem horizontal intencional, registre a decisão para que a próxima pessoa não a confunda com um defeito despercebido.
Priorize os problemas pendentes pelo que eles impedem. Uma ação escondida ou um requisito ilegível pode bloquear a tarefa. Um título pouco elegante, mas legível, costuma ter prioridade menor. Isso dá uma ordem sensata à próxima revisão sem sugerir que a qualidade visual não importa. Apenas evita que pequenos ajustes de acabamento escondam os problemas que impedem o uso da página.