Ficha 01 · UX, wireframes e análise de problemas

1. F — UX foca na experiência e funcionamento; UI foca na aparência visual. São disciplinas relacionadas mas distintas.

2. F — wireframe low-fi é deliberadamente esquemático, sem tipografia real nem cores da marca. A "feiura" é intencional para focar na estrutura.

3. V — Auto Layout usa os mesmos conceitos: direcção, alignment, padding, gap, grow/fill.

4. V — happy path = fluxo ideal sem erros.

5. V — é a principal vantagem dos componentes: single source of truth.

6. F — o CSS gerado pelo Figma Inspect é uma referência, não código production-ready. Precisa de adaptação.

7. V — são todos edge cases obrigatórios a documentar.

8. F — um sitemap mostra a hierarquia de páginas/ecrãs, não o design visual.

9. F — a transição deve acontecer após a validação da estrutura em low-fi.

10. V — tipografia, componentes e espaçamento preciso são características do high-fi.

Problema 1 — Botão "Fechar" com 20px height e posição no canto superior esquerdo (7 pts) - Elemento: botão [×] Fechar, 20px. - Problema: touch target abaixo do mínimo de 44px. Zona de polegar mais difícil (canto superior). Acção comum mas inacessível. - Solução: aumentar para 44×44px mínimo. Considerar mover para bottom sheet close handle ou usar botão voltar na navigation bar em vez de modal com fechar.

Problema 2 — Botões de tamanho 24×24px (7 pts) - Elemento: botões de selecção de tamanho [36][37]...[43]. - Problema: touch target de 24px é muito abaixo do mínimo de 44px. Acção crítica (seleccionar o tamanho antes de comprar) com o pior touch target do ecrã. - Solução: aumentar para mínimo 44×44px por botão. Em mobile, um scroll horizontal de pills seria melhor que tentar colocar 8 tamanhos em linha.

Problema 3 — Nome e preço com texto demasiado pequeno (12px e 10px) (7 pts) - Elemento: nome do produto a 12px, preço a 10px. - Problema: tamanho mínimo recomendado para texto de leitura é 16px. 10-12px é ilegível para muitos utilizadores (especialmente com problemas de visão). O preço é informação crítica para a decisão de compra. - Solução: nome do produto: 20-24px bold. Preço: 22-26px, destaque visual (negrito ou cor).

Problema 4 — Descrição de 300 palavras em parágrafo único sem formatação (7 pts) - Elemento: bloco de texto de 300 palavras. - Problema: bloco de texto denso é inlegível em mobile. Utilizadores em mobile não lêem textos longos linearmente — fazem scan. Sem hierarquia, não conseguem encontrar a informação que procuram. - Solução: reduzir o texto para os pontos essenciais (bullets de características em 5-8 itens). Restante texto acessível via "Ver mais" (expand). Usar bullets, emojis ou ícones para tornar scannable.

Problema 5 — Botão "Adicionar ao carrinho" de 30px, alinhado à direita (7 pts) - Elemento: botão de compra, 30px height, alinhado à direita. - Problema: o CTA principal (comprar) tem apenas 30px de altura (abaixo do mínimo de 44px) e está alinhado à direita, onde o acesso com o polegar pode ser difícil dependendo da posição do ecrã. Deve ser o elemento mais proeminente do ecrã. - Solução: botão full-width (100%) de 52-60px height, posicionado fixo no fundo do ecrã (sticky bottom), sempre visível sem scroll.

Wireframe corrigido — Produto Mobile:

[HEADER — 60px fixo] ← Botão Voltar (44×44px) | Título truncado | Partilhar (44×44px) | Carrinho (44×44px)

[GALERIA — 280px] Carrossel swipe horizontal de imagens. Indicadores de paginação (dots). Botão favorito (40×40px) sobreposto no canto.

[INFO PRINCIPAL — padding 16px] Nome produto: "Sapatilha Running Pro X200" — 20px, bold Preço: 89,99€ — 26px, bold, cor destaque (verde) Rating: ★★★★☆ (4.2) · 127 avaliações → tap abre reviews

