UC04376

Conceber o protótipo e o design de interfaces interativas

Do utilizador ao protótipo navegável: pesquisa, wireframes, UI/UX, acessibilidade e testes

Curso profissional · 50h · Técnico de Produção de Conteúdos Interativos

Plano

  1. Design de interfaces e o utilizador (UX)
  2. Pesquisa, referências e tendências
  3. Arquitetura da informação e fluxos de navegação
  4. Composição visual: layout, tipografia, cor
  5. Design UI: ícones, botões e sistemas de design
  6. Wireframes de baixa fidelidade
  7. Protótipos de alta fidelidade
  8. Interatividade e animação
  9. Ferramentas de prototipagem
  10. Design responsivo
  11. Acessibilidade e WCAG
  12. Testes de usabilidade e design inclusivo

Bloco 1 · Design de interfaces e o utilizador (UX)

O que é o Design UX

UX (User Experience, experiência do utilizador) é a disciplina que garante que uma interface resolve o problema certo, para a pessoa certa, de forma clara e sem atrito.

  • Não é "fazer bonito": é fazer funcionar bem, do ponto de vista de quem usa.
  • Cobre a jornada toda: antes de abrir a app, durante o uso, depois de sair.
  • Assenta em investigação, não em opinião do designer.
  • É um dos critérios de desempenho da UC: pesquisar necessidades e comportamentos dos utilizadores.

Sem conhecer o utilizador, qualquer interface é um palpite caro.

Conhecer o utilizador: necessidades, comportamentos e preferências

Antes de desenhar um único ecrã, o design de interfaces pergunta: quem vai usar isto, e porquê?

  • Necessidades: o problema real que a pessoa quer resolver (ex.: marcar uma consulta rapidamente).
  • Comportamentos: como a pessoa já usa apps parecidas (hábitos, gestos, expectativas).
  • Preferências: idade, literacia digital, dispositivo preferido, contexto de uso (em pé, na rua, com uma mão).
  • Ferramentas: entrevistas, questionários, observação e personas (perfis representativos do público-alvo).

Uma persona bem feita evita desenhar para "toda a gente", que na prática é para ninguém.

Bloco 2 · Pesquisa, referências e tendências

Análise da concorrência

Antes de desenhar, olha-se para o que já existe. A análise da concorrência identifica o que funciona, o que falha e onde há espaço para diferenciar.

  • Escolher 3 a 5 concorrentes diretos (mesma função) e indiretos (função parecida, público diferente).
  • Registar: estrutura de navegação, paleta de cores, tom de voz, pontos fortes e fracos.
  • Fazer um benchmark: tabela comparativa lado a lado.
  • Objetivo: não copiar, mas entender padrões de expectativa do utilizador (o que ele já espera encontrar).

Se toda a gente do sector põe o carrinho de compras no canto superior direito, mudar isso sem motivo forte confunde o utilizador.

Fontes e tendências estéticas e criativas

A pesquisa de referências não se esgota na concorrência direta. Alarga-se a fontes de inspiração e tendências do momento.

  • Websites especializados: Awwwards, Behance, Dribbble.
  • Publicações especializadas: revistas e blogues de design digital.
  • Conferências e eventos da indústria (webinars, meetups de UX/UI).
  • Redes sociais e comunidades online: Instagram, Pinterest, fóruns de design.

Manter um moodboard (painel de referências visuais) organizado por projeto ajuda a justificar decisões estéticas perante o cliente.

Bloco 3 · Arquitetura da informação e fluxos de navegação

Arquitetura da informação

A arquitetura da informação (AI) organiza o conteúdo de forma lógica, para que o utilizador encontre o que procura sem se perder.

  • Mapa do site/app (sitemap): diagrama em árvore com todos os ecrãs e a sua hierarquia.
  • Agrupamento: reunir conteúdos relacionados sob a mesma secção.
  • Nomenclatura clara: rótulos de menu que a pessoa entende sem explicação.
  • Card sorting: técnica em que utilizadores agrupam cartões com conteúdos, para validar a estrutura antes de desenhar.
