O que é um protótipo

Um protótipo é uma representação experimentável de um sistema interativo, construída antes do produto final, para aprender, validar e comunicar uma ideia.

• Não é o produto: é uma ferramenta de trabalho, descartável.
• Pode ser tão simples como papel e caneta ou tão realista como um ecrã interativo.
• O objetivo nunca é "ficar bonito": é responder a uma pergunta concreta sobre o desenho.

Planear a prototipagem é a primeira realização desta UC: decidir o que se vai prototipar, com que fidelidade e para responder a que pergunta.

Para que serve prototipar

Prototipar poupa tempo e dinheiro porque revela problemas antes de investir em desenvolvimento.

• Testar fluxos: o utilizador chega ao objetivo?
• Testar compreensão: a interface é clara?
• Testar desejo: o utilizador gostaria de usar isto?
• Comunicar uma ideia à equipa, a um cliente ou a um professor.

Cada protótipo deve ter um propósito declarado antes de começar a desenhar.

Do esboço em papel à maqueta

A fidelidade de um protótipo é o quanto ele se parece e se comporta como o produto final.

Cada nível tem um custo de produção diferente e uma finalidade diferente.

Quando usar cada nível

• Esboço em papel: para gerar e descartar muitas ideias, em minutos, em grupo.
• Wireframe: para validar a estrutura e o fluxo, antes de decidir cores e tipografia.
• Maqueta: para validar o visual e o conteúdo com stakeholders.
• Protótipo interativo de alta fidelidade: para testar a experiência real com utilizadores e preparar a entrega ao desenvolvimento.

Regra prática: começar em papel e só avançar de nível quando a decisão anterior estiver validada.

Analisar necessidades e comportamentos

Antes de desenhar qualquer ecrã, é preciso perceber quem vai usar o sistema e porquê.

• Pesquisar e recolher informação junto de utilizadores reais: entrevistas, observação, inquéritos.
• Identificar objetivos, frustrações e o contexto de uso (em movimento, com pressa, com pouca luz).
• Registar comportamentos observados, não apenas opiniões declaradas.

Esta análise é uma das realizações centrais da UC e alimenta todo o desenho a seguir.

Cenários e modelo mental

Duas ferramentas da metodologia de design ajudam a transformar dados em decisões:

• Modelo mental: a ideia que o utilizador já tem de como algo deve funcionar (ex: um carrinho de compras funciona como um cesto físico).
• Cenário: uma pequena história concreta ("a Maria, no autocarro, quer marcar consulta em menos de um minuto").

Desenhar a favor do modelo mental e testar contra cenários reais evita interfaces que só fazem sentido para quem as construiu.

Arquitetura de informação

A arquitetura de informação organiza o conteúdo e as funcionalidades em categorias que fazem sentido para o utilizador, antes de desenhar um único ecrã.

• Listar todo o conteúdo e agrupá-lo por afinidade.
• Definir a hierarquia: o que é principal, o que é secundário.
• Desenhar o mapa de ecrãs (quantos ecrãs existem e como se relacionam).

Uma arquitetura confusa não se resolve com um design bonito por cima.

Fluxos de interação

Um fluxo é o caminho que o utilizador percorre, ecrã a ecrã, para completar uma tarefa.

• Desenha-se com esboços ligados por setas: ecrã inicial, decisões, ecrã final.
• Um bom fluxo tem o menor número de passos necessários, sem atalhos confusos.
• Fluxos alternativos (erro, cancelamento, sem resultados) fazem parte do desenho, não são um extra.

Desenvolver wireframes, esboços de interface e fluxos de interação é uma realização explícita desta UC.

Fundamentos do wireframing

O wireframe representa a estrutura de um ecrã (o que existe e onde fica) sem cor, tipografia definitiva ou imagens finais.

• Blocos, linhas e texto de substituição (lorem ipsum) em vez de conteúdo real.
• Foco na disposição: cabeçalho, navegação, conteúdo principal, rodapé.
• Permite discutir estrutura sem discutir gosto pessoal sobre cor.

O wireframe é o esqueleto que sustenta tudo o que vem depois.

Área de trabalho e ferramentas

