Roteiro de testes de usabilidade para protótipos no Figma

Um roteiro de testes de usabilidade para protótipos no Figma transforma uma conversa subjetiva sobre telas em uma investigação organizada. Em vez de perguntar apenas se a pessoa gostou do layout, você observa se ela entende a proposta, encontra a função principal e consegue concluir uma tarefa sem receber pistas da equipe. Essa diferença ajuda PMEs, fundadores e times de produto a separar opinião pessoal de evidência de uso. O protótipo navegável não precisa conter todas as funcionalidades do produto final. Um fluxo com seis ou oito telas pode ser suficiente para avaliar uma hipótese central, como solicitar um atendimento, simular uma transferência, agendar uma consulta ou finalizar uma compra. O critério é simples: o protótipo deve representar o caminho necessário para aprender algo relevante antes de definir a implementação. Para uma empresa de Tubarão, o teste pode ser feito presencialmente ou por chamada de vídeo, com participantes recrutados na própria região e em cidades próximas quando o público do produto exigir. A proximidade facilita compreender expressões, hábitos e situações de uso que uma pesquisa genérica pode não revelar. Ainda assim, a seleção deve seguir o perfil da persona, e não apenas a facilidade de convidar colegas ou conhecidos. A prática se conecta ao processo de descoberta descrito no guia sobre como usar um protótipo navegável no Figma para validar hipóteses, mas aqui o foco é operacional: preparar a sessão, conduzir tarefas, registrar observações e converter achados em prioridades. O objetivo não é provar que a ideia está certa. É descobrir quais premissas precisam ser ajustadas enquanto ainda é possível mudar o escopo com agilidade.

Um bom script funciona como um mapa, não como um questionário rígido. Ele dá consistência entre entrevistas, mas permite que o moderador explore uma reação inesperada. Uma sessão remota costuma caber em 30 a 45 minutos, dependendo da quantidade de tarefas e da complexidade do produto. Se você precisar de gravação, explique o motivo e solicite autorização antes de começar. Abertura, de 3 a 5 minutos: "Obrigado por participar. Estamos avaliando uma ideia e não você. O protótipo ainda está em teste, então qualquer dificuldade pode indicar uma melhoria na solução. Vou pedir que você realize algumas tarefas e fale o que está pensando. Não vou explicar o caminho, porque queremos entender o que seria natural para você. Podemos começar?" Aquecimento, de 5 minutos: pergunte sobre a situação real relacionada ao problema. Em uma fintech, por exemplo: "Conte como você acompanha o fluxo de caixa hoje". Em uma healthtech: "Como costuma agendar ou confirmar um atendimento?". Em um e-commerce: "O que você normalmente verifica antes de concluir uma compra?". Essas perguntas ajudam a comparar o comportamento observado com a rotina, sem induzir a pessoa a elogiar a proposta. Tarefa principal: apresente um cenário, não o nome do botão. Em vez de dizer "clique em Agendar consulta", diga: "Você precisa marcar uma consulta para a próxima semana e quer sair desta tela com o horário confirmado. Mostre como faria". Depois, permaneça em silêncio por alguns segundos. Se a pessoa pedir ajuda, responda: "O que você tentaria se eu não estivesse aqui?" e registre que houve necessidade de apoio. Perguntas de aprofundamento: após cada tarefa, pergunte: "O que você esperava que acontecesse?", "O que chamou sua atenção nesta tela?", "Houve algum momento de dúvida?" e "Como você faria isso no seu processo atual?". Evite perguntar "você usaria esta função?" como única medida, porque a resposta declarada pode ser diferente do comportamento em uma situação real. Encerramento: peça que a pessoa descreva o que entendeu sobre a solução em uma frase, identifique o trecho mais fácil e o mais difícil e indique o que faltou para confiar no fluxo. Agradeça sem defender decisões de design. Explicar por que uma tela foi criada pode influenciar os próximos participantes e reduzir a qualidade da evidência.

Métricas não substituem a observação, mas ajudam a organizar padrões. Para cada tarefa, registre conclusão, tempo aproximado, quantidade de erros de navegação, pedidos de ajuda e nível de confiança declarado. Não transforme uma amostra pequena em uma estatística de mercado. Use os números como sinais para comparar tarefas e decidir o que merece investigação adicional. A taxa de conclusão pode ser calculada dividindo o número de participantes que chegaram ao objetivo sem orientação pelo número total de pessoas que tentaram a tarefa. Se quatro de seis participantes completarem um fluxo, anote 67% e preserve o contexto: quem concluiu, em que tela hesitou e que informação já conhecia. Em testes iniciais, a explicação por trás da falha costuma ser mais valiosa que o percentual isolado. O tempo de execução é útil quando a tarefa tem uma expectativa clara, como localizar um pedido ou confirmar uma consulta. Meça do momento em que o cenário é apresentado até a conclusão, sem pressionar a pessoa. Uma duração muito alta pode apontar para rótulos pouco claros, excesso de etapas ou falta de informação, mas também pode refletir pouca familiaridade com o problema. Para a parte qualitativa, classifique cada observação por tipo: compreensão, navegação, conteúdo, confiança, acessibilidade ou expectativa. Registre a fala literal quando ela revelar o modelo mental do participante, como "achei que este botão cancelaria tudo". O padrão de acessibilidade para conteúdo web WCAG 2.2 oferece referências úteis para avaliar contraste, foco, nomes de controles e alternativas para diferentes formas de interação. Uma ficha simples pode conter estas colunas: participante, tarefa, conclusão, tempo, ponto de hesitação, fala, severidade, frequência, hipótese afetada e recomendação. Para severidade, use uma escala de 1 a 4, em que 1 é uma observação cosmética e 4 impede a conclusão ou pode levar a uma decisão equivocada. A escala é uma convenção interna, não uma medida universal, portanto documente seus critérios.

O recrutamento local começa com uma definição precisa de quem enfrenta o problema. Para um sistema de gestão financeira voltado a pequenos negócios, por exemplo, o perfil pode ser proprietário ou responsável pelo caixa de uma empresa com rotina semanal de conciliação. Para uma solução de saúde, pode ser necessário separar paciente, recepcionista e profissional, porque cada grupo usa o produto com objetivos diferentes. Em Tubarão, procure participantes por canais coerentes com o público: contatos profissionais dos decisores, entidades empresariais, parceiros de pesquisa, redes de empreendedores, universidades e convites direcionados em comunidades locais. O convite deve informar duração, formato, tema geral e tratamento dos registros, mas não deve revelar o caminho esperado. Incentivos, quando adotados, precisam ser proporcionais e não podem criar pressão para a pessoa agradar a equipe. Evite montar a amostra apenas com funcionários, amigos ou pessoas que já conhecem o projeto. Esse grupo tende a completar lacunas com conhecimento prévio e pode esconder problemas de linguagem. Se o produto atende várias cidades, faça uma primeira rodada local para aprender com proximidade e valide depois se os achados continuam pertinentes em outros contextos. Uma rodada inicial pode começar com cinco a oito participantes por perfil quando o objetivo for encontrar problemas recorrentes de interação, desde que a equipe trate esse número como uma amostra exploratória e não como representação estatística da população. O Nielsen Norman Group explica a lógica de testes iterativos com poucos participantes, mas a decisão deve considerar complexidade, diversidade de perfis e consequência de uma interpretação errada. Na Consultoria Orbe Soft, o recrutamento é conectado ao diagnóstico, às personas e às jornadas. Essa sequência evita testar um protótipo com pessoas que não correspondem ao público prioritário. Quando a empresa ainda não consegue descrever quem tem o problema, o caminho adequado é voltar uma etapa e organizar a pesquisa de mercado e a definição de público antes de concluir que a interface falhou.