App de encomendas
├── Início
├── Restaurantes
│   ├── Categoria
│   └── Ficha do restaurante
├── Carrinho
├── Encomendas (histórico)
└── Perfil

Fluxos de navegação e cenários de uso

O fluxo de navegação (user flow) mostra o caminho passo a passo que o utilizador percorre para cumprir uma tarefa concreta.

  • Parte de um objetivo (ex.: "reservar uma mesa") e mapeia cada ecrã e decisão até ao fim.
  • Usa cenários: histórias curtas que descrevem o contexto de uso ("a Marta, com pressa, no telemóvel, quer reservar em 30 segundos").
  • Identifica pontos de decisão (if/else) e estados de erro (ex.: mesa indisponível).
  • Base do modelo mental: o que o utilizador espera que aconteça a seguir, em cada clique.
[Abrir app] → [Escolher restaurante] → [Escolher hora] → [Confirmar] → [Ecrã de sucesso]
                                              ↓ (sem hora livre)
                                        [Sugerir alternativas]

Bloco 4 · Composição visual: layout, tipografia, cor

Princípios de composição visual e layout

O design visual assenta em princípios que organizam o olhar do utilizador pelo ecrã.

  • Hierarquia visual: o que é mais importante deve destacar-se primeiro (tamanho, peso, cor, posição).
  • Alinhamento: elementos alinhados a uma grelha transmitem ordem e profissionalismo.
  • Proximidade: elementos relacionados ficam próximos; espaço em branco separa grupos diferentes.
  • Repetição e consistência: os mesmos estilos de botão, título e ícone em todo o produto.
  • Grelha (grid): divide o ecrã em colunas para alinhar todos os elementos de forma previsível.

A hierarquia visual guia o olho do utilizador na ordem certa, sem que ele tenha de pensar nisso.

Tipografia, legibilidade e ritmo de leitura

A tipografia é o principal veículo de informação numa interface: mal escolhida, prejudica a leitura antes de qualquer imagem.

  • Legibilidade: contraste suficiente, tamanho mínimo confortável (recomenda-se 16px para texto de corpo em ecrã), espaçamento entre linhas (1,4 a 1,6 vezes o tamanho da letra).
  • Hierarquia tipográfica: título, subtítulo, corpo de texto, legenda, cada um com o seu peso e tamanho.
  • Máximo 2 famílias tipográficas por produto, para manter coerência.
  • Ritmo de leitura: linhas nem muito curtas nem muito longas (45 a 75 caracteres por linha é a referência clássica).
Elemento Tamanho típico Peso
Título (H1) 28-32px bold
Subtítulo (H2) 20-24px semibold
Corpo de texto 16px regular
Legenda/nota 12-14px regular

Cor: sistema, significado e consistência

A cor comunica identidade, hierarquia e estado, e tem de ser usada de forma sistemática.

  • Paleta: uma cor primária (marca), uma ou duas secundárias, e cores neutras (cinzentos) para texto e fundos.
  • Cores de estado: verde (sucesso), vermelho (erro), amarelo (aviso), azul (informação). Convenções que o utilizador já traz de outras interfaces.
  • Consistência: o mesmo botão de ação principal usa sempre a mesma cor em todo o produto.
  • Contraste: garantir que texto sobre fundo é sempre legível, sobretudo em modo escuro.

A cor é um dos elementos que a UC pede explicitamente para manter consistentes: ícones, cores e outros elementos da identidade visual.

Bloco 5 · Design UI: ícones, botões e sistemas de design

Elementos gráficos: ícones, símbolos e botões

O Design UI trabalha os elementos concretos que o utilizador toca e reconhece.

  • Ícones e símbolos: devem ser reconhecíveis à primeira vista (a lupa é sempre pesquisa; a casa é sempre início).
  • Botões: têm de parecer clicáveis (contraste, sombra, cor) e ter um único estilo por tipo de ação (primário, secundário, destrutivo).
  • Estados de interação: normal, hover (rato por cima), ativo (a ser clicado), desativado (disabled) e foco (navegação por teclado).
  • Tamanho de toque: área mínima recomendada de 44x44px em ecrãs táteis, para dedos de diferentes tamanhos.

Um ícone ambíguo obriga o utilizador a parar e pensar; um bom ícone não precisa de legenda.

Sistemas de design e componentes reutilizáveis

Um sistema de design (design system) é a biblioteca central de componentes, estilos e regras que garante consistência em todo o produto.

  • Componentes reutilizáveis: botões, campos de formulário, cartões (cards), barras de navegação, definidos uma vez e usados em todo o lado.
  • Bibliotecas (em ferramentas como Figma): guardam esses componentes com variações (tamanho, estado, tema).
  • Tokens de design: valores nomeados para cor, espaçamento e tipografia (ex.: cor-primaria, espaco-md), partilhados entre design e desenvolvimento.
  • Colaboração em tempo real: várias pessoas a editar o mesmo ficheiro, com comentários e histórico de versões.

Mudar um componente na biblioteca atualiza-o automaticamente em todos os ecrãs onde é usado: é a base da consistência da identidade visual.

Bloco 6 · Wireframes de baixa fidelidade

O que é um wireframe

O wireframe é um esboço estrutural do ecrã: mostra onde ficam os elementos, sem cor, tipografia final ou conteúdo real.

  • Baixa fidelidade: caixas, linhas e texto genérico ("Lorem ipsum"), muitas vezes em papel ou a preto e branco.
  • Foca a estrutura e o layout, não a estética: onde fica o menu, o botão principal, a imagem.
  • Permite testar e mudar ideias rapidamente e sem custo, antes de investir tempo em estética.
  • É a etapa em que o cliente valida "o que está onde", sem se distrair com cores.

Um wireframe feito em 10 minutos que se deita fora vale mais do que um ecrã perfeito desenhado nas primeiras horas.

Boas práticas ao desenhar wireframes

  • Usar caixas cinzentas para imagens e linhas para texto, sem detalhe.
  • Manter consistência entre ecrãs: o mesmo elemento sempre no mesmo sítio (ex.: menu sempre em baixo).
  • Numerar ou nomear os ecrãs, e ligá-los ao fluxo de navegação definido antes.
  • Testar o wireframe com colegas ou utilizadores reais, pedindo que apontem onde clicariam.
  • Ferramentas comuns: papel, Figma (modo wireframe), Balsamiq.

O objetivo do wireframe não é impressionar, é validar decisões estruturais antes de gastar tempo na estética.

Bloco 7 · Protótipos de alta fidelidade

Do wireframe ao protótipo de alta fidelidade

O protótipo de alta fidelidade já tem cor, tipografia final, imagens reais e, sobretudo, interações navegáveis.

  • Aplica o sistema de design definido: componentes, cores, tipografia.
  • Usa conteúdo real ou realista, não texto genérico.
  • Liga os ecrãs entre si com interações clicáveis, simulando a app final.
  • Serve para testes de usabilidade com utilizadores reais, e para apresentar ao cliente uma visão fiel do produto final.

Passar diretamente do rascunho à alta fidelidade, sem wireframe, é o erro mais caro em tempo de projeto.

Artboards, componentes e organização do ficheiro

Nas ferramentas de prototipagem, o trabalho organiza-se em artboards (pranchas, uma por ecrã).

  • Artboard: representa um ecrã, com o tamanho exato do dispositivo alvo (ex.: 375x812px para telemóvel).
  • Páginas/secções do ficheiro: separar wireframes, protótipo de alta fidelidade e biblioteca de componentes.
  • Nomenclatura clara: nomear artboards e camadas de forma que outra pessoa (ou o próprio, meses depois) entenda.
  • Versões: guardar versões do protótipo à medida que evolui, para poder comparar e recuar.

