Prototipação & Usabilidade

Guia da quest

O protótipo nasce aqui

Nenhuma quest anterior pediu protótipo. A Q6 diz literalmente “nesta quest não precisa prototipar” — ali o que se testa é o conceito, com o meio mais barato disponível. É nesta quest que o artefato testável é construído.

Se a sua equipe já construiu algo na Q6, ótimo — use. Se não construiu, você não está atrasado.

A entrega não é o protótipo

É o aprendizado. Todas as perguntas da quest são sobre o que os testes revelaram, não sobre o que foi construído. Equipe que entrega um protótipo lindo e nenhuma descoberta não cumpriu a quest.

Vale registrar uma coisa que a metodologia diz e é fácil esquecer: entender uma solução para a qual não se tem referência prévia é mais difícil que o normal. O que parece simples para quem está imerso produz percepção completamente diferente em quem tem o primeiro contato.

Você é a pior pessoa para avaliar a usabilidade do seu produto. A segunda pior é a IA que o construiu com você.

O método: três usuários por rodada, uma manhã por rodada

Três participantes por rodada. É o número ideal para teste feito pela própria equipe.

A objeção óbvia — três é amostra pequena demais e não acha todos os problemas — é verdadeira e irrelevante, por três motivos:

1. O propósito não é provar nada. Provar exigiria teste quantitativo, amostra grande e análise estatística. Isto é qualitativo: você dá tarefas, observa e aprende. O resultado são insights acionáveis, não prova.
2. Você não precisa achar todos os problemas — e não adiantaria: você acha mais problemas em meia manhã do que consegue consertar em um mês.
3. Mais rodadas vencem rodada mais completa. É muito mais importante fazer mais rodadas do que espremer cada uma.

Testar um usuário cedo no projeto é melhor que testar 50 perto do fim. — Steve Krug

A cadência: uma manhã por rodada, com a equipe toda. Três usuários, depois debriefing no almoço — e ao sair do almoço a equipe já decidiu o que vai consertar. Marque dia fixo, não amarre a etapas do cronograma: cronograma escorrega, e o teste escorrega junto.

⚠️ Krug propõe cadência mensal; a Q8 dura uma semana. No livro, a manhã de teste é um ritual de calendário (a terceira quinta-feira de cada mês) porque ele fala de produto em operação contínua. Aqui o ciclo é comprimido: duas rodadas dentro da mesma semana, uma no começo e outra depois dos consertos. A lógica é a mesma — testar cedo, pouco e de novo —, só que o “de novo” acontece em dias, não em meses. Depois da Q8, se a equipe seguir construindo até o Demoday, a cadência mensal do livro volta a ser a referência.

⚠️ Três por rodada, não três no total. O enunciado da quest no site dá “10 usuários afoitos” como exemplo de resposta, e os dois números não se contradizem: 3 é o tamanho da rodada, 10 é a ordem de grandeza de quem a equipe ouve ao longo do projeto. Numa semana, isso são no mínimo duas rodadas de 3 — a segunda testando o que a primeira mandou consertar. Uma rodada só entrega uma lista de problemas; a segunda é que mostra se a correção funcionou, e é isso que a quest cobra. Se a equipe fizer 10 pessoas numa sessão única, terá gastado o dobro do tempo para aprender menos.

Infraestrutura mínima: sala silenciosa, mesa, duas cadeiras, computador, e software de gravação de tela.

Recrutar solto e corrigir na leitura

Equipes gastam tempo demais tentando achar o perfil exato. Recrutar exatamente do público-alvo não é tão importante quanto parece — se você está começando a testar, o produto provavelmente tem falhas que travam qualquer um.

Recrute solto, e corrija na hora de interpretar. — Steve Krug

Na prática: procure gente que reflita o seu público, mas não trave nisso. Afrouxe os requisitos e faça a compensação mental depois. Quando alguém tiver um problema, pergunte-se:

“Os nossos usuários teriam esse problema, ou foi problema só porque essa pessoa não sabe o que eles sabem?”

E há um argumento a favor de sempre incluir alguém de fora do público-alvo:

1. Projetar de modo que só o público-alvo consiga usar costuma ser má ideia — parte dos próprios especialistas não entende o jargão.
2. Somos todos iniciantes por baixo da pele. Arranhe um especialista e você acha alguém se virando — só que num nível mais alto.
3. Especialistas raramente se ofendem com algo que está claro o bastante para iniciantes.

Se o produto exige conhecimento de domínio, você precisa de alguns participantes com esse conhecimento — não de todos.

O roteiro da sessão

Uma hora, minuto a minuto:

Escolha tarefas, não telas. “Encontre um grupo de corrida no seu bairro e entre nele” é tarefa. “Veja a tela de grupos” não é. E prefira tarefas em que a pessoa escolhe parte dos detalhes — “encontre um livro que você queira comprar” em vez de “encontre um livro de culinária abaixo de R$40” — porque aumenta o investimento emocional.

O que o facilitador PODE dizer

• “Estamos testando o site, não você. Você não pode fazer nada errado aqui.”
• “Por favor, não se preocupe em ferir os nossos sentimentos.”
• Quando a pessoa silencia: “No que você está pensando?”, “O que você está olhando?”, “O que você está fazendo agora?”
• Se pedirem ajuda: “O que você faria se eu não estivesse aqui?”
• Avise que as perguntas serão respondidas no fim — interessa saber como as pessoas se viram sozinhas.

O que o facilitador NÃO PODE fazer

Não faça perguntas indutoras, e não dê nenhuma pista ou ajuda, a menos que a pessoa esteja irremediavelmente travada ou extremamente frustrada.

Guarde as perguntas investigativas para o bloco de sondagem, justamente para não enviesar durante as tarefas. E escolha como facilitador alguém paciente, calmo, empático e bom ouvinte.

O debriefing — e a triagem que define a nota

Durante: no intervalo após cada sessão, cada observador escreve os três problemas mais sérios que notou. Podem anotar o que quiserem, mas a lista curta é obrigatória.

Depois: logo em seguida, com tudo fresco.

Por que a triagem existe

Problemas sérios aparecem sempre — mas não são os que acabam consertados. Ou alguém diz “essa parte vai mudar mesmo, dá pra conviver”, ou, diante da escolha entre um problema grave e vários simples, a equipe escolhe os simples. É por isso que sites grandes e bem financiados têm problemas graves.

Foque implacavelmente em consertar primeiro os problemas mais sérios.

O método, em quatro passos

1. Lista coletiva. Cada pessoa diz os três problemas mais sérios que observou. Escreve tudo no quadro; repetição vira um tique. Sem discussão nesta etapa, e só valem problemas observados — coisas que de fato aconteceram numa sessão.
2. Escolher os dez mais sérios, começando pelos mais repetidos.
3. Ordenar de 1 a 10, 1 sendo o pior.
4. Lista acionável: para cada um, de cima para baixo — como consertar no próximo mês, quem faz, que recursos exige.

Duas regras de parada: você não precisa consertar cada problema perfeitamente; basta fazer algo — muitas vezes um ajuste — que o tire da categoria de “problema sério”. E quando o tempo do mês estiver alocado, pare.

As quatro armadilhas do debriefing

• Lista separada de fruta baixa. Coisas fáceis (uma pessoa, menos de uma hora) ficam fora da lista principal, para não competirem com o que é grave.
• Resista ao impulso de acrescentar. Quando o usuário não entende, o reflexo é adicionar explicação. Muitas vezes o certo é tirar o que está obscurecendo o sentido.
• Trate pedido de funcionalidade com ceticismo. Peça para a pessoa descrever a funcionalidade na sondagem e ela quase sempre conclui sozinha que não usaria. Participantes não são designers.
• Ignore problemas de caiaque. Desvios momentâneos em que a pessoa se recupera sozinha, rápido, sem se abalar. Se o segundo palpite dela sobre onde achar as coisas está sempre certo, está bom o bastante.

Os três tipos de problema mais frequentes: a pessoa não entende o conceito; as palavras que ela procura não estão lá; há coisa demais acontecendo — o alvo está na página mas não é visto.

