Ficha 02 · Responsivo, sistema e teste

a) Desenhar primeiro para o ecrã pequeno (telemóvel) e depois ampliar para tablet/desktop. Força a priorizar o essencial (espaço escasso) e resulta em interfaces mais focadas; é mais fácil acrescentar do que cortar.

b) Os alvos de toque devem ser grandes (≥ ~44-48 px) e espaçados (o dedo é impreciso). Não pode haver interação essencial só em hover (no touch não há hover). Considerar também a zona alcançável pelo polegar.

É a largura de ecrã a partir da qual o layout muda (ex.: o menu deixa de ser hamburger, as colunas passam de 1 para 3). Decide-se onde o layout "parte" ou fica desconfortável (conteúdo apertado/esticado), não por dimensões de modelos específicos de telemóvel. Tipicamente há pontos para mobile / tablet / desktop, mas o critério é o conteúdo.

a) Tokens são os valores base do design (paleta de cores, escala tipográfica, espaçamentos, raios, sombras) definidos uma vez e reutilizados. Vantagem: consistência e manutenção — mudar o token propaga a todo o produto; rapidez no design.

b) Estados de botão: normal, hover, foco (teclado), ativo/pressionado, desativado, carregando (loading). (4 quaisquer.) Esquecer estados (sobretudo foco e desativado) é erro clássico.

Garante coerência (o utilizador aprende uma vez e reconhece em todo o lado → menos esforço e mais confiança), acelera o trabalho (componentes prontos), facilita a manutenção (alterar num sítio) e o trabalho em equipa (toda a gente usa as mesmas peças/regras). Sem sistema, cada página fica diferente e o produto parece amador e confuso.

a) Componentes + variantes — elementos reutilizáveis; alterar o principal propaga; variantes para estados/tamanhos. b) Auto Layout — elementos que se ajustam ao conteúdo/tamanho (listas, botões, layouts responsivos). c) Prototype — ligar ecrãs com interações/transições para simular o uso e testar. d) Estilos partilhados — cores e estilos de texto centralizados (o sistema de design vivo).

Handoff é a passagem do design para a equipa de desenvolvimento. O designer deve entregar: o ficheiro/protótipo com medidas e espaçamentos, cores e tipografia (tokens/estilos), estados dos componentes, assets exportáveis (ícones/imagens nas densidades certas — UC00504), e notas de comportamento/responsivo. O Figma gera muito disto automaticamente (inspecionar).

a) Definir tarefas reais (ex.: "encontra e reserva o livro X"); recrutar utilizadores representativos; pedir para pensar em voz alta; observar sem ajudar; registar; agradecer.

b) 3-5 utilizadores — segundo Nielsen, ~5 revelam cerca de 85% dos problemas; mais do que isso traz retorno decrescente. Melhor testar pouco e cedo (e iterar) do que muito e tarde.

c) Recolher: sucesso na tarefa (sim/não), tempo, erros/becos sem saída, onde hesitam, comentários, satisfação subjetiva.

d) Priorizar os problemas encontrados, iterar o design (corrigir), e voltar a testar — o processo é cíclico.