Ficha 01 · Design mobile e auditoria de página web

1. V — 44×44 pt (Apple HIG) e 48×48 dp (Material Design).

2. V — sem esta meta tag, o browser mobile renderiza como desktop a ~980px e faz zoom out.

3. F — o padrão F mostra que o utilizador lê mais o topo e o início das linhas, com scans progressivamente mais curtos para baixo.

4. F — em mobile-first, os estilos base são para mobile e as media queries expandem para ecrãs maiores (min-width).

5. V — o Service Worker intercede as requests e pode servir conteúdo em cache quando offline.

6. F — INP mede o tempo de resposta a interacções do utilizador. LCP é que mede o carregamento do maior elemento visível.

7. V — as plataformas requerem permissão explícita do utilizador para enviar notificações.

8. F — o DevTools Device Mode tem limitações: não simula a CPU/RAM real do telemóvel, nem comportamentos específicos de browsers mobile.

9. V — processo correcto: Opções de Programador → USB Debugging → ligar cabo USB → chrome://inspect.

10. V — ao definir as dimensões, o browser reserva o espaço antes de a imagem carregar, evitando o deslocamento de layout.

Problema 1 — Imagem hero de 3.5MB (5 pts) Causa: imagem de 4000×2000px não redimensionada nem comprimida para mobile. Impacto: tempo de carregamento muito lento em mobile (especialmente em 4G). 3.5MB de apenas uma imagem pode exceder o orçamento de dados de muitos utilizadores. LCP elevado.

Problema 2 — Menu de navegação com 8 itens horizontais (5 pts) Causa: menu desktop não adaptado para mobile. Impacto: num ecrã de 375px de largura, 8 itens horizontais ficam ilegíveis ou forçam scroll horizontal. Deve ser substituído por menu hamburguer ou padrão de navegação mobile adequado.

Problema 3 — Botão "Inscrever-me" de 60×20px (5 pts) Causa: touch target abaixo do mínimo de 44×44px. Impacto: o utilizador tem dificuldade extrema em clicar no botão. Taxa de erro de toque elevada, frustração, abandono. O botão mais importante da página é o mais difícil de usar.

Problema 4 — 4 colunas de cards de cursos (5 pts) Causa: layout de grid desktop não responsivo. Impacto: em mobile, 4 colunas ficam ilegíveis (cada coluna com ~90px de largura). Os cards são muito pequenos para interagir. A solução é 1 coluna em mobile, 2 em tablet.

Problema 5 — Texto de hero a 12px (5 pts) Causa: fonte demasiado pequena para leitura mobile confortável. Impacto: o texto é ilegível sem fazer zoom. O Google recomenda tamanho mínimo de 16px para texto de corpo. 12px viola as boas práticas de acessibilidade mobile.

Problema 6 (bónus): mapa com 800px de altura bloqueia o scroll vertical — o utilizador fica "preso" ao tentar fazer scroll no mapa com um dedo.

Solução 1 — Imagem hero:

<picture>
  <source media="(max-width: 768px)" srcset="hero-mobile-800.webp">
  <source media="(max-width: 1200px)" srcset="hero-tablet-1200.webp">
  <img src="hero-desktop-2000.webp" alt="Academia de música" 
       width="2000" height="1000" loading="eager">
</picture>

Imagem mobile: 800px, WebP, ~50KB. Imagem desktop: 2000px, ~300KB.

Solução 2 — Menu de navegação:

@media (max-width: 768px) {
  .nav-menu { display: none; }
  .hamburger-btn { display: block; }
}

Implementar menu hamburguer que abre um drawer ou dropdown.

Solução 3 — Botão "Inscrever-me":

.btn-inscricao {
  min-height: 48px;
  min-width: 120px;
  padding: 14px 24px;
  font-size: 16px;
  /* Em mobile: 100% width para máxima área de toque */
}
@media (max-width: 768px) {
  .btn-inscricao { width: 100%; }
}

Solução 4 — Grid de cursos:

.cursos-grid {
  display: grid;
  grid-template-columns: 1fr; /* Mobile: 1 coluna */
}
@media (min-width: 600px) {
  .cursos-grid { grid-template-columns: repeat(2, 1fr); }
}
@media (min-width: 1024px) {
  .cursos-grid { grid-template-columns: repeat(4, 1fr); }
}

Solução 5 — Tamanho do texto:

body { font-size: 16px; line-height: 1.6; }
h1 { font-size: clamp(1.5rem, 5vw, 3rem); }
p { font-size: clamp(1rem, 2.5vw, 1.125rem); }

Versão melhorada:

Título: "Novo curso de piano a partir de Outubro" Corpo: "Inscrições abertas até 30 Set. Plazas limitadas!"

Justificação: a versão original não diz o que é a novidade (sem valor específico). A versão melhorada nomeia o produto, o prazo e a escassez — três elementos que motivam acção imediata.

Versão melhorada:

Título: "Novo módulo de guitarra disponível" Corpo: "Técnica de fingerpicking — continua onde paraste."

Justificação: "Não te esqueças de nós!" é centrado na empresa, não no utilizador. A versão melhorada oferece valor concreto (novo conteúdo específico) e personalização (continua onde paraste). Nunca usar linguagem que implique culpa ou que o utilizador é ausente.

Versão melhorada:

Título: "Pagamento falhou — acesso em risco" Corpo: "Actualiza o cartão até Sex para manter o acesso ilimitado."

Justificação: "Aviso Importante" é vago (o utilizador não sabe se é urgente). A versão melhorada diz explicitamente o que aconteceu, as consequências e o prazo. Usa a urgência de forma honesta (não fabricada).

Versão melhorada:

Título: "50% off em todos os cursos — só hoje" Corpo: "Código JULHO50 · válido até meia-noite."

Justificação: a versão original usa linguagem de spam genérico sem dar nenhuma informação concreta sobre a promoção. A versão melhorada especifica o desconto, o código e o prazo — todas as informações necessárias para o utilizador decidir em 2 segundos se quer clicar.

Problema: pedir permissão de notificações imediatamente ao abrir a app pela primeira vez resulta quase sempre em rejeição — o utilizador ainda não viu valor e não tem razão para confiar na app.

Solução proposta — permission priming:

1. Não pedir imediatamente. Deixar o utilizador explorar a app.

2. Esperar um momento de valor: após o utilizador completar o primeiro treino, criar o primeiro plano, ou atingir um objetivo inicial — quando claramente viu o valor da app.

3. Apresentar uma notificação de contexto (in-app prompt) ANTES do prompt do sistema operativo:

   "Quer receber lembretes do teu plano de treino? Estudos mostram que utilizadores com lembretes treinam 3× mais regularmente." Botões: "Sim, quero!" / "Agora não"

4. Só ao clicar "Sim" se pede a permissão real do sistema operativo.

Resultado esperado: taxa de opt-in de 50-70% em vez de 15%. O utilizador compreende o benefício antes de decidir.