Ficha 01 · Interativo, plataformas, sistema de design
- Distinguir linear/interativo
- Adaptar a inputs
- Sistema de design
- Estados
Parte I · Linear vs interativo
Exercício 1 · Distinção (10 pts)
Indica diferenças entre conteúdo linear e interativo (3 diferenças).
| Linear | Interativo |
|---|---|
| Tempo controlado pelo autor | Tempo controlado pelo utilizador |
| Um caminho | Vários caminhos/estados |
| Sem feedback | Feedback em cada ação |
(Também: "vê" vs "faz"; storyboard cronológico vs fluxos.)
Exercício 2 · Onde está a complexidade (5 pts)
Onde está a maior dificuldade ao desenhar interativo (vs linear)?
Na previsão de todos os estados e transições possíveis — utilizador decide o caminho. Cada componente tem múltiplos estados (default/hover/focus/active/disabled/loading/error...) e cada ecrã pode estar vazio, em loading, em erro, etc. Esquecer um caso = bug visível ou bloqueio.
Parte II · Plataformas e inputs
Exercício 3 · Plataforma certa (10 pts)
Indica o tipo/stack adequado:
a) App para consultar o cardápio num restaurante via QR code. ___
b) Ecrã interativo num museu (público em pé, toque). ___
c) App móvel iOS/Android com 1 código-base. ___
a) Web app / PWA (não exige instalação; browser do telemóvel basta). b) Kiosk — web app full-screen num browser dedicado, ou aplicação Unity/TouchDesigner; UI com alvos grandes e tempo de inatividade que volta ao ecrã inicial. c) Flutter ou React Native — uma base, duas plataformas (UC02835 do TDS).
Exercício 4 · Inputs (15 pts)
Que cuidados de design ter para cada input:
a) Toque (mobile). ___
b) Controlador (smart TV). ___
c) Rato + teclado (desktop web). ___
a) Toque: alvos ≥ 44-48 px, espaçados; gestos comuns (tap/swipe/pinch); sem hover essencial; zona alcançável do polegar.
b) Controlador: navegação por focus visível + setas; texto grande (distância); pouca densidade na UI; ações primárias acessíveis com botão "OK"/"A".
c) Rato + teclado: hover com feedback; foco visível por teclado (Tab); atalhos para utilizadores avançados; densidade maior é OK (precisão do rato).
Parte III · Sistema de design
Exercício 5 · Tokens (10 pts)
O que são "design tokens" e que vantagem trazem num app com light/dark mode?
São valores base do design (cores, espaçamentos, tipografia, raios) definidos uma vez e reutilizados. Vantagem em light/dark: define-se uma paleta com tokens semânticos (--surface, --text, --primary) e trocam-se os valores por modo — todos os componentes adaptam-se automaticamente, sem reescrever cada peça. Em Figma usam-se Variables com modes; em código, custom properties + prefers-color-scheme.
Exercício 6 · Estados de componente (15 pts)
Para um botão, lista 5 estados que o design tem de prever e desenhar.
- Default (normal).
- Hover (rato em cima).
- Focus visível (Tab por teclado).
- Active / pressed (a clicar).
- Disabled (não pode clicar — visual claro, sem foco).
- Loading (a executar — spinner + impedir cliques repetidos).
- Selected/toggled (se aplicável).
(5 quaisquer.) Esquecer focus, disabled ou loading é erro clássico de UI iniciante.
Parte IV · Estados de ecrã
Exercício 7 · 5 estados (15 pts)
Numa lista de "Encomendas" no app, lista os 5 estados que cada ecrã deve prever e o que mostrar em cada.
- Vazio (primeira vez): "Ainda não tens encomendas — começa por adicionar uma" + CTA visível.
- Loading: skeleton das linhas (não spinner num ecrã em branco).
- Erro: "Não foi possível carregar. Tentar de novo?" + botão retry + suporte.
- Sucesso (depois de ação): toast "Encomenda criada" + estado visível na lista.
- Dados normais: lista com filtros, pesquisa, paginação.
Bónus: offline, permissão negada.
Parte V · Aplicação
Exercício 8 · Microinterações (10 pts)
Dá 3 exemplos de microinterações úteis num app e explica brevemente o porquê de cada uma.
- Feedback ao tocar num botão (ripple/escala) — confirma ao utilizador que o toque foi registado, evita carregamentos repetidos.
- Skeleton durante loading — mostra a estrutura que vai aparecer, perceção de rapidez maior do que um spinner.
- Toast "Encomenda criada · Desfazer" — confirma a ação e dá um caminho de reversão sem ter de a fazer "à mão".
(Também: pull-to-refresh, transições suaves entre ecrãs, animação de check de sucesso.)
Exercício 9 · Reduced motion (10 pts)
O que é prefers-reduced-motion e como o respeitar no design de microinterações?
É uma preferência do utilizador (definida no SO) para reduzir movimento — importante para pessoas com sensibilidade vestibular, enxaqueca, epilepsia. No design: prever versão "estática" ou simplificada de cada microinteração (sem deslizes/escalas grandes). Em código (CSS): @media (prefers-reduced-motion: reduce) { ... }. Em Lottie/JS: detetar a preferência e não tocar (ou tocar uma versão estática). Ignorar exclui utilizadores reais.