Classificar o que aconteceu: deslize ou engano?

Esta é a ferramenta que transforma “não conseguiu usar” em diagnóstico acionável.

Deslizes acontecem quando o objetivo está correto, mas as ações não são executadas direito — a execução falhou. Enganos acontecem quando o objetivo ou o plano está errado.

— Donald Norman, O design do dia a dia

Deslize (a pessoa sabia o que queria e errou a execução)

Propriedade contraintuitiva: deslizes são mais frequentes em especialistas que em novatos, porque o especialista automatiza e não presta atenção consciente.

Engano (a pessoa executou corretamente um plano errado)

Aqui o alvo do conserto é o modelo conceitual, o vocabulário e a informação de estado — não o botão.

Distinção operacional que muda o teste: enganos são difíceis de detectar. Como as ações seguintes são coerentes com o objetivo errado, observar as ações não revela o erro. Engano só aparece se a pessoa pensar em voz alta ou se você perguntar na sondagem. Deslize aparece sozinho.

Onde exatamente o usuário travou

Sete fases da ação — uma de objetivo, três de execução, três de avaliação — e os dois golfos:

Ao usar algo, as pessoas enfrentam dois golfos: o Golfo da Execução, ao tentar descobrir como aquilo funciona, e o Golfo da Avaliação, ao tentar descobrir o que aconteceu. O papel do designer é ajudar a atravessar os dois.

— Donald Norman

Atravessa-se o Golfo da Execução com significantes, restrições, mapeamentos e modelo conceitual. Atravessa-se o Golfo da Avaliação com feedback e modelo conceitual.

A tabela de diagnóstico

Significantes, não affordances

Uma correção que o próprio autor fez ao termo que ele popularizou: desenhar um círculo indicando onde tocar não é criar uma affordance — a affordance de tocar existe na tela inteira. Você está sinalizando onde o toque deve acontecer.

Affordances determinam que ações são possíveis. Significantes comunicam onde a ação deve acontecer. — Donald Norman, O design do dia a dia

No design, significantes são mais importantes que affordances, porque comunicam como usar.

Regra de bolso para avaliar protótipo: toda vez que você vê um aviso escrito à mão colado num controle explicando como usá-lo, você está vendo design ruim.

Feedback — três exigências

Imediato (até um décimo de segundo de atraso já desconcerta), informativo (bipe genérico diz que algo aconteceu, não o quê) e priorizado. E duas advertências: feedback ruim pode ser pior que nenhum, porque distrai e irrita; e feedback demais incomoda mais que de menos.

Fidelidade: escolha pelo que quer descobrir

Aviso específico da era da IA: a facilidade de gerar alta fidelidade não é razão para pular a baixa. O protótipo de papel continua melhor para testar conceito, porque ninguém tem medo de dizer que um rabisco está errado.

Mágico de Oz — quando o back-end não existe: um membro da equipe simula as respostas do sistema por trás da cortina enquanto o participante interage com algo que parece real. A credibilidade depende de comportamento consistente do “mago” quanto a tempo, padrões e lógica. Especialmente útil em produtos com IA, onde o modelo pode ser um humano na primeira rodada.

Inspeção não substitui usuário

A independência antes da agregação é o que mitiga o viés de qualquer avaliador. E os dois métodos revelam classes diferentes de problema — use os dois, não um no lugar do outro.

As perguntas da entrega

1. As pessoas se mostraram motivadas a usar o protótipo?
2. O protótipo funciona corretamente?

⚠️ Cuidado com a pergunta 1. Teste de usabilidade não mede desejabilidade — ele mede se a pessoa consegue fazer, não se ela quer. Querer é pergunta de pesquisa com usuário, e a resposta de quem está sentado num teste é enviesada pela cortesia.

O que fazer: responda a pergunta 1 com evidência de outra origem — o que os usuários afoitos disseram, quantos aceitaram continuar usando depois da sessão, quantos pediram acesso — e declare de onde veio. Responder “60% gostaram” a partir do próprio teste é medir educação, não motivação.

3. Qual o perfil e a quantidade de usuários que testaram?
4. O usuário aprovou as funcionalidades?
5. O usuário se sentiu familiarizado, ou teve dificuldade? Em qual tarefa teve mais dificuldade?
6. O que precisa mudar?

A pergunta 5 é a que dá o milestone. Note o formato esperado: ela nomeia a tarefa específica. “Acharam um pouco confuso” não é resposta.

Referências desta quest

Antes de registrar pessoas

Técnicas desta quest

Fichas curtas de consulta rápida. Abra quando o procedimento acima mencionar a técnica.

Perguntas frequentes

“Podemos testar com colegas de turma?” Só se forem do perfil. Colega sabe o que você está fazendo, quer te ajudar e domina tecnologia — as três coisas contaminam. Se não houver alternativa, declare a limitação na entrega; declarar é melhor que disfarçar.

“O gerente da equipe não sabe gerenciar.” Ninguém sabe — todos estão aprendendo. Cheque três coisas: ele quer o papel; ele não está ouvindo a equipe ou apenas não está fazendo o que você queria; e ele está tentando melhorar. Se há esforço de aprendizado, as coisas estão andando como deveriam.

Bibliografia desta quest

Diagnóstico de erro

Abra este arquivo depois do teste, com as notas na mão, quando for preciso transformar “não conseguiu usar” em uma frase que diz o que consertar. É o vocabulário que separa uma entrega nível 2 de uma entrega nível 4 na Q8: nível 2 diz “os usuários acharam confuso”; nível 4 diz “o participante 2 travou na fase de especificar a ação, por falta de significante no botão de convite — vamos rotular o ícone”.

Modo de IA: com apoio. A IA é boa em ajudar a classificar um episódio já descrito — pergunte a ela por que um caso é engano e não deslize, e peça que ela aponte a evidência que falta. Ela não pode classificar o que não observou.

1. Deslize ou engano: a bifurcação

Toda a classificação de erro humano usada aqui vem da divisão que Donald Norman e o psicólogo britânico James Reason estabeleceram, e que hoje é usada em estudos de acidentes industriais, de aviação e de erro médico.

Deslizes acontecem quando o objetivo está correto, mas as ações não são executadas direito — a execução falhou. Enganos acontecem quando o objetivo ou o plano está errado.

A consequência prática vem antes de qualquer subtipo:

Norman também registra que a distinção entre detectar um e outro não é simétrica: lapsos de memória são difíceis de detectar precisamente porque não há nada para ver — a ação devida não foi executada, e quando nenhuma ação acontece, não há o que detectar. Só quando a ausência de ação provoca algum evento indesejado é que existe chance de perceber.

⚠️ Por que isso muda o seu roteiro de teste. Se a equipe não insistir no “pensar em voz alta” e pular o bloco de sondagem, ela vai voltar do campo com uma lista só de deslizes — e vai consertar botões enquanto o problema real é que ninguém entendeu para que serve o produto. O bloco de sondagem não é sobra de tempo: é o único instrumento que detecta engano.

2. Os deslizes, subtipo por subtipo

Norman divide deslizes em dois grupos: baseados em ação (a ação errada é executada) e lapsos de memória (a memória falha, e a ação pretendida não é feita, ou o resultado não é avaliado).

Deslize de captura

O que é: em vez da atividade pretendida, uma outra, mais frequente ou mais recente, é executada — ela captura a atividade. Exige que parte das duas sequências de ação seja idêntica, com uma delas sendo muito mais familiar. Depois da parte idêntica, a atividade mais frequente continua sozinha, e a pretendida não acontece. Norman observa que a sequência não familiar raramente, ou nunca, captura a familiar. Basta um lapso de atenção no ponto crítico em que as sequências se separam. São, portanto, erros parciais de memória.

Por que aparece em especialistas: o experiente automatizou as ações e pode não estar prestando atenção consciente exatamente quando a ação pretendida se desvia da mais frequente.

A cura: desenhe sequências que difiram desde o início. Norman é explícito ao fechar o capítulo: procedimentos devem ser projetados de modo que os passos iniciais sejam tão dissimilares quanto possível. E forneça auxílio e lembretes visíveis para procedimentos pouco frequentes que se parecem com outros muito frequentes.

