Índice

1. Design para mobile
2. Apps vs PWA vs responsive web
3. Conteúdo mobile-first
4. Performance mobile
5. Push notifications e engagement
6. Testes em dispositivos

A thumb zone

O polegar é o dedo mais usado em smartphones. A "thumb zone" é a área da ecrã alcançável confortavelmente com o polegar quando o telemóvel é segurado com uma mão.

Zonas de acessibilidade:

• Verde (fácil): zona central-inferior — acção mais frequente aqui.
• Amarela (esticável): bordas laterais — acções secundárias.
• Vermelha (difícil): canto superior — nunca colocar acções críticas aqui.

Implicação: CTAs, botões de confirmação e navegação principal devem estar na zona verde. O menu hamburguer no canto superior esquerdo é uma má prática de acessibilidade.

Touch targets e viewports

Touch targets: o tamanho mínimo recomendado para elementos interactivos é 44×44 px (Apple) ou 48×48 dp (Google Material Design). Elementos mais pequenos são difíceis de activar e causam erros de toque.

Spacing: deixar pelo menos 8px entre targets adjacentes para evitar cliques acidentais.

Viewport meta tag:

<meta name="viewport" content="width=device-width, initial-scale=1">

Sem esta tag, o browser mobile renderiza a página como se fosse desktop e depois faz zoom out.

Breakpoints standard:

• Mobile: até 768px.
• Tablet: 768px-1024px.
• Desktop: 1024px+.

Gestos em mobile

Gestos básicos: tap, double tap, long press, swipe (4 direcções), pinch to zoom, scroll.

Padrões de UX para gestos:

• Swipe horizontal: navegação entre ecrãs, carousel.
• Swipe vertical: scroll, dismiss de modais.
• Long press: contexto (like no Facebook, acções avançadas).
• Pinch to zoom: mapas, imagens.

Não inventar gestos novos sem indicação visual — o utilizador não sabe que existem.

Back button: em Android, o botão back é fundamental. Garantir que o comportamento é correcto (não fecha a app quando deveria voltar ao ecrã anterior).

Três abordagens

Responsive Web: website que se adapta a todos os tamanhos de ecrã. Acesso via browser. Sem instalação. SEO natural. Limitações de acesso a hardware.

PWA (Progressive Web App): website com capacidades extra — instalável no ecrã inicial, funciona offline (parcialmente), push notifications, acesso a câmara/GPS. Construído com tecnologias web (HTML/CSS/JS).

App nativa: construída com Swift/SwiftUI (iOS) ou Kotlin/Jetpack (Android). Acesso completo ao hardware, melhor performance, presença nas stores. Maior custo e tempo de desenvolvimento.

Tabela de decisão

Padrões de leitura mobile

Padrão F: em texto longo sem formatação, o utilizador lê o início das primeiras linhas, depois vai varrendo da esquerda, com cada scan mais curto. Resultado: começo da frase e início de parágrafos são os mais lidos.

Padrão Z: em páginas mais visuais com menos texto, o olho faz um Z: canto superior esquerdo → direito → diagonal para esquerda inferior → direita. Colocar mensagem principal e CTA nestas posições.

Implicação: a informação mais importante tem de estar no topo, no início das frases, e antes do "fold" (o que se vê sem fazer scroll).

Writing for mobile

Brevidade: frases curtas. Parágrafos de 2-3 frases máximo. Sem introduções longas.

Hierarquia visual: usar headings (H1, H2, H3), bullets, listas numeradas — facilita a leitura em scan.

Acção primeiro: começar com o verbo. "Compra agora" em vez de "Se estiveres interessado, podes adquirir..."

Labels de botões: específicos e activos. "Ver menu" em vez de "Clique aqui". "Criar conta" em vez de "Submeter".

Evitar: texto em bloco (parágrafos longos sem espaçamento), linguagem passiva, jargão técnico sem explicação.

Porque a performance mobile é crítica

Dados:

• 53% dos utilizadores abandona um site mobile que demora mais de 3 segundos a carregar.
• O tempo médio de carregamento de páginas mobile é ~8 segundos em redes 4G.
• Google usa Core Web Vitals como factor de ranking (mobile-first indexing).

Contexto de uso mobile:

• Rede mais lenta (4G, às vezes 3G).
• CPU e RAM mais limitados.
• Bateria limitada.
• Contexto de uso intermitente (transportes, filas).

Core Web Vitals para mobile

LCP (Largest Contentful Paint): < 2.5s. Carregar o elemento mais visível rapidamente.

INP (Interaction to Next Paint): < 200ms. Resposta rápida às interacções do utilizador.

CLS (Cumulative Layout Shift): < 0.1. Sem elementos a saltar enquanto carrega.

Optimizações:

• Imagens em WebP com srcset.
• Preload de recursos críticos.
• Minificação de CSS e JS.
• Lazy loading de imagens abaixo da dobra.
• Service Worker para cache (PWA).

Princípios de push notifications

As notificações são intrusivas por natureza. Usadas mal, o utilizador desactiva-as. Usadas bem, são o canal de engagement com maior CTR.

Quando usar:

• Informação urgente ou com prazo (promoção expira em X horas).
• Evento que o utilizador esperava (encomenda enviada, resposta recebida).
• Conteúdo de alta relevância pessoal (resultado do jogo da equipa favorita).

Quando NÃO usar:

• Conteúdo que o utilizador não pediu explicitamente.
• Apenas para "manter o engagement" sem valor real.
• Múltiplas notificações por dia sem razão clara.

Copywriting de notificações

Uma boa notificação tem:

1. Título: relevante, específico, máx 50 caracteres.
2. Corpo: contexto + acção, máx 100 caracteres.
3. CTA implícito: o utilizador sabe o que vai acontecer ao clicar.

Exemplos:

Emuladores vs dispositivos reais

Emuladores (Chrome DevTools Device Mode):

• Simula diferentes tamanhos de ecrã e densidades.
• Gratuito, imediato.
• Limitações: não simula performance real (CPU/RAM do telemóvel), não testa gestos multi-toque, não testa notificações, não testa funcionalidades de hardware.

Dispositivos reais:

• A experiência exacta do utilizador.
• Revelar problemas de performance que o emulador não detecta.
• Costoso e impraticável para cobrir todos os dispositivos.

BrowserStack / LambdaTest / Sauce Labs:

• Cloud de dispositivos reais. Testar em centenas de dispositivos via browser.
• Plano gratuito com limitações. Planos pagos para uso comercial.

Debugging mobile

Chrome Remote Debugging:

1. No telemóvel Android: activar Opções de Programador → USB Debugging.
2. Ligar com cabo USB ao computador.
3. No Chrome desktop: chrome://inspect → seleccionar o dispositivo.
4. DevTools completo abre ligado ao browser do telemóvel.

Safari Web Inspector (iOS):

1. iPhone: Definições → Safari → Avançado → Web Inspector activado.
2. Ligar com USB ao Mac.
3. Safari Mac: Develop menu → seleccionar o dispositivo.

Erros mais comuns: CSS que funciona no desktop mas não em iOS Safari, gestos que conflituam com o browser, problemas de overflow horizontal.