Um ficheiro bem organizado poupa-te (e à equipa) horas quando o projeto cresce.

Bloco 8 · Interatividade e animação

Princípios de interatividade e modelos de transição

A interatividade define como a interface reage ao toque, clique ou gesto do utilizador.

  • Feedback imediato: todo o toque deve ter uma resposta visual (mudança de cor, animação, som), para o utilizador saber que "aconteceu alguma coisa".
  • Modelos de transição: como se muda de ecrã (deslizar, desvanecer/fade, escala, sobreposição/modal).
  • Micro-interações: pequenos detalhes animados (ex.: coração que "pulsa" ao dar like, botão que muda ao ser premido).
  • Devem ser rápidas (habitualmente entre 150 e 400 milissegundos): animação lenta demais irrita, rápida demais passa despercebida.

Uma boa animação não é decoração: comunica hierarquia, direção e causa/efeito.

Simular o fluxo do utilizador no protótipo

Ligar os artboards com interações transforma um conjunto de ecrãs estáticos numa simulação navegável do produto.

  • Cada elemento clicável (botão, cartão, ícone) liga a um destino (outro ecrã, um estado, uma sobreposição).
  • Definir o ponto de partida do protótipo (o primeiro ecrã que abre ao testar).
  • Simular estados diferentes: ecrã vazio, ecrã com dados, ecrã de erro, ecrã de carregamento.
  • Testar o fluxo completo, do início ao fim, tal como o utilizador o vai viver.
[Ecrã Início] --toque no botão "Entrar"--> [Ecrã Login]
[Ecrã Login] --toque "Confirmar", campos vazios--> [Ecrã Login + erro]
[Ecrã Login] --toque "Confirmar", campos válidos--> [Ecrã Início autenticado]

Bloco 9 · Ferramentas de prototipagem

Aplicações e plataformas de prototipagem

Existem várias ferramentas para desenhar e prototipar interfaces, com um fluxo de trabalho semelhante entre elas.

Ferramenta Ponto forte
Figma colaboração em tempo real, gratuita para uso individual, padrão de mercado
Adobe XD integração com outras ferramentas Adobe
Sketch histórico consolidado, só macOS
Balsamiq wireframes rápidos de baixa fidelidade
Marvel / InVision prototipagem simples a partir de imagens

Fluxo comum a todas: criar artboards → desenhar/importar componentes → definir estilos → ligar interações → partilhar link de protótipo → recolher feedback.

Edição de vetores, imagem e bancos de recursos

O design de interfaces também recorre a ferramentas de edição gráfica e a bancos de conteúdo.

  • Edição de vetores (ex.: Figma, Illustrator, Inkscape): para criar e ajustar ícones e ilustrações escaláveis sem perda de qualidade.
  • Edição de imagem (ex.: Photoshop, GIMP, Photopea): para tratar fotografias, cortar, ajustar cor e comprimir.
  • Bancos de imagem, som e vídeo: fontes gratuitas ou pagas (com licença adequada) para não usar conteúdo protegido sem autorização.
  • Exportar sempre nos formatos e resoluções certos para cada plataforma (ícones em SVG, fotos em JPG/WebP comprimido).

Usar conteúdo com licença errada é um risco legal e ético, não só uma questão técnica.

Bloco 10 · Design responsivo

Princípios do design responsivo

O design responsivo garante que a interface se adapta a diferentes tamanhos de ecrã e dispositivos, mantendo a usabilidade.

  • Breakpoints: larguras de referência onde o layout muda (ex.: telemóvel até 480px, tablet até 1024px, desktop acima disso).
  • Layout fluido: elementos que se redimensionam em proporção, em vez de tamanhos fixos.
  • Prioridade de conteúdo: em ecrãs pequenos, mostrar primeiro o essencial; esconder ou reorganizar o secundário.
  • Mobile-first: desenhar primeiro para o ecrã mais pequeno e ir acrescentando espaço para os maiores, não o inverso.

A maioria do tráfego de muitos produtos digitais em Portugal já vem do telemóvel: desenhar "desktop-first" inverte as prioridades reais.

Adaptabilidade e exportação para diferentes plataformas

Desenhar de forma responsiva implica também preparar o protótipo para diferentes contextos técnicos de exportação.

  • Grelhas responsivas: usar colunas (ex.: 4 no telemóvel, 8 no tablet, 12 no desktop) que se reorganizam por breakpoint.
  • Componentes adaptativos: um menu que é uma barra horizontal no desktop e se transforma em menu "hambúrguer" no telemóvel.
  • Testar em dispositivos reais sempre que possível, não só no simulador da ferramenta de design.
  • Exportação: preparar assets (ícones, imagens) em várias resoluções para diferentes densidades de ecrã (1x, 2x, 3x).

Um protótipo só está pronto quando foi verificado nos três contextos: telemóvel, tablet e desktop.

Bloco 11 · Acessibilidade e WCAG

Web Content Accessibility Guidelines (WCAG)

As WCAG são as diretrizes internacionais de referência para tornar o conteúdo digital acessível a todos, incluindo pessoas com deficiência.

Organizam-se em quatro princípios, o acrónimo POUR:

  • Percetível: a informação tem de ser apresentável de forma que todos a consigam percecionar (texto alternativo em imagens, contraste suficiente).
  • Operável: os componentes de interface têm de ser operáveis (navegação por teclado, tempo suficiente para agir).
  • Compreensível: a informação e o funcionamento têm de ser compreensíveis (linguagem clara, comportamento previsível).
  • Robusto: o conteúdo tem de funcionar com diferentes tecnologias de apoio (leitores de ecrã, por exemplo).

Acessibilidade na prática: contraste, teclado e leitores de ecrã

Aplicar a acessibilidade não exige reinventar o design, exige disciplina em decisões concretas.

  • Contraste de cor: mínimo recomendado de 4.5:1 entre texto e fundo, para texto de corpo.
  • Texto alternativo (alt text): descrição de cada imagem informativa, para quem usa leitor de ecrã.
  • Navegação por teclado: todos os elementos interativos devem ser alcançáveis com a tecla Tab, com um indicador de foco visível.
  • Tamanhos de toque e zoom: permitir ampliar texto sem quebrar o layout; áreas de toque suficientemente grandes.
  • Não depender só da cor: um erro de formulário não pode ser assinalado só a vermelho, precisa também de texto ou ícone.

Um site acessível serve mais pessoas e evita problemas legais; a acessibilidade nunca é opcional.

Bloco 12 · Testes de usabilidade e design inclusivo

Testes de usabilidade: métodos e métricas

O teste de usabilidade verifica, com utilizadores reais, se o protótipo é fácil de usar e cumpre o objetivo a que se propõe.

  • Método: dar a um pequeno grupo de participantes (5 a 8 chegam para detetar a maioria dos problemas) tarefas concretas a cumprir no protótipo, observando sem ajudar.
  • Think aloud: pedir ao participante que verbalize o que está a pensar enquanto navega.
  • Métricas: taxa de sucesso da tarefa, tempo até completar, número de erros, satisfação percebida (questionário curto no fim).
  • Registar cada problema encontrado, priorizar por gravidade e frequência, e corrigir antes da entrega final.

Um teste com 5 utilizadores bem escolhidos revela mais problemas reais do que uma semana de opinião interna da equipa.

Design inclusivo, correção de erros e documentação final

O design inclusivo vai além da acessibilidade técnica: pensa na diversidade real do público-alvo.

  • Diversidade e inclusão: representar diferentes idades, géneros, culturas e capacidades nas imagens e exemplos usados.
  • Flexibilidade e adaptação: permitir diferentes formas de completar a mesma tarefa (ex.: pesquisa por texto e por filtros).
  • Clareza e comunicação efetiva: linguagem simples, sem jargão desnecessário.
  • Após o teste de usabilidade: corrigir os erros identificados, ajustar o design e documentar o protótipo (guia de estilo, decisões tomadas, resultados dos testes) para entregar ao cliente ou à equipa de desenvolvimento.

Fundamentar cada decisão de design com dados de pesquisa e de testes é o que separa um protótipo profissional de um palpite bem desenhado.

Recapitulando

  • UX conhece o utilizador (pesquisa, personas, análise da concorrência); UI desenha os elementos que ele toca (cor, tipografia, ícones, botões).
  • Arquitetura da informação e fluxos de navegação organizam o conteúdo antes de desenhar qualquer ecrã.
  • Wireframe (baixa fidelidade, estrutura) evolui para protótipo de alta fidelidade (interativo, navegável, com o sistema de design aplicado).
  • Responsividade, WCAG/acessibilidade e design inclusivo garantem que a interface serve todos, em qualquer dispositivo.
  • Testes de usabilidade validam com utilizadores reais, e fundamentam cada decisão de design tomada.

Próximo: fichas e mini-projecto, conceber um protótipo de raiz.

NOTAS DO PROFESSOR - Enfatizar: UI é a superfície (o que se vê); UX é a experiência completa (o que se sente e consegue fazer). Vêm sempre juntas, mas são disciplinas distintas. - Erro comum: alunos tratam UX como sinónimo de "design bonito". Corrigir logo neste primeiro slide. - Analogia: um restaurante pode ter uma sala linda (UI) e, ainda assim, um serviço lento e confuso (má UX). Precisamos das duas coisas.

NOTAS DO PROFESSOR - Trazer um exemplo real: uma app de marcação de consultas usada por pessoas de 65+ anos precisa de texto maior e menos passos do que uma app de desporto para jovens. - Erro comum: confundir "cliente" (quem paga o projeto) com "utilizador" (quem usa a interface). Nem sempre são a mesma pessoa. - Exercício rápido: pedir à turma que descreva, em 3 frases, a persona principal de uma app de transportes públicos.

NOTAS DO PROFESSOR - Enfatizar que a análise da concorrência responde a um critério de desempenho explícito: analisar referências e tendências. - Erro comum: copiar literalmente um concorrente. A análise serve para entender padrões, não para plagiar. - Exercício em aula: em grupos, analisar 2 apps de bancos portugueses (ex.: apps de bancos conhecidos) e listar 3 semelhanças de navegação.

NOTAS DO PROFESSOR - Mostrar ao vivo um site como o Awwwards ou o Dribbble e discutir 2 exemplos de tendências atuais (ex.: modo escuro, glassmorphism, micro-interações). - Erro comum: seguir uma tendência visual sem avaliar se serve o público-alvo do projeto (ex.: um site institucional sénior não precisa de estética "gamer"). - Ligar à atitude "sentido criativo" e "sentido crítico" do referencial: inspirar-se, mas com filtro.

NOTAS DO PROFESSOR - Fazer o paralelismo com o índice de um livro: se o índice está mal organizado, o leitor não encontra o capítulo, mesmo que o conteúdo lá dentro seja bom. - Erro comum: criar menus com mais de 7 itens de topo. A regra prática (não absoluta) é manter a navegação principal enxuta. - Exercício: desenhar em conjunto o sitemap de uma app de biblioteca municipal.

NOTAS DO PROFESSOR - Distinguir claramente sitemap (estrutura estática) de user flow (percurso dinâmico de uma tarefa). - Erro comum: desenhar só o "caminho feliz" e esquecer os erros e exceções (rede lenta, campo vazio, stock esgotado). - Exercício: mapear o fluxo de "recuperar palavra-passe" de uma app à escolha da turma.

NOTAS DO PROFESSOR - Mostrar dois exemplos do mesmo ecrã: um sem hierarquia (tudo do mesmo tamanho) e outro com hierarquia clara. Pedir à turma para dizer qual lê primeiro e porquê. - Erro comum: usar mais de 3 níveis de tamanho de texto num único ecrã, o que dilui a hierarquia. - Ligar à atitude "sentido de organização": um layout desorganizado transmite descuido, mesmo com boas cores.

NOTAS DO PROFESSOR - Mostrar um bloco de texto com má legibilidade (letra pequena, sem espaçamento) e o mesmo texto corrigido, lado a lado. - Erro comum: usar 5 ou 6 tipos de letra diferentes "porque ficam bonitos". Reforçar a regra das 2 famílias. - Exercício: medir o contraste de um exemplo com uma ferramenta online de contraste de cor (liga-se ao bloco de acessibilidade mais à frente).

NOTAS DO PROFESSOR - Mostrar uma paleta bem definida (ex.: 1 primária + 2 neutras + 4 de estado) versus um ecrã com cores aleatórias. - Erro comum: usar vermelho para um botão de ação positiva "porque destaca". Vermelho é lido como erro/perigo por convenção. - Perguntar à turma: porque é que quase todos os botões de "eliminar" são vermelhos? (convenção aprendida, reduz erros do utilizador).

NOTAS DO PROFESSOR - Mostrar um conjunto de ícones ambíguos (ex.: três traços horizontais = menu, mas confunde-se com "lista") e discutir alternativas. - Erro comum: usar cor como único sinal de estado desativado, sem baixar também o contraste. Prejudica utilizadores com daltonismo. - Exercício: desenhar (em papel) os 4 estados de um botão "Adicionar ao carrinho".

NOTAS DO PROFESSOR - Demonstrar, se possível, um componente Figma e as suas "instâncias" espalhadas por várias telas, e mostrar o efeito de editar o componente principal. - Erro comum: duplicar um botão "à mão" em vez de reutilizar o componente, o que faz o design divergir com o tempo. - Ligar à atitude "cooperação com a equipa": um sistema de design só funciona se todos o respeitarem.

NOTAS DO PROFESSOR - Trazer papel e caneta para a aula e fazer wireframes à mão em conjunto: mostra que a ferramenta não é o obstáculo. - Erro comum: alunos "adiantam-se" e já colocam cores e imagens finais no wireframe. Corrigir: baixa fidelidade é só estrutura. - Analogia: o wireframe está para o design como a planta de uma casa está para a decoração.

NOTAS DO PROFESSOR - Exercício prático: cada aluno desenha, em 15 minutos, o wireframe de 3 ecrãs de uma app simples (ex.: lista de tarefas). - Erro comum: um wireframe sem ligação nenhuma aos fluxos definidos antes, como se fossem exercícios isolados. - Reforçar: um wireframe mau descoberto agora custa 10 minutos a corrigir; descoberto no protótipo final, custa horas.

NOTAS DO PROFESSOR - Mostrar lado a lado o mesmo ecrã em baixa e em alta fidelidade, para a turma visualizar a progressão. - Erro comum: começar logo em alta fidelidade "porque fica mais bonito", perdendo a velocidade de iteração da baixa fidelidade. - Perguntar: o que se perde ao saltar o wireframe? (tempo perdido a mudar estrutura já com detalhe estético aplicado).

NOTAS DO PROFESSOR - Mostrar a organização de um ficheiro Figma real: páginas separadas para wireframes, UI kit e protótipo final. - Erro comum: um único artboard gigante com tudo misturado, impossível de navegar. - Ligar à atitude "sentido de organização", tal como nas layers dos esquemas técnicos noutras UCs.

NOTAS DO PROFESSOR - Mostrar exemplos de transições comuns (deslizar da direita para abrir um novo ecrã = "avançar"; deslizar para baixo = "fechar/cancelar") e o significado que cada gesto carrega. - Erro comum: animações longas ou excessivas que atrasam a tarefa do utilizador em vez de ajudar. - Exemplo prático: o "pull to refresh" (puxar para atualizar) como padrão de interação universalmente reconhecido.

NOTAS DO PROFESSOR - Demonstrar ao vivo, se possível, a ligação de dois artboards num protótipo interativo simples numa ferramenta como o Figma. - Erro comum: só ligar o "caminho feliz" e deixar os estados de erro sem protótipo, o que impossibilita testar cenários reais. - Reforçar a ligação direta a este critério: "fundamentar decisões de design, interações e resultados dos testes".

NOTAS DO PROFESSOR - Escolher UMA ferramenta principal para a turma (recomenda-se Figma pela colaboração em tempo real e plano gratuito) e mencionar as outras como equivalentes. - Sublinhar que o fluxo de trabalho é transferível entre ferramentas: aprender bem uma facilita aprender as outras. - Recomendar o plano gratuito do Figma para os alunos praticarem em casa.

NOTAS DO PROFESSOR - Mostrar a diferença entre um ícone vetorial (escala sem perder qualidade) e um ícone em pixels (fica desfocado ao ampliar). - Erro comum: usar imagens do Google Imagens sem verificar a licença de utilização. - Recomendar bancos com licença livre (Creative Commons, uso comercial permitido) como prática por defeito.

NOTAS DO PROFESSOR - Mostrar o mesmo ecrã em três larguras (telemóvel, tablet, desktop) e discutir o que muda em cada um. - Erro comum: apenas "encolher" o layout de desktop para telemóvel, em vez de reorganizar o conteúdo pela sua prioridade real. - Ligar ao critério de desempenho "garantindo a responsividade da interface" e "assegurando a adaptação a diferentes tamanhos de ecrã".

NOTAS DO PROFESSOR - Demonstrar, numa ferramenta de prototipagem, a criação de 2 ou 3 versões responsivas do mesmo ecrã. - Erro comum: entregar só a versão desktop e assumir que "depois se adapta" na fase de desenvolvimento. - Exercício: redesenhar em conjunto um menu de navegação de desktop para versão telemóvel (hambúrguer).

NOTAS DO PROFESSOR - Escrever o acrónimo POUR no quadro e pedir à turma que dê um exemplo prático de cada princípio. - Erro comum: tratar acessibilidade como "extra opcional" em vez de requisito desde o início do projeto. - Curiosidade: em vários países, incluindo a UE, há legislação que obriga certos sites públicos a cumprir níveis mínimos de acessibilidade.

NOTAS DO PROFESSOR - Demonstrar uma ferramenta gratuita de verificação de contraste e testar 2-3 combinações de cor do próprio projeto da turma. - Erro comum: assinalar campos obrigatórios só com um asterisco vermelho pequeno, difícil de perceber para baixa visão. - Exercício: navegar um site conhecido só com o teclado (Tab/Enter), sem usar o rato, e identificar onde o foco se perde.

NOTAS DO PROFESSOR - Simular em aula um mini teste de usabilidade: um aluno usa o protótipo de outro, a turma observa e regista problemas. - Erro comum: o facilitador do teste "ajudar" o participante quando ele hesita, o que invalida os resultados. - Reforçar o critério de desempenho: "executando testes de usabilidade e acessibilidade, analisando e corrigindo erros".

NOTAS DO PROFESSOR - Mostrar um exemplo de documentação final de protótipo (guia de estilo simples: cores, tipografia, componentes, decisões). - Erro comum: entregar só o protótipo, sem explicar o "porquê" das decisões, o que dificulta o trabalho de quem desenvolve a seguir. - Fechar ligando às atitudes do referencial: responsabilidade, sentido crítico e cooperação com a equipa em todo o processo.