[TAMANHOS — padding 16px] Label: "Escolhe o teu número" Scroll horizontal de pills (44×44px mínimo cada): [36] [37] [38] [39] [40] [41] [42] [43] "Guia de tamanhos →" (link)

[DESCRIÇÃO — padding 16px] H3: "Características" • Sola de amortecimento reactivo • Cabedal em mesh respirável • Drop: 8mm • Peso: 285g [Ver mais...] → expande o texto completo de 300 palavras

[AVALIAÇÕES — padding 16px] "Avaliações (127)" — 3 reviews mostradas [Ver todas as avaliações →]

[CTA FIXO NO FUNDO — 80px, position sticky bottom] Fundo branco, shadow superior. Preço (18px) | [Botão "Adicionar ao carrinho" — 52px height, full remaining width, cor primária]

User flow — Escrever review na ReadApp

[INÍCIO] Utilizador abre a app
        ↓
[Decisão] Utilizador está autenticado?
    NÃO → [Ecrã de login] → Login bem sucedido?
              NÃO → [Erro: credenciais inválidas] → retry → [Ecrã de login]
              SIM → ↓
    SIM → ↓

[Ecrã Home / Lista de leitura]
        ↓
[Utilizador navega para aba "Lido"]
        ↓
[Decisão] Há livros na lista "Lido"?
    NÃO → [Estado vazio: "Ainda não marcaste livros como Lidos."] 
           [CTA: "Explorar livros"] → [Pesquisa]
    SIM → ↓

[Lista de livros Lidos]
        ↓
[Utilizador toca num livro]
        ↓
[Ecrã de detalhe do livro]
        ↓
[Utilizador toca em "Escrever review"]
        ↓
[Ecrã de review]
  - Avaliação de 1-5 estrelas
  - Campo de texto (máx 1000 chars)
  - Botão "Publicar review"
        ↓
[Utilizador preenche e toca em "Publicar"]
        ↓
[Decisão] Avaliação (estrelas) foi seleccionada?
    NÃO → [Erro inline: "Por favor, selecciona uma avaliação"] → retry
    SIM → ↓

[Decisão] Texto tem pelo menos 10 caracteres?
    NÃO → [Erro inline: "A review precisa de pelo menos 10 caracteres"] → retry
    SIM → ↓

[Submit para servidor]
        ↓
[Decisão] Rede disponível?
    NÃO → [Toast: "Sem ligação à internet. Tenta novamente."]
           [Opção: Guardar rascunho] → retry quando rede voltar
    SIM → ↓

[Sucesso: review publicada]
[Toast: "Review publicada!"]
        ↓
[Redireccionamento para ecrã do livro com review visível]
        ↓
[FIM]

Edge cases documentados: 1. Lista "Lido" vazia — estado vazio com CTA. 2. Validação de campos incompletos (sem estrelas, texto demasiado curto). 3. Erro de rede ao submeter — com opção de guardar rascunho.

Happy path: o percurso ideal e mais comum — onde o utilizador tem todos os dados correctos, está autenticado, a rede funciona e tudo corre como esperado. É o fluxo que os designers e developers tendem a desenhar primeiro.

Edge case: cenários que ocorrem mas são menos frequentes ou representam estados de erro, excepção ou uso não previsto. São críticos para a qualidade da experiência — uma app que trata bem os edge cases parece mais profissional e confiável.

Dois edge cases frequentemente esquecidos:

1. Estado vazio (empty state): o utilizador abre uma lista, feed ou histórico que ainda não tem conteúdo. O que mostra? Muitas apps mostram apenas uma lista em branco sem nenhuma orientação. A boa prática é mostrar uma ilustração amigável + texto explicativo + CTA para a próxima acção óbvia. Exemplo: lista de favoritos vazia → "Ainda não tens favoritos. Explora o catálogo ↗".

2. Perda de dados ao navegar para trás: o utilizador preenche um formulário longo (registo, checkout, review) e toca no botão de voltar do sistema. A maioria das implementações básicas perde todos os dados introduzidos sem aviso. A boa prática: mostrar um dialog de confirmação ("Tens alterações não guardadas. Sair?") ou guardar automaticamente um rascunho local.