Prototipagem e perguntas de avaliação

Um protótipo é uma representação parcial de uma proposta, e a pergunta de avaliação decide o que precisa de representar: para estudar a ordem das etapas, pode chegar papel, mas para medir a resposta de uma interação contínua precisamos de comportamento e tempos mais próximos do sistema real.

Fidelidade e cobertura são dimensões diferentes

A fidelidade pode referir-se ao aspeto visual, interação, conteúdo ou comportamento: um ecrã visualmente polido pode não executar uma única operação, enquanto um protótipo pouco polido pode ter uma operação implementada com dados reais de teste.

Cobertura	O que representa	Exemplo
Horizontal	Muitas funções com pouca profundidade	Percorrer todas as secções, sem guardar reservas
Vertical	Uma função em profundidade	Reservar uma sala com conflitos e validações, sem as outras secções

Não uses horizontal como sinónimo de baixa fidelidade, nem vertical como sinónimo de alta, pois são eixos distintos: um protótipo pode ser horizontal e visualmente polido, mostrando tudo e executando pouco.

Escolhe pelo que queres descobrir: para saber se a ordem seleção, revisão e confirmação é compreensível, um protótipo vertical em papel chega; para saber se o contraste e o tamanho dos alvos funcionam, precisas de fidelidade visual; para saber se a validação de conflitos responde a tempo, precisas de comportamento implementado.

Papel, storyboard e Wizard of Oz

Um storyboard mostra uma sequência em contexto, incluindo situações fora do ecrã. Um protótipo em papel permite experimentar estados e percursos trocando folhas, e um mockup representa uma interface com detalhe, podendo ou não permitir interação. No bodystorming, representamos fisicamente uma situação para explorar a interação no seu contexto: encarnar a compra de um bilhete com bagagem pode revelar mãos ocupadas ou dificuldade em alcançar controlos, sem provar ainda o desempenho do sistema final.

No Wizard of Oz, uma pessoa simula uma função ainda inexistente e o participante interage com o sistema aparente. Um exemplo é reconhecer um comando de voz e apresentar a resposta correspondente.

A simulação segue regras definidas: o operador decide a resposta segundo casos previstos, sem ajudar cada participante de forma diferente. Define respostas e tempos antes de começar, para que a ajuda não varie sem intenção de sessão para sessão.

O operador pode estar oculto ou ser conhecido, conforme a pergunta e o protocolo. O que caracteriza a técnica é simular a função, não o material usado: trocar folhas de papel serve para percorrer ecrãs, e decidir a resposta de um reconhecimento de voz ainda inexistente é simular essa função mesmo quando os ecrãs são de papel.

A técnica permite estudar a interação antes de construir o reconhecimento, porque o participante reage ao comportamento aparente. Não demonstra a precisão do algoritmo real nem a latência de produção.

Trata consentimento, informação fornecida e qualquer explicação posterior segundo o protocolo ético do estudo.

Do wireframe ao wireflow

Um wireframe representa a estrutura de um ecrã: que informação aparece e onde, enquanto um wireflow liga vários ecrãs pelas ações da pessoa, incluindo retornos e erros. O projeto atual pede wireflows, por isso desenha sempre as transições, não apenas ecrãs isolados.

Lê o wireflow como uma promessa de teste: cada seta é uma transição a percorrer com participantes.

Transição	O que testa
Rever para escolher	Se a correção conserva os dados
Ramo de conflito	Se a pessoa percebe que a sala ficou ocupada
Resposta incerta em “A enviar”	Se a pessoa compreende que o pedido continua pendente

“A enviar” não é sucesso, é o estado a aguardar resposta. Com resposta incerta, o fluxo volta a rever com os dados preservados e repete a mesma tentativa.

Repetir sem duplicar pressupõe apoio do servidor, que um desenho do fluxo não demonstra. O protótipo testa o que a pessoa compreende nesse retorno, não o mecanismo.

Um protótipo de estados

O exemplo tem três estados: escolher sala, rever a escolha e apresentar a confirmação, sem reservar uma sala real; usa-o para perguntar se a distinção entre selecionar e confirmar é compreensível.

Experimenta B102, volta à escolha e muda para B101: voltar à escolha deve conservar a sala selecionada, permitindo corrigi-la antes de confirmar. Percorre também o exemplo com teclado. Depois de confirmares, a página mostra a mensagem de simulação junto da escolha reaberta; lê-a como resultado da simulação, não como estado persistente da reserva. O protótipo não inclui conflito de disponibilidade, autenticação nem recuperação de uma falha de rede; não serve para concluir que esses casos são utilizáveis.

Antes de testar, prevê o que esperas observar (onde hesitam, que nome dão à ação e que estado esperam depois de confirmar) e regista desvios a essa previsão em vez de apenas seguir o guião.

Preparar e interpretar a avaliação

Regista a pergunta, tarefas, estados implementados, ações simuladas e limites, mantendo conteúdos plausíveis: um texto como “Lorem ipsum” não permite avaliar compreensão de uma mensagem de erro.

A baixa fidelidade pode favorecer alterações rápidas, mas também esconder problemas de contraste, tamanho dos alvos ou detalhes do conteúdo, enquanto a alta fidelidade pode permitir avaliar esses detalhes mas levar participantes a assumir que tudo funciona. Explica o âmbito sem ensinar o percurso que pretendes estudar.

Após o teste, liga cada observação a uma decisão. Se as pessoas interpretam “Rever” como confirmação, investiga o texto e os estados. Não concluas que o sistema completo falhou porque uma função declaradamente ausente não executou.