As ferramentas de prototipagem organizam o trabalho em projetos, páginas e frames (o equivalente a cada ecrã).

• Figma: a ferramenta comercial mais usada no mercado, colaborativa em tempo real.
• Penpot: alternativa livre e de código aberto, com funcionalidades equivalentes, sem custo de licença.
• Conceitos comuns às duas: frames, camadas, componentes, biblioteca de estilos.

Escolher a ferramenta certa importa menos do que dominar estes conceitos, que são transferíveis entre programas.

Grelhas e espaçamento

A grelha (grid) organiza os elementos em colunas e linhas regulares, dando ordem visual ao ecrã.

• Grelha comum em web: 12 colunas, com margens e goteiras (gutters) definidas.
• O espaçamento deve seguir uma escala fixa (ex: múltiplos de 4 pixels: 4, 8, 12, 16, 24, 32).
• Elementos relacionados ficam mais próximos entre si do que de elementos não relacionados.

Uma grelha bem aplicada torna o ecrã legível mesmo antes de o utilizador ler o texto.

Consistência visual

O design de interfaces exige que os mesmos elementos se comportem sempre da mesma forma ao longo de todo o sistema.

• O mesmo botão, com o mesmo estilo, faz sempre o mesmo tipo de ação.
• As mesmas cores comunicam sempre o mesmo significado (ex: vermelho para erro).
• A consistência reduz a curva de aprendizagem: o utilizador só precisa de aprender o padrão uma vez.

Consistência de design, layout e interação é um dos critérios de desempenho avaliados nesta UC.

Estrutura de página e tipografia

O design UI (user interface) trata da camada visual concreta de cada ecrã.

• Estrutura de página: cabeçalho, navegação, conteúdo, chamadas para ação, rodapé.
• Tipografia: hierarquia clara entre título, subtítulo e texto corrido; poucas famílias de letra, usadas com consistência.
• Tamanhos de texto legíveis, mesmo em ecrãs pequenos.

Uma hierarquia tipográfica clara guia o olhar sem precisar de explicação.

Cor e elementos gráficos

• Cor: uma paleta reduzida, com uma cor principal, cores de apoio e cores de estado (sucesso, aviso, erro).
• Ícones e símbolos: sempre do mesmo estilo (todos preenchidos ou todos de contorno), nunca misturados.
• Botões: hierarquia clara entre ação principal, ação secundária e ação terciária.

Os elementos gráficos (ícones, símbolos e botões) fazem parte do referencial desta UC e devem ser tratados com o mesmo rigor da tipografia.

Metodologias de design de interfaces

O design de interfaces combina metodologia, modelo mental e cenários com o cuidado visual da consistência e da usabilidade.

• Começa pela pesquisa (bloco 3), passa pela arquitetura (bloco 4) e só depois desenha o ecrã final.
• Cada decisão visual deve poder justificar-se com o objetivo do utilizador, não só com gosto pessoal.
• A usabilidade (facilidade de uso) é medida, não é uma impressão subjetiva do designer.

Esta é a ponte entre a investigação e o ecrã bonito: sem ela, o design vira decoração.

Sistemas de componentes reutilizáveis

Um componente é um elemento de interface reutilizável (botão, campo de formulário, cartão) definido uma vez e usado em muitos ecrãs.

• Mudar o componente na biblioteca atualiza automaticamente todos os ecrãs que o usam.
• Um sistema de componentes garante a consistência visual à escala do projeto inteiro.
• Em Figma e Penpot, chamam-se componentes com variantes (ex: botão em três tamanhos e dois estados).

Construir um pequeno sistema de componentes desde o início poupa horas de retrabalho mais tarde.

Princípios do design responsivo

O design responsivo garante que a mesma interface funciona bem em ecrãs de tamanhos diferentes: telemóvel, tablet e computador.

• Layout fluido: colunas e larguras que se ajustam ao espaço disponível.
• Pontos de quebra (breakpoints): larguras a partir das quais o layout muda (ex: de uma coluna para três).
• Elementos que empilham em ecrãs pequenos e se distribuem lado a lado em ecrãs grandes.

Garantir a adaptabilidade a diferentes dispositivos e tamanhos de ecrã é um critério de desempenho explícito desta UC.

Exportação para diferentes plataformas

Depois de desenhado, o protótipo tem de ser exportado e partilhado de forma adequada a cada plataforma.

• Definir frames por dispositivo (telemóvel, tablet, desktop) dentro do mesmo projeto.
• Exportar ativos gráficos (ícones, imagens) nas resoluções corretas para cada ecrã.
• Partilhar uma ligação de protótipo navegável, sem exigir conta nem instalação a quem vai testar.

A exportação correta é o que torna o protótipo utilizável fora da ferramenta onde foi criado.

Criar ecrãs, elementos interativos e simulações

Depois de definida a estrutura, o passo seguinte é criar os ecrãs de interface, os elementos interativos (botões, campos, menus) e as simulações de funcionalidades que reproduzem o comportamento real do sistema.

• Cada ecrã deve corresponder a um passo do fluxo definido no bloco 4.
• Elementos interativos precisam de área de toque suficiente e de sinal visual claro de que reagem.
• Simular uma funcionalidade (ex: um formulário que "envia" e mostra confirmação) é o que distingue um protótipo de uma simples imagem.

Esta é uma das realizações centrais da UC: sem ecrãs e simulações credíveis, não há nada para testar.

Estados e variantes dos componentes

Cada componente interativo tem vários estados possíveis, que precisam de ser desenhados, não apenas imaginados.

Uma variante é uma versão alternativa do mesmo componente (ex: botão pequeno e botão grande). Desenhar os estados evita protótipos que só funcionam no "caminho feliz".

Transições e animações

Uma transição liga dois ecrãs ou dois estados de forma suave, em vez de um corte seco.

• Tipos comuns: dissolver, deslizar, aparecer a partir de um elemento (ex: um cartão que cresce até ecrã de detalhe).
• Duração: entre 150 e 300 milissegundos costuma parecer natural; mais lento do que isso irrita.
• Coerência: avançar sempre na mesma direção, recuar sempre na direção inversa.

A animação comunica a relação espacial entre ecrãs: o utilizador percebe "de onde veio" e "para onde vai".

Microinterações: úteis, não decorativas

Uma microinteração é um pequeno momento de resposta a uma ação, com um único propósito: confirmar, avisar ou guiar.

• Tem sempre um gatilho (o toque), uma regra (o que muda) e um retorno visual (o que o utilizador vê).
• É útil quando comunica informação que o utilizador precisa (a ação resultou? falhou? está a carregar?).
• É decorativa, e deve ser evitada, quando não comunica nada além de "olha, mexe-se".

O critério que separa as duas: se a removeres, o utilizador perde informação importante ou só perde um efeito bonito?

Variáveis e lógica condicional

Ferramentas de prototipagem mais avançadas permitem que o protótipo reaja a estado, em vez de mostrar sempre o mesmo conteúdo fixo.

SE carrinho > 0   MOSTRAR contador no ícone
SE campo vazio    DESATIVAR botão "Submeter"
SE resposta falha MOSTRAR mensagem de erro

• Uma variável guarda um valor (um contador, um texto, um estado ligado/desligado).
• Uma condição decide o que mostrar consoante essa variável.
• Isto aproxima o protótipo de um sistema real, sem escrever código de produção.

Simulações de funcionalidades

Simular uma funcionalidade é fazer o protótipo comportar-se como se a lógica real já existisse, sem que ela exista de verdade por trás.

• Um formulário que "valida" campos obrigatórios antes de avançar.
• Uma pesquisa que mostra resultados fixos, mas realistas, para o termo procurado.
• Um botão de "gostar" que alterna entre dois estados visuais.

Estas simulações são o que permite testar a experiência completa antes de qualquer linha de código de produção existir.

Contraste, foco e alvos de toque

Um protótipo acessível pode ser usado por mais pessoas, incluindo quem tem baixa visão, dificuldade motora ou usa apenas o teclado.

• Contraste: texto e fundo com diferença suficiente para se lerem com facilidade.
• Foco visível: quem navega por teclado tem de ver sempre onde está o cursor de foco.
• Alvos de toque: botões e ligações com área mínima confortável, especialmente em telemóvel.

Acessibilidade a todos os utilizadores é, tal como a adaptabilidade, um critério de desempenho desta UC.

Texto alternativo e adaptabilidade

• Texto alternativo: toda a imagem com significado precisa de uma descrição textual associada.
• Ordem de leitura: a sequência lógica dos elementos deve fazer sentido, também para quem usa um leitor de ecrã.
• Adaptabilidade: a interface deve continuar acessível quando o texto aumenta de tamanho ou o ecrã muda de orientação.

Um protótipo que já pensa nisto poupa retrabalho caro quando o produto chega ao desenvolvimento.

Plano de teste: objetivos, tarefas, recrutamento

Um teste de usabilidade não é uma conversa informal: precisa de um plano escrito.

• Objetivos: o que se quer aprender com este teste em concreto.
• Tarefas: pedidos realistas em forma de cenário ("encontra e reserva uma consulta para amanhã"), nunca instruções passo a passo.
• Recrutamento: participantes do público-alvo real; cerca de cinco por ronda costuma bastar para encontrar a maioria dos problemas.
• Métricas a observar: taxa de sucesso, tempo na tarefa, número de erros e satisfação percebida.

Conduzir: pensar em voz alta, não guiar

Durante o teste, pede-se ao participante para pensar em voz alta: descrever o que vê, o que espera e porque clica onde clica.

• O moderador observa e regista; não corrige, não ensina, não sugere o próximo passo.
• Faz apenas perguntas abertas: "o que esperavas que acontecesse agora?"
• Um silêncio desconfortável do participante é dado valioso, não um problema a resolver ajudando.

Guiar o participante destrói o valor do teste: os resultados deixam de dizer nada sobre a interface real.

Avaliação heurística e métricas do protótipo

Além do teste com utilizadores, existem princípios heurísticos que ajudam a avaliar uma interface mesmo sem sessão marcada.

• Visibilidade do estado do sistema, correspondência com o mundo real, controlo do utilizador, consistência, prevenção de erros.
• Cada heurística violada é um problema potencial a corrigir antes do teste com utilizadores reais.
• Métricas de desempenho do protótipo: taxa de sucesso, tempo médio por tarefa, número de erros por tarefa.

Combinar avaliação heurística com dados de teste dá uma imagem mais completa do que qualquer um dos dois sozinho.

Iteração, registo de decisões e entrega ao desenvolvimento

• Agrupar os problemas encontrados por tema e identificar padrões repetidos entre participantes.
• Priorizar por gravidade, frequência e esforço de correção; uma matriz impacto por esforço ajuda a decidir.
• Registar decisões: porque se mudou algo, com que evidência, o que ficou por resolver.
• Entrega ao desenvolvimento (handoff): especificação de ecrãs, estados, componentes, medidas e comportamento esperado.

O ciclo fecha-se: prototipar, testar, analisar, refinar e repetir até o protótipo estar validado e pronto a entregar.

Segurança e saúde no trabalho com ecrãs

Prototipar é um trabalho passado longas horas ao ecrã, com riscos próprios que as normas de segurança e saúde no trabalho procuram prevenir.

• Postura: ecrã à altura dos olhos, antebraços apoiados, costas direitas, cadeira ajustada.
• Pausas: intervalos curtos e regulares para levantar, alongar e descansar a vista.
• Iluminação: luz suficiente e sem reflexos diretos no ecrã, evitando contraluz.
• Fadiga visual: a regra "20 20 20" (a cada 20 minutos, olhar 20 segundos para algo a 20 pés de distância) ajuda a prevenir.

Proteção ambiental: equipamento e consumo

O trabalho de prototipagem depende de equipamento eletrónico, e as normas de proteção ambiental aplicam-se também aqui.

• Resíduos de equipamento elétrico e eletrónico (REEE): computadores, ecrãs e periféricos antigos não vão para o lixo comum; entregam-se em pontos de recolha próprios.
• Consumo de energia: configurar o equipamento para poupança de energia (suspensão automática, brilho ajustado) reduz o impacto ambiental do trabalho diário.
• Preferir ferramentas e fluxos que evitem impressões desnecessárias de protótipos em papel.

Aplicar estas normas é uma aptidão explícita do referencial desta UC, tal como as normas de segurança no trabalho.