Como aparece no seu protótipo: dois fluxos que começam pelos mesmos três toques e divergem no quarto. Salvar rascunho e publicar. Convidar para o grupo e entrar no grupo.

Deslize por semelhança de descrição

O que é: agir sobre um item semelhante ao alvo, porque a descrição interna do alvo era vaga demais. Norman dá o mecanismo: se a descrição mental era algo como “um recipiente grande o bastante”, tanto o cesto de roupa quanto o vaso sanitário satisfazem. Acontece mais quando a pessoa está cansada, estressada ou sobrecarregada.

A cura: garantir que controles e telas de propósitos diferentes sejam significativamente diferentes entre si. Norman é enfático: uma fileira de interruptores ou mostradores de aparência idêntica é receita quase certa para esse erro. Em cabines de avião, muitos controles são codificados por forma, de modo a parecer e se sentir diferentes — a alavanca de flap tem o formato de um flap de asa; o controle do trem de pouso, o de uma roda.

Como aparece no seu protótipo: três botões iguais em cinza, com rótulos parecidos, um ao lado do outro. Duas listas idênticas em telas diferentes.

Lapso de memória

O que é: a pessoa pula uma etapa, repete uma etapa, esquece o resultado da ação, ou esquece o objetivo no meio do caminho.

A causa imediata, segundo Norman, é quase sempre interrupção: eventos que se interpõem entre o momento em que a ação foi decidida e o momento em que ela seria concluída. E boa parte da interferência vem das próprias máquinas — os muitos passos exigidos entre o início e o fim da operação sobrecarregam a memória de trabalho.

As curas, em ordem de força:

1. Minimizar o número de passos.
2. Lembretes vívidos dos passos que ainda faltam.
3. Função de força — o método superior. O caixa eletrônico que exige a retirada do cartão antes de entregar o dinheiro impede o esquecimento do cartão, aproveitando o fato de que as pessoas raramente esquecem o objetivo da atividade, que aqui é o dinheiro.

Norman é honesto sobre o limite: nem todo lapso de memória admite solução simples, porque muitas interrupções vêm de fora do sistema, onde o projetista não tem controle.

E um alerta que vale para todo formulário longo: listas de verificação impressas têm uma falha grande — forçam os passos a seguir uma ordem sequencial mesmo quando isso não é necessário nem possível. Quando um item não pode ser feito na hora em que aparece, a pessoa o pula pretendendo voltar depois. Isso é uma oportunidade clara de lapso de memória.

Erro de modo

O que é: o dispositivo tem estados diferentes nos quais os mesmos controles têm significados diferentes. Esses estados são os modos. Norman é direto sobre a inevitabilidade: erros de modo são inevitáveis em qualquer coisa que tenha mais ações possíveis do que controles ou telas disponíveis — e isso é inescapável à medida que acrescentamos funções.

A tentação que os cria: parece econômico ter dez funções e apenas dois controles, um para escolher a função e outro para ajustá-la. O resultado parece simples e fácil de usar, mas essa simplicidade aparente mascara a complexidade de uso: o operador precisa estar sempre completamente ciente de qual modo está ativo. A prevalência dos erros de modo mostra que essa premissa é falsa. E o problema piora quando o modo é selecionado e a pessoa é interrompida, ou quando o modo se mantém por períodos longos.

A frase que a equipe precisa decorar: erro de modo é, na verdade, erro de projeto. Erros de modo são especialmente prováveis quando o equipamento não torna o modo visível, e se espera que o usuário se lembre de qual modo foi estabelecido — às vezes horas antes, com muitos eventos no meio.

A cura: eliminar modos. Se não for possível, tornar óbvio qual modo está ativo. Norman registra a correção que a Airbus fez depois de um acidente em que os pilotos acreditavam controlar o ângulo de descida quando controlavam a velocidade vertical: passou a exibir velocidade vertical sempre com quatro dígitos e ângulo com dois, reduzindo a chance de confusão.

Como aparece no seu protótipo: o mesmo botão “+” que cria tarefa numa aba e cria projeto em outra. O modo de edição que não se distingue do modo de leitura.

3. Os enganos, subtipo por subtipo

Enganos resultam da escolha de objetivos e planos inadequados, ou de comparação falha entre resultado e objetivo. Norman classifica em três, apoiado na distinção do engenheiro dinamarquês Jens Rasmussen entre comportamento baseado em habilidade, baseado em regra e baseado em conhecimento.

Por que enganos baseados em regra são difíceis de evitar e difíceis de detectar: uma vez classificada a situação, escolher a regra costuma ser direto. Mas se a classificação está errada, isso é difícil de descobrir, porque normalmente há bastante evidência sustentando a classificação errada. Em situações complexas o problema é informação demais — informação que sustenta a decisão e informação que a contradiz. Sob pressão de tempo, é difícil saber qual considerar e qual rejeitar.

E há um viés previsível: as pessoas decidem casando a situação atual com algo que aconteceu antes, e esse casamento é enviesado por recência, regularidade e unicidade. Diante de algo genuinamente novo, a pessoa ainda assim encontra algum casamento na memória para usar como guia.

Um exemplo que Norman dá e que serve de teste para o seu produto: girar o termostato do forno até o máximo para ele chegar mais rápido à temperatura de cozimento é engano baseado num modelo conceitual falso do funcionamento do forno. Pergunte-se se o seu produto tem um controle que convida a esse tipo de raciocínio.

Diagnóstico duplo. Norman analisa um caso comum de computador — fechar a janela errada e aceitar a caixa de diálogo sem ler — e conclui que houve os dois erros: emitir o comando “fechar” com a janela errada ativa é lapso de memória (deslize); decidir não ler a caixa de diálogo e aceitá-la sem salvar é engano. Um episódio pode conter os dois. Não force a escolha.

4. As sete fases da ação

Toda ação tem duas partes — executar e avaliar; fazer e interpretar. Norman decompõe em sete fases: uma de objetivo, três de execução, três de avaliação.

Norman é claro sobre os limites do modelo: ele é simplificado; nem toda atividade percorre as sete fases em sequência, objetivos geram subobjetivos, e há atividades em que o objetivo é esquecido ou reformulado. Nem tudo é consciente — só quando algo novo ou um impasse rompe o fluxo é que a atenção consciente entra. E o ciclo tanto pode começar em cima, no objetivo (comportamento dirigido a objetivo), quanto embaixo, disparado por um evento do mundo (dirigido a dados ou a eventos).

Onde cada erro nasce: enganos são erros nas fases altas — estabelecer objetivo ou plano, e comparar resultado com expectativa. Deslizes acontecem na execução do plano, ou na percepção e interpretação do resultado — as fases baixas. Lapsos de memória podem acontecer em qualquer uma das oito transições entre fases, e um lapso numa transição impede o ciclo de prosseguir, de modo que a ação desejada não se completa.

Uso adicional, que serve à Q2 tanto quanto à Q8: as sete fases servem de guia para desenvolver produtos novos. Os golfos são o ponto óbvio de partida, porque cada um deles é uma oportunidade de melhoria — o truque é desenvolver a habilidade de observação para detectá-los. Ideias radicais, que criam categorias novas, vêm de reconsiderar o objetivo, perguntando qual é o objetivo real — o que Norman chama de análise de causa-raiz.

5. Os dois golfos, e como atravessá-los

Ao usar algo, as pessoas enfrentam dois golfos: o Golfo da Execução, ao tentar descobrir como aquilo funciona, e o Golfo da Avaliação, ao tentar descobrir o que aconteceu. O papel do designer é ajudar a atravessar os dois.

O Golfo da Avaliação reflete o esforço que a pessoa tem de fazer para interpretar o estado físico do dispositivo e determinar quão bem as expectativas e intenções foram atendidas. Ele é pequeno quando o dispositivo oferece informação sobre o próprio estado numa forma fácil de obter, fácil de interpretar e compatível com o modo como a pessoa pensa o sistema.

Há um par de termos que organiza isso e que vale usar na apresentação da Q8:

• Feedforward — a informação que ajuda a responder às perguntas de execução (o que dá para fazer, como faço). Vem de significantes, restrições e mapeamentos, com o modelo conceitual como base. O termo é emprestado da teoria de controle.
• Feedback — a informação que ajuda a entender o que aconteceu. Vem de informação explícita sobre o impacto da ação, de novo com o modelo conceitual como base.

Norman acrescenta a condição que quase toda equipe esquece: os dois precisam ser apresentados numa forma que as pessoas que usam o sistema consigam interpretar. A apresentação tem de corresponder ao modo como a pessoa vê o objetivo que persegue e às expectativas dela.

Quem deve conseguir responder às sete perguntas? Qualquer pessoa que use o produto, sempre. Isso põe o ônus no projetista: garantir que, em cada fase, o produto forneça a informação necessária para responder.

6. A tabela de diagnóstico

Use esta tabela lendo as notas do teste. A coluna da esquerda é o que você anotou; as outras três são o diagnóstico.

Ação: para cada um dos dez problemas priorizados no debriefing, preencha as quatro colunas antes de escrever o conserto. Problema que não cabe em nenhuma linha provavelmente não é problema de usabilidade — é pedido de funcionalidade disfarçado.

7. Significantes, não affordances

Esta é uma correção que o próprio Norman fez ao termo que ele popularizou, e que ele explica na revisão do livro: a primeira edição focava em affordances, mas embora affordances façam sentido para objetos físicos, elas confundem quando se trata de objetos virtuais — e criaram muita confusão no mundo do design.

Affordance é a possibilidade de interação que existe no mundo entre um agente e algo. Algumas affordances são perceptíveis, outras são invisíveis. Se uma affordance não pode ser percebida, é preciso algum meio de sinalizar que ela existe — e a esse meio Norman dá o nome de significante.

Significante é qualquer marca, som ou indicador perceptível que comunique o comportamento apropriado a uma pessoa. Pode ser deliberado — a placa “EMPURRE” na porta — ou acidental: a trilha aberta na neve por quem passou antes, o número de pessoas esperando na plataforma como sinal de que o trem já passou ou não. Norman insiste que não faz diferença se o sinal foi colocado de propósito.

A formulação dele: affordances definem que ações são possíveis; significantes especificam como as pessoas descobrem essas possibilidades. E a consequência para quem projeta: no design, significantes são mais importantes que affordances, porque são eles que comunicam como usar. Na maior parte do tempo, o projetista pode se concentrar nos significantes.

O exemplo que fecha a discussão, num diálogo do próprio livro: desenhar um círculo indicando onde tocar na tela não é criar uma affordance — a affordance de tocar existe na tela inteira, e o círculo não acrescenta nada de novo. Ele sinaliza o que fazer e onde fazer. Chame pelo nome certo: significante.

Um cuidado: affordances percebidas podem ser falsas. Algo pode parecer uma porta ou um lugar de empurrar sem ser. Norman chama esses de significantes enganosos — às vezes acidentais, às vezes propositais, como uma fileira de tubos de borracha atravessando uma estrada de serviço, que bloqueia carros aos olhos de quem passa mas deixa passar quem sabe que são de borracha.

A regra de bolso para avaliar o seu protótipo:

Toda vez que você vê um aviso escrito à mão colado numa porta, num interruptor ou num produto, explicando como usar aquilo, você está olhando para design ruim. A versão de tela é o balão de ajuda que a equipe acrescentou porque “ninguém entendia” — o pedido de socorro do significante que está faltando.

8. Feedback: três exigências e duas advertências

Norman observa que, dada a importância do feedback, é espantoso quantos produtos o ignoram.

As três exigências:

1. Imediato. Mesmo um atraso de um décimo de segundo já desconcerta. Se o atraso é longo demais, as pessoas frequentemente desistem e vão fazer outra coisa — o que é irritante para elas e desperdício de recurso para o sistema, que gasta tempo e esforço atendendo uma requisição cujo destinatário já não está mais lá.
2. Informativo. Empresas economizam usando luzes baratas e geradores de som simples. Esses flashes e bipes costumam ser mais irritantes que úteis: dizem que algo aconteceu, transmitem pouquíssima informação sobre o que aconteceu, e nada sobre o que fazer a respeito. Com som, muitas vezes não dá nem para saber qual aparelho emitiu; com luz, você perde se não estava olhando para o lugar certo na hora certa.
3. Priorizado. Todas as ações precisam de confirmação, mas de modo discreto. Informação sem importância deve ser apresentada de forma discreta; sinais importantes, de forma que capture atenção. Quando tudo sinaliza emergência, nada é ganho com a cacofonia resultante.

As duas advertências:

• Feedback ruim pode ser pior que nenhum feedback, porque distrai, não informa e, em muitos casos, irrita e provoca ansiedade.
• Feedback demais incomoda mais que de menos. Norman dá o exemplo doméstico da lava-louças que apita às três da manhã para avisar que terminou, derrotando o objetivo de rodar de madrugada sem incomodar ninguém. E o risco maior: excesso de avisos faz as pessoas ignorarem todos, ou desligarem todos — e então os importantes se perdem.

Ação para a Q8: liste as ações principais do seu protótipo numa tabela de três colunas — ação · o que o sistema responde · em quanto tempo. Toda linha em que a segunda coluna esteja vazia é um problema de Golfo da Avaliação esperando aparecer no teste. Toda linha em que a resposta seja genérica (“Pronto!”, “Erro”) é feedback não informativo.

Fontes

• Norman, Donald, O design do dia a dia (The Design of Everyday Things, edição revista) — cap. 1: affordances, significantes, a correção do autor ao próprio termo, significantes enganosos, a regra do aviso escrito à mão; cap. 2: os dois golfos, as sete fases da ação, feedforward e feedback, os sete princípios de projeto; cap. 1: as três exigências do feedback e as duas advertências; cap. 5: a classificação de erros, todos os subtipos de deslize e de engano, as curas de cada um, a dificuldade de detecção, interrupções e listas de verificação
• Reason, James — coautor, com Norman, da classificação em deslizes e enganos, conforme o próprio Norman registra nas notas
• Rasmussen, Jens (1983) — a distinção entre comportamento baseado em habilidade, em regra e em conhecimento, da qual vem a classificação de enganos; Norman a indica como uma das melhores introduções ao tema

Protótipos

Abra este arquivo antes de construir, quando a equipe está decidindo o que fazer para levar ao teste — e de novo antes de trazer usuários, para limpar o básico por conta própria. Ele responde a três perguntas: qual fidelidade construir, como simular o que ainda não existe, e o que a equipe consegue descobrir sozinha sem gastar a sessão de um participante.

Modo de IA: coprodução ao construir o protótipo — gerar telas, variações, dados de exemplo. com apoio na avaliação heurística e no percurso cognitivo: a IA aponta violações e faz perguntas, e a equipe decide o que é problema.

1. Escolha a fidelidade pelo que você quer descobrir

Protótipo é a representação tangível de artefatos em vários níveis de resolução, para desenvolver e testar ideias dentro da equipe, com clientes e com usuários. Hanington & Martin definem protótipos pelo nível de fidelidade, ou grau de acabamento resolvido, e tratam baixa e alta fidelidade como as duas pontas de um contínuo — com muitas variações no meio.

Um princípio que atravessa a tabela. Brown registra o caso de um executivo da Steelcase que, tomando um modelo em espuma bem detalhado pelo objeto real, destruiu ao sentar-se um protótipo de 40 mil dólares da cadeira Vecta. A conclusão dele: toda a tecnologia do mundo não serve de nada se for usada para criar protótipos refinados demais, detalhados demais e cedo demais. “Prototipagem apenas o suficiente” significa escolher sobre o que você quer aprender e alcançar resolução suficiente só para aquilo. Quem tem experiência sabe a hora de dizer “já basta”.

⚠️ Correção específica da era da IA. A facilidade de gerar alta fidelidade em minutos não é razão para pular a baixa. O motivo não é ideológico: é que protótipo bonito muda o comportamento do participante e o da própria equipe. Ninguém tem medo de dizer que um rabisco está errado; quase todo mundo hesita em dizer que uma tela acabada está errada. E, do lado da equipe, apego a um artefato caro é o que produz aquele item de debriefing que ninguém quer priorizar. Se a IA gerou alta fidelidade em dez minutos, isso é argumento a favor de jogar fora e refazer, não a favor de defender o que está lá.

Prototipar o que não se pega. As mesmas regras valem para serviço, experiência virtual ou sistema organizacional. Brown: qualquer coisa tangível que permita explorar uma ideia, avaliá-la e empurrá-la adiante é um protótipo. Ele cita dispositivos sofisticados de injeção de insulina que começaram como Lego, interfaces de software esboçadas com notas adesivas antes de existir uma linha de código, e conceitos de agência bancária encenados diante do cliente contra um cenário de papelão preso com fita.

Prototipagem paralela

Vale citar quando a equipe está travada entre duas direções. Consiste em considerar várias ideias simultaneamente antes de escolher e refinar uma. Aplicada antes do design iterativo, evita que a equipe fixe cedo demais numa direção e suba morro acima rumo a um resultado inferior — crítica antiga ao design puramente iterativo.

O procedimento: cada pessoa cria, rápido e de forma independente, protótipos de baixa fidelidade; depois todos vão a teste com usuários ou a avaliação heurística. Hanington & Martin fazem uma ressalva que muda o uso: a intenção não é escolher o “melhor” ou o “preferido”. É levar a equipe a refletir sobre como as pessoas reagem a elementos individuais de cada design e quais deles cumprem os objetivos do projeto — para depois refinar e fundir as melhores qualidades num design otimizado.

O efeito colateral interessa a equipes de disciplina: quando vários designs são considerados lado a lado, fica mais difícil o autor se sentir na defensiva sobre um deles. Isso desloca a crítica da pessoa para o design e reduz a competição interna.

Ação: escreva numa frase o que a rodada de teste precisa descobrir. Se a frase contém “se entendem o que é”, construa papel. Se contém “se conseguem completar”, construa navegável. Se contém “se confiam”, só aí alta fidelidade.

2. Mágico de Oz

Serve quando o back-end não existe — e é a técnica central para produtos com IA numa disciplina de um semestre.

O que é: os participantes são levados a acreditar que estão interagindo com um protótipo funcional, mas na verdade um pesquisador atua como procurador do sistema, nos bastidores. Sem ser visto, ele intercepta e molda a interação, sem que exista sistema nenhum rodando. O objetivo é permitir que a pessoa experimente o produto proposto antes de protótipos caros serem construídos.

O nome vem do filme de 1939 em que um homem comum se esconde atrás de uma cortina e usa tecnologia para convencer todos de que é um mago onipotente. O paradigma foi cunhado por John F. Kelly, do centro de pesquisa da IBM, em 1980.

A montagem: participante numa sala, mago em outra. O mago precisa observar a atividade do participante — por vídeo ou compartilhamento de tela — para conseguir preparar uma resposta apropriada e no tempo certo.

Os três papéis que o mago pode assumir:

A condição de validade, e é uma só: a credibilidade das simulações depende do comportamento consistente do mago quanto a tempo, padrões e lógica do sistema. Um mago que responde em 2 segundos numa tarefa e em 20 na seguinte, ou que aplica um critério diferente do que aplicou antes, invalida a sessão — o participante está reagindo à inconsistência, não ao produto.

A trajetória ao longo do projeto: nas fases iniciais, o mago simula a maior parte dos comportamentos do sistema. À medida que a interface é melhorada de forma iterativa, cada vez menos intervenção é necessária — só o suficiente para manter o processo andando e cobrir a distância entre o que já está implementado e o sistema imaginado.

Quando usar: sempre que for preciso avaliar como as pessoas vão se sentir com uma solução proposta, e como se sairiam usando-a, antes de investir tempo e dinheiro num protótipo de verdade. É especialmente útil em aplicações digitais que ainda não têm padrões de design estabelecidos. Serve tanto nas fases exploratórias e conceituais quanto nas finais.

Ação: se o seu produto depende de um modelo, escreva antes da sessão as regras que o mago vai seguir — tempo de resposta, formato da resposta, o que fazer diante de entrada fora do previsto. Ensaie uma vez com alguém da equipe. Declare na entrega que a rodada foi Mágico de Oz: declarar é mais forte que disfarçar.

3. Avaliação heurística

É método de inspeção informal de usabilidade: avaliadores checam a interface contra um conjunto acordado de boas práticas — “regras de bolso” de usabilidade. É reconhecidamente um dos métodos de usabilidade de baixo custo de Jakob Nielsen, e o benefício é duplo: os usuários ganham um produto mais usável, e a organização gasta menos e ocupa menos gente.

Quem faz: ao contrário do teste, que exige usuários reais, a avaliação heurística convoca membros da própria equipe — do programador iniciante ao profissional experiente de usabilidade — para inspecionar a interface e detectar os problemas de base que devem ser corrigidos antes de o teste com usuários começar.

O procedimento que define a qualidade do resultado: avaliadores duplamente especialistas — que conhecem o domínio e usabilidade — tendem a ser os que mais identificam problemas, mas o método foi projetado para ser usado tanto por especialistas quanto por novatos treinados nas heurísticas. Para conter o viés que qualquer avaliador traz consigo, por causa da mentalidade ou da experiência dele, recomenda-se que três a cinco avaliadores façam a avaliação de forma independente primeiro, e só depois agreguem os achados num relatório único.

A independência antes da agregação é o método. Sem ela, você tem uma reunião de opinião.

O que esperar, e o que não esperar. O método raramente vai revelar oportunidades de ruptura no design. O que ele faz bem é detectar elementos de diálogo críticos que estão faltando, cedo no processo. Pode ser usado a partir do meio do processo — ou mesmo assim que existam protótipos de baixa fidelidade.

Como escrever o relatório: liste quais problemas são inconsistentes com quais heurísticas, com bastante captura de tela e marcação. E inclua também exemplos do que está funcionando bem. Reportar os dois lados dá equilíbrio ao documento, reconhece o trabalho já feito e serve de motivação para continuar avaliando — o que importa numa equipe de disciplina, em que a rodada seguinte depende de as pessoas quererem participar.

Um efeito de segunda ordem que vale para a Q8: conforme a equipe assiste a mais testes com usuários, ela tende a ficar melhor em detectar problemas nas avaliações heurísticas. Os dois métodos se alimentam.

4. Percurso cognitivo

Avalia se a ordem das pistas e dos comandos num sistema reflete o modo como as pessoas processam a tarefa cognitivamente e antecipam o “próximo passo”. É método de inspeção, criado no início dos anos 1990 por Peter Polson, Clayton Lewis, John Rieman e Cathleen Wharton, no Instituto de Ciência Cognitiva da Universidade do Colorado, apoiado numa teoria de aprendizagem exploratória.

Onde ele se aplica melhor: situações em que instrução prévia, orientação ou treinamento não vão acontecer — em que a pessoa precisa se engajar ativamente com a interface para saber o que fazer em seguida, em vez de recorrer a conhecimento prévio do sistema. Ele é particularmente adequado a sistemas de “chegar e usar”: caixas eletrônicos, máquinas de estacionamento e de bilhete de metrô, atendimento telefônico automatizado.

A montagem: escolha uma série de tarefas representativas, todas escritas do ponto de vista do usuário, e descreva cada uma como uma sequência crível de passos de ação. O método então critica cada passo e avalia se ele é o passo certo no momento certo. Cada passo é julgado como algo que aproxima ou afasta a pessoa do objetivo dela.

As quatro perguntas, feitas para cada passo da sequência:

1. O usuário vai querer produzir o efeito que essa ação produz?
2. O usuário vai ver o controle — botão, menu, rótulo — para essa ação?
3. Uma vez que o encontre, ele vai reconhecer que aquele controle produz o efeito que ele quer?
4. Depois de executada a ação, o usuário vai entender o feedback que recebeu, de modo a seguir com confiança para a ação seguinte?

Ao avaliar cada passo com essas quatro perguntas, a equipe consegue decidir qual sequência cria menos obstáculos para o usuário.

A relação com as sete fases de Norman é direta, e vale explicitar na apresentação: a pergunta 1 é a fase de objetivo; a 2 e a 3, o Golfo da Execução; a 4, o Golfo da Avaliação. Ver diagnostico-de-erro.md.

5. Por que inspeção não substitui usuário

Hanington & Martin dão os dois argumentos, e eles não se anulam:

• A favor da inspeção: não se pode supor que haverá usuários disponíveis para testar cada passo do processo iterativo. Revisões por especialistas, como o percurso cognitivo, garantem melhor uso do tempo dos participantes — quando eles chegam, os problemas óbvios já foram removidos.
• A favor de usar os dois: percursos cognitivos e testes de usabilidade tendem a revelar classes diferentes de problema de design e de usabilidade. Usá-los juntos, em vez de um no lugar do outro, é sempre recomendado.

Há ainda o argumento de Krug, do outro lado: você é a pior pessoa para avaliar a usabilidade do que construiu. Inspeção feita pela equipe está sujeita a isso; é justamente por isso que ela vem antes e não no lugar.

Ação para a Q8: faça a inspeção uma semana antes do teste, com três pessoas da equipe avaliando separado. Conserte o que couber. Leve ao usuário a versão limpa. Registre as duas listas na entrega — as violações que vocês acharam sozinhos e os problemas que só apareceram com gente de fora. A diferença entre as duas listas é uma das evidências mais fortes que a Q8 pode apresentar.

6. Microinterações com propósito

Vale a seção porque toda equipe, na Q8, gasta tempo em animação, e porque animação mal calibrada aparece no teste como problema de Golfo da Avaliação.

O critério de aceitação, e é um só:

Nenhuma animação de interface deveria chegar ao produto final sem que se saiba qual é o propósito dela.

Val Head propõe o exercício operacional: desafie-se a articular um propósito para cada animação, para avaliar quão úteis elas são. O propósito pode ser tático — dar feedback — ou de marca — expressar personalidade. Se não há propósito definível, considere eliminar ou redesenhar a animação para que ela tenha um propósito e um objetivo sólidos.

As três regras que evitam que a animação vire problema no teste:

Uma quarta, quando a animação existe para orientar: a direção do movimento pode guiar o olho pela hierarquia do conteúdo. Head descreve o padrão do Pinterest, em que a miniatura desliza para dentro do modal a partir da posição que ocupava na grade, e volta ao mesmo lugar ao fechar — o que ajuda a pessoa a não perder de vista com qual item ela está interagindo. E o encadeamento: quando a segunda animação começa exatamente onde a primeira terminou, fica mais fácil acompanhar o fluxo de informação.

Como usar isso no debriefing: microinteração é o item típico da lista separada de fruta baixa (ver teste-de-usabilidade.md). Ela raramente é o problema mais grave; ela quase sempre é uma correção de menos de uma hora. Não deixe competir com o que é grave.

Fontes

• Hanington, Bruce & Martin, Bella, Universal Methods of Design — método 13 (Cognitive Walkthrough): origem, aplicação e as quatro perguntas por passo; método 36 (Experience Prototyping): encenação e protótipos de experiência; método 46 (Heuristic Evaluation): quem avalia, os três a cinco avaliadores independentes, o que o método acha e o que não acha, como escrever o relatório; método 58 (Parallel Prototyping): o procedimento e os efeitos sobre a equipe; método 66 (Prototyping): fidelidades, protótipo de papel, o contínuo; método 99 (Wizard of Oz): origem, montagem, os três papéis do mago, a condição de consistência
• Krug, Steve, Não me faça pensar — o argumento de que quem constrói é a pior pessoa para avaliar
• Brown, Tim, Change by Design — “prototipagem apenas o suficiente”, o caso da cadeira Vecta, prototipar o que não se pega
• Head, Val, Designing Interface Animation — cap. 3: animação bloqueante e não bloqueante, a faixa de 200–500 ms, o alerta contra a duração única; cap. 5: a direção do movimento e o pareamento entre volume da animação e tamanho da tarefa; cap. 9 e 10: a auditoria de movimento, articular o propósito de cada animação e a regra de não levar ao produto animação sem propósito conhecido
• Nielsen, Jakob — autor das heurísticas e do conjunto de métodos de usabilidade de baixo custo, conforme atribuído por Hanington & Martin
• Kelly, John F. (IBM, 1980) — o paradigma “Oz”, conforme registrado por Hanington & Martin
• Polson, Lewis, Rieman & Wharton (Universidade do Colorado, início dos anos 1990) — o percurso cognitivo

Teste de usabilidade

Abra este arquivo na semana em que a equipe vai testar: quando já existe algo a mostrar e ainda falta decidir quem chamar, o que dizer e o que fazer com o que aparecer. Ele cobre a sessão inteira, do recrutamento à decisão do que consertar.

O modo de IA aqui é sem assistência durante a sessão. A IA pode ajudar antes (montar o roteiro, revisar o texto das tarefas) e depois (organizar as notas do debriefing). Ela não facilita, não observa e não interpreta no lugar de quem esteve na sala.

1. O que você está montando, e o que ele custa

O teste que a Q8 pede é o teste feito pela própria equipe — a versão barata, mensal, sem laboratório. Vale saber de onde ela vem, porque a diferença explica por que três participantes bastam.

Krug registra a genealogia: até 1989 um teste custava de 20 a 50 mil dólares e exigia laboratório com espelho falso. O artigo de Jakob Nielsen Usability Engineering at a Discount derrubou isso para 5 a 10 mil. A versão que você vai fazer custa algumas centenas de reais ou menos por rodada.

⚠️ Sobre a palavra “participante”. Krug é explícito: chamamos de participante, e não de “sujeito de teste”, para deixar claro que não estamos testando a pessoa — estamos testando o produto. Não é preciosismo de vocabulário: a palavra que você usa entre a equipe vaza para a fala do facilitador, e o participante percebe.

Infraestrutura mínima: uma sala silenciosa em que ninguém interrompa (uma sala de aula vazia serve), mesa, duas cadeiras, um computador com internet, mouse, teclado e microfone. Uma segunda sala para os observadores, com projetor ou monitor grande e som. Software de compartilhamento de tela para transmitir, e software de gravação de tela para registrar o que aconteceu e o que foi dito. Você pode nunca reassistir; é bom ter para conferir um detalhe ou recortar 30 segundos para a apresentação.

A cadência: dia fixo do calendário — a terceira quinta-feira, por exemplo —, não a uma etapa do cronograma. Cronograma escorrega, e teste amarrado a cronograma escorrega junto. Sempre haverá alguma coisa para testar.

Ação: antes de recrutar, reserve a sala e marque a data no calendário compartilhado da equipe. Data primeiro, participante depois — a ordem inversa é a que faz o teste não acontecer.

2. Recrutar solto e corrigir na leitura

Equipes gastam tempo demais atrás do perfil exato — “homens contadores de 25 a 30 anos com um a três anos de experiência com computador”. Recrutar exatamente do público-alvo não é tão importante quanto parece: se você está começando a testar, o produto provavelmente tem falhas que travam quase qualquer pessoa.

A regra de Krug é curta: recrute solto, e corrija na hora de interpretar.

Na prática: procure pessoas que reflitam o seu público, mas não trave nisso. Afrouxe os requisitos e faça a compensação depois. Quando alguém tiver um problema, a pergunta é “os nossos usuários teriam esse problema, ou foi problema só porque essa pessoa não sabe o que eles sabem?”

Quando você precisa de conhecimento de domínio — um sistema para técnicos de laboratório, um app para agentes de saúde —, você precisa de alguns participantes com esse conhecimento. Não de todos.

E há um argumento a favor de sempre incluir alguém de fora do público-alvo:

1. Projetar de modo que só o público-alvo consiga usar costuma ser má ideia. Se você escreve para gestores financeiros usando o jargão que acha que todo gestor financeiro entende, vai descobrir que uma parcela pequena mas não desprezível deles não entende. E na maioria dos casos você precisa atender novatos além de especialistas.
2. Somos todos iniciantes por baixo da pele. Arranhe um especialista e você acha alguém se virando — só que num nível mais alto.
3. Especialistas raramente se ofendem com algo que está claro o bastante para iniciantes. Todo mundo aprecia clareza — clareza de verdade, não simplificação.

Onde achar participantes

Krug lista: grupos de usuários, feiras e eventos do setor, classificados online, redes sociais, fóruns de clientes, um convite na própria página do produto, e até amigos e vizinhos. Traduzindo para o CIn:

Incentivo. Krug relata a faixa praticada no mercado americano: de 50 a 100 dólares por sessão de uma hora para usuários médios, e várias centenas para profissionais caros e ocupados. Ele recomenda pagar um pouco acima da praxe, porque deixa claro que você valoriza o tempo da pessoa e aumenta a chance de ela aparecer — e lembra que, mesmo numa sessão de uma hora, a pessoa normalmente gasta outra hora se deslocando. Num projeto de disciplina não há orçamento equivalente; o que existe é o reconhecimento do custo real. Ofereça o que for possível e digno (lanche, vale-transporte, crédito na entrega, acesso antecipado) e combine antes, não na hora.

Ação: monte uma lista de dez nomes ou grupos concretos com forma de contato. Chame seis para conseguir três.

3. O roteiro, minuto a minuto

Uma hora, dividida assim:

Krug recomenda ler as falas exatamente como escritas, porque a redação foi escolhida com cuidado. O que segue é a tradução das falas do roteiro dele para o português; adapte os nomes, não a estrutura.

Abertura

• “Oi, [nome]. Meu nome é [seu nome], e eu vou te acompanhar nesta sessão. Antes de começar, tenho algumas informações para você, e vou ler para ter certeza de que não esqueço nada.”
• “Você provavelmente já tem uma ideia de por que a gente te chamou aqui hoje, mas deixa eu repassar rapidinho. Estamos testando um produto em que estamos trabalhando, para ver como é usá-lo. A sessão deve levar cerca de uma hora.”
• “Quero deixar claro desde já que estamos testando o produto, não você. Você não pode fazer nada errado aqui. Na verdade, este é provavelmente o único lugar hoje em que você não precisa se preocupar em errar.”
• “A gente quer ouvir exatamente o que você pensa, então, por favor, não se preocupe em ferir os nossos sentimentos. A gente quer melhorar isto, então precisa saber honestamente o que você acha.”
• “Conforme a gente for andando, vou te pedir para pensar em voz alta, para me dizer o que está passando pela sua cabeça. Isso ajuda muito.”
• “Se você tiver perguntas, é só perguntar. Talvez eu não consiga responder na hora, porque a gente quer saber como as pessoas se viram quando não tem ninguém do lado para ajudar, mas eu vou tentar responder qualquer pergunta que ainda ficar no fim.”
• “E se você precisar de uma pausa em algum momento, é só falar.”
• “Você deve ter visto o microfone. Com a sua permissão, vamos gravar o que acontece na tela e o que você fala. A gravação vai ser usada só para nos ajudar a melhorar o produto, e não vai ser vista por ninguém além de quem trabalha no projeto. Também me ajuda, porque assim eu não preciso fazer tanta anotação.”
• “Também tem algumas pessoas da equipe acompanhando a sessão de outra sala. Elas não veem a gente, só a tela.”
• “Se você puder, vou te pedir para assinar um termo de autorização simples. Ele só diz que você nos autoriza a gravar, e que a gravação só será vista por quem trabalha no projeto.”
• “Você tem alguma pergunta antes de a gente começar?”

O ponto sobre as perguntas é o que mais se esquece. Krug explica por quê: é importante avisar antes que você não vai responder na hora, porque não responder pareceria grosseria. Você tem de deixar claro que (a) não é nada pessoal e (b) você tenta responder no fim, se a dúvida ainda existir.

Perguntas sobre a pessoa

Duas ou três, curtas: qual é a sua ocupação, o que você faz durante o dia; quantas horas por semana você passa na internet, mais ou menos; que tipo de site ou aplicativo você costuma usar. A precisão da resposta não importa. O objetivo é fazer a pessoa começar a falar, e mostrar que você vai escutar com atenção e que não há resposta certa ou errada.

Duas atitudes que Krug recomenda aqui: não hesite em admitir que você não conhece algo que a pessoa mencionou — seu papel não é parecer especialista, é ser bom ouvinte —, e não tenha medo de uma digressão curta, desde que você volte ao assunto logo.

Tour da tela inicial

“Primeiro, vou só pedir para você olhar para esta tela e me dizer o que você entende disto: o que te chama atenção, de quem você acha que é, o que dá para fazer aqui, para que serve. Só olhe e vá narrando um pouco. Você pode rolar a tela se quiser, mas não clique em nada ainda.”

Deixe o navegador aberto em algo neutro até esse momento; abra a tela do produto na hora e passe o mouse para a pessoa.

As tarefas

Escolha tarefas, não telas. “Encontre um grupo de corrida no seu bairro e entre nele” é tarefa. “Veja a tela de grupos” não é.

Escreva cada tarefa com cuidado, incluindo toda a informação que a pessoa vai precisar e não tem — login de conta de demonstração, por exemplo. E prefira tarefas em que a pessoa escolha parte dos detalhes: “encontre um livro que você queira comprar, ou um que você comprou recentemente” rende mais que “encontre um livro de culinária abaixo de R$ 40”, porque aumenta o investimento emocional e deixa a pessoa usar o conhecimento dela sobre o conteúdo.

Escolha tarefas suficientes para preencher os 35 minutos, lembrando que algumas pessoas terminam mais rápido do que você espera. Deixe cada tarefa correr até que (a) a pessoa termine, (b) ela fique realmente frustrada, ou (c) você pare de aprender algo novo observando.

O que dizer quando a pessoa silencia: “No que você está pensando?”. Para variar: “O que você está olhando?”, “O que você está fazendo agora?”.

O que dizer quando pedem ajuda: “O que você faria se eu não estivesse aqui?”.

Sondagem

É aqui, e só aqui, que entram as perguntas investigativas: sobre o que aconteceu, por que a pessoa ignorou determinado elemento, o que ela esperava que acontecesse. Inclua as perguntas que a sala de observação mandou. Guardar essas perguntas para o fim é justamente o que impede que elas enviesem as tarefas.

Fechamento

Agradeça, entregue o combinado, acompanhe até a porta.

4. O que o facilitador pode e não pode

Quem facilita. Quase qualquer pessoa consegue, e melhora com prática. Se você vai escolher outra pessoa, escolha alguém paciente, calmo, empático e bom ouvinte. Krug é direto sobre quem não escolher: quem você descreveria como “não é muito de gente” ou “o rabugento da sala”.

A função principal do facilitador, além de manter a pessoa confortável e concentrada nas tarefas, é encorajá-la a pensar em voz alta o máximo possível. É a combinação de ver o que ela faz com ouvir o que ela pensa enquanto faz que permite aos observadores enxergar o produto pelos olhos de outra pessoa.

A regra dura:

Não faça perguntas indutoras, e não dê nenhuma pista ou ajuda, a menos que a pessoa esteja irremediavelmente travada ou extremamente frustrada.

5. A sala de observação

Quantos observadores? Quantos couberem. Um dos efeitos mais valiosos do teste é sobre quem assiste: para muita gente é uma experiência que muda de forma dramática o modo de pensar sobre usuários — a pessoa de repente entende que os usuários não são todos como ela. Krug recomenda gastar o pouco dinheiro que houver em comprar comida boa para atrair gente para a sala.

Na Q8 isso tem uma consequência específica: quem escreveu o código precisa assistir. Ler o relatório não produz o mesmo efeito.

A regra que faz o debriefing funcionar: no intervalo depois de cada sessão, cada observador escreve os três problemas mais sérios que notou naquela sessão. Podem anotar o que quiserem além disso, mas a lista curta de três é obrigatória. Com três sessões, cada observador chega ao debriefing com nove problemas anotados e três para dizer em voz alta.

Além disso, a sala de observação manda perguntas para o facilitador fazer no bloco de sondagem. Combine o canal antes (um grupo de mensagens serve).

6. O debriefing, em quatro passos

Quando: logo depois, no mesmo dia, com tudo fresco. Krug faz no almoço.

Por que ele existe. Problemas sérios aparecem sempre — mas não são os que acabam consertados. Ou alguém diz “essa parte vai mudar mesmo, dá para conviver até lá”, ou, diante da escolha entre um problema grave e vários simples, a equipe escolhe os simples. É por isso que sites grandes e bem financiados continuam tendo problemas graves.

Foque implacavelmente em consertar primeiro os problemas mais sérios.

O método:

1. Lista coletiva. Cada pessoa diz os três problemas mais sérios que observou. Escreva tudo num quadro. Repetição vira um tique ao lado do item. Sem discussão nesta etapa — você está só listando. E só valem problemas observados: coisas que de fato aconteceram numa das sessões. Opinião sobre o design não entra.
2. Escolher os dez mais sérios. Pode haver votação informal, mas normalmente basta começar pelos que receberam mais tiques.
3. Ordenar de 1 a 10, sendo 1 o pior. Copie para uma lista nova, com o pior no topo e espaço entre os itens.
4. Lista acionável. Do topo para baixo, escreva para cada um: uma ideia grosseira de como consertar no próximo mês, quem faz, e que recursos exige.

As regras de parada

São duas, e as duas são contraintuitivas:

• Você não precisa consertar cada problema perfeitamente nem completamente. Basta fazer algo — muitas vezes um ajuste pequeno — que tire aquilo da categoria de “problema sério”.
• Quando você tiver alocado todo o tempo e os recursos disponíveis no próximo mês, PARE. Você já conseguiu o que veio buscar: o grupo decidiu o que precisa ser consertado e se comprometeu a consertar.

Numa disciplina de um semestre, a segunda regra é a que mais importa, porque a Q9 já está chegando e o cronograma dela precisa caber no que sobrou.

7. As quatro armadilhas do debriefing

8. Os três tipos de problema mais frequentes

Krug lista os que aparecem com mais regularidade. Use como grade de codificação ao escrever o resultado — ela dá o vocabulário que falta quando a equipe só sabe dizer “acharam confuso”.

9. Duas coisas que este teste não mede

Não mede desejo. Krug é explícito: ele fica desconfortável quando ouvem falar em usar teste de usabilidade para determinar se algo é desejável, porque não é isso que esse teste mede. Você pode ter uma sensação, durante a sessão, de que a pessoa achou aquilo desejável — mas é só isso, uma sensação. Desejabilidade é pergunta de pesquisa de mercado, respondida com instrumentos de pesquisa de mercado.

⚠️ Isso tem efeito direto na entrega da Q8. A pergunta 1 da quest — “as pessoas se mostraram motivadas a usar o protótipo?” — não é respondida pelo teste de usabilidade. Responda-a com o que você tem de outra natureza: quantas pessoas pediram para continuar usando, quantas aceitaram entrar na base de testes da Q9, quantas indicaram outra pessoa. Declarar que a evidência de motivação vem de outra fonte é mais forte que fingir que o teste mediu isso.

Não prova nada. É método qualitativo: você dá tarefas, observa e aprende. O resultado são insights acionáveis, não prova. Provar exigiria teste quantitativo, amostra grande, protocolo rígido e análise. Se a banca ou o mentor perguntar “três pessoas provam alguma coisa?”, a resposta correta não é defender a amostra — é dizer que a rodada não pretendia provar, e mostrar o que mudou no produto por causa dela.

Fontes

• Krug, Steve, Não me faça pensar (Don't Make Me Think, Revisited), cap. 9 — todo o método: a tabela tradicional × faça-você-mesmo, a cadência mensal, os três participantes, “recrute solto e corrija na leitura”, onde achar e quanto pagar, a infraestrutura, o roteiro minuto a minuto e as falas, os três tipos de problema, o debriefing em quatro passos, as regras de parada, as quatro armadilhas; cap. 13 — o que o teste não mede
• Krug, Steve, Rocket Surgery Made Easy — livro dedicado ao procedimento, citado por ele como a versão detalhada do capítulo 9; é de lá que vem a máxima sobre consertar primeiro o mais sério
• Nielsen, Jakob, “Usability Engineering at a Discount”, 1989 — a origem do teste barato, referida por Krug
• Hanington & Martin, Universal Methods of Design, método 87 (Think-aloud Protocol) — as duas variantes do pensar em voz alta e o alerta de focar no o quê e não no porquê durante a tarefa

Autodiagnóstico

Faça este exercício antes de entregar. Ele é o mesmo que o mentor vai fazer depois.

A escala

O milestone da Q8 é Testes de usabilidade. Use a escala 0–5 da disciplina:

O salto que trava a maioria na Q8 é o 2 → 3, e ele quase nunca é sobre o protótipo: é sobre ter observado em vez de ter apresentado. Equipe que fez demonstração comentada com três amigos não passa de 2, por melhor que seja a tela.

Rubrica por dimensão

1. Condução do teste

2. Participantes

3. Achados

4. Decisão do que mudar

5. Honestidade metodológica

Checklist rápido

• Dei tarefas, não telas — e consigo nomear a tarefa em que a maior dificuldade apareceu?
• Todos os problemas da minha lista aconteceram numa sessão, ou algum é opinião da equipe?
• Alguém pediu ajuda e eu respondi “o que você faria se eu não estivesse aqui?”, ou eu ajudei?
• Guardei as perguntas para a sondagem, ou perguntei durante a tarefa?
• Sei distinguir, na minha lista, o que foi deslize e o que foi engano?
• Se só há deslizes na lista, eu de fato sondei — ou não houve como detectar engano?
• Ignorei os problemas de caiaque, e separei a fruta baixa para não competir com o que é grave?
• Cada item da lista tem dono e prazo, ou é uma lista de desejos?
• Declarei o que não vamos consertar?
• O protótipo era da fidelidade certa para o que eu queria descobrir?
• Se usei Mágico de Oz, declarei — e o mago se comportou de forma consistente?

Sinal de alerta: se a entrega tem mais imagem de tela do que descrição de comportamento observado, a equipe entregou o protótipo, não o aprendizado. A quest pede o segundo.

Segundo sinal: se nenhuma decisão de produto mudou por causa do teste, ou o produto já estava perfeito — improvável — ou o teste foi apresentação.

Registro de trajetória (modo de IA)

Meia página, entregue junto. Ver metodo/modo-ia.md para o racional.

1. Modo em que a quest foi feita, e onde você saiu dele. Na Q8 há dois modos distintos: coprodução ao construir o protótipo, sem assistência durante a sessão com o participante. Se a IA participou da condução ou da interpretação do que o participante fez, isso precisa estar declarado.

2. O que a IA gerou e você descartou — e por quê. Típico da Q8: a IA gera uma lista de “problemas de usabilidade prováveis” a partir das telas. Ela pode servir de insumo para a avaliação heurística, e não pode entrar na lista de achados do teste. Achado de teste é o que aconteceu com alguém.

3. O que você verificou, e como. Típico da Q8: a classificação dos erros. Diga qual episódio você reclassificou depois de olhar a gravação.

4. O que ainda não sabe.

Como o mentor vai ler

Quatro perguntas que aparecem com regularidade na apresentação da Q8. Se você tem resposta para as quatro, está em 4:

1. “Em qual tarefa o usuário teve mais dificuldade?” É a pergunta 5 da entrega, e ela pede o nome de uma tarefa. “Acharam um pouco confuso” não é resposta.
2. “O que exatamente aconteceu na tela quando ele travou?” Se a resposta é vaga, a equipe assistiu sem registrar. Se é precisa, ela observou.
3. “Vocês ajudaram?” “Só um pouquinho, quando ele ficou perdido” é responder que a sessão foi contaminada. Melhor ter ajudado e declarado do que ter ajudado e omitido.
4. “O que vocês vão consertar até a Q9, e o que não vão?” A segunda metade da pergunta é a que separa 3 de 4.

Divergência entre a sua auto-avaliação e a leitura do mentor é informação útil, não constrangimento.