# Instruções para a IA Você vai acompanhar um aluno do Projetão (CIn-UFPE) na quest abaixo. Este arquivo é autocontido: tudo o que você precisa está aqui. **Antes de produzir qualquer coisa:** pergunte o que a equipe já tem das quests anteriores, e declare em voz alta o modo de IA desta quest. **A regra que atravessa a disciplina:** não projetamos para nós mesmos, projetamos para os outros. Toda afirmação sobre o usuário precisa de evidência de campo. Quando o aluno disser "as pessoas querem X", pergunte quantas ele ouviu, quando, e o que disseram literalmente. Se for suposição, diga isso — não ajude a fabricar justificativa bonita. **Você não escreve a entrega no lugar do aluno.** Ele defende o resultado numa apresentação semanal. Você pergunta, critica, organiza e devolve. **Você não inventa dado de mercado, número de entrevista nem citação.** Se falta evidência, o certo é dizer que falta. E você nunca escreve a fala de um entrevistado que não existiu, nem "completa" uma entrevista curta. --- # Quest #8 — Prototipação & Usabilidade > **Objetivo.** Apresentar testes de usabilidade com o protótipo de solução. | | | |---|---| | **Modo de IA** | 🟢 coprodução no protótipo · 🔴 sem assistência no teste com usuário | | **Milestone** | **Testes de usabilidade** | | **Entrega** | o que os testes revelaram e o que vai mudar por causa disso | | **Erro que mais custa** | apresentar o protótipo e anotar elogios | --- ## 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: | Etapa | Tempo | O que acontece | |---|---|---| | Boas-vindas | 4 min | Explica como funciona, para a pessoa saber o que esperar | | Perguntas | 2 min | Sobre o participante; deixa à vontade e revela familiaridade | | Tour da tela inicial | 3 min | "Olhe e me diga o que você entende disto" — **sem clicar** | | **As tarefas** | **35 min** | O coração: executa pensando em voz alta | | Sondagem | 5 min | Perguntas sobre o que aconteceu, inclusive as da sala de observação | | Fechamento | 5 min | Agradece, paga, acompanha até a porta | **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) | Subtipo | O que é | Como consertar | |---|---|---| | **Captura** | Uma sequência mais frequente "captura" a pretendida, porque as duas começam igual | Desenhe sequências que difiram **desde o início** | | **Semelhança de descrição** | Ação certa no objeto errado, porque a descrição interna do alvo era vaga | Diferencie visual e fisicamente controles de propósitos distintos | | **Lapso de memória** | Pula etapa, repete, esquece o resultado | Minimize passos; lembretes vívidos | | **Erro de modo** | O mesmo controle significa coisas diferentes em estados diferentes | Elimine modos, ou torne o modo óbvio. **Erro de modo é erro de design** | 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 | O que o participante disse ou fez | Fase travada | Golfo | O que consertar | |---|---|---|---| | "Não sei o que dá para fazer aqui" | planejar / especificar | Execução | Significantes, descoberta | | "Sei o que quero, mas não sei como" | executar | Execução | Mapeamento | | "Cliquei… aconteceu alguma coisa?" | perceber | Avaliação | Feedback imediato | | "Apareceu isso, não sei o que quer dizer" | interpretar | Avaliação | Feedback informativo, modelo conceitual | | "Acho que deu certo… deu?" | comparar | Avaliação | Confirmação explícita do estado | | Buscou o objetivo errado desde o início | objetivo | — | Modelo conceitual, vocabulário | ### 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 | Fidelidade | Boa para | Cuidado | |---|---|---| | **Papel** | fluxo, nomenclatura, entendimento do conceito | não testa desempenho nem prazer de uso | | **Encenação** | serviço, atendimento, processo com pessoas | exige ensaio | | **Wireframe navegável** | arquitetura de informação, navegação | gera discussão sobre estética que não interessa agora | | **Alta fidelidade** | percepção de valor, confiança, detalhe | caro; e protótipo bonito demais inibe crítica | **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 | | Inspeção (heurística, percurso cognitivo) | Teste com usuário | |---|---|---| | Quem | 3 a 5 avaliadores da equipe, **independentes** | Participantes reais, 3 por rodada | | Contra o quê | Um conjunto de heurísticas acordadas | Tarefas reais, comportamento observado | | Quando | **Antes** de trazer usuários — limpa o básico | Continuamente | | Acha | Violações de princípio | O que de fato confunde e frustra | 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 | Arquivo | Quando | |---|---| | **Teste de usabilidade — Quest #8** (neste arquivo) | Antes de testar. Roteiro completo, falas literais, recrutamento, o debriefing | | **Diagnóstico de erro — Quest #8** (neste arquivo) | Ao analisar. Deslize × engano, as sete fases, os golfos, feedback | | **Protótipos e inspeção — Quest #8** (neste arquivo) | Ao construir. Fidelidades, Mágico de Oz, microinterações | | **Autodiagnóstico — Quest #8** (neste arquivo) | Antes de entregar | --- ### Antes de registrar pessoas | Arquivo | Quando | |---|---| | `../../metodo/consentimento.md` | Antes do teste de usabilidade. Gravação de tela e voz, e o que não se publica | --- ### Técnicas desta quest Fichas curtas de consulta rápida. Abra quando o procedimento acima mencionar a técnica. | Ficha | Para quê | |---|---| | **Wireframe** (neste arquivo) | o que testar em cada fidelidade | | **Microinterações** (neste arquivo) | quando o usuário não percebe que algo aconteceu | | **Usuário afoito (*early adopter*)** (neste arquivo) | quem recrutar | | **Brainstorm** (neste arquivo) | gerar soluções para os problemas achados | --- ## 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 | Obra | O que ela dá para a Q8 | |---|---| | **Krug — Não me faça pensar** | O método de teste barato, o roteiro, o debriefing, a triagem | | **Norman — O design do dia a dia** | Deslize × engano, sete fases, golfos, significantes, feedback | | **Hanington & Martin — Universal Methods of Design** | Think-aloud, avaliação heurística, percurso cognitivo, Mágico de Oz | | **Head — Designing Interface Animation** | Microinterações com propósito | | **Maurya — Running Lean** | A entrevista de MVP, derivada do método de teste acima | | **Bigão Silva** · **Sutherland** | Bibliografia oficial da quest no site | --- # Autodiagnóstico — Quest #8 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: | Nível | Significado | |---|---| | **0** | O critério ainda não aparece. | | **1** | Já aparece, mas sem clareza nem coerência. | | **2** | Falta clareza **ou** falta coerência. A resposta ainda está no terreno da insegurança. | | **3** | Coerente, mas ainda não totalmente claro. Resta uma parcela de incerteza. | | **4** | Claro e coerente com toda a proposta. Ainda cabe aperfeiçoar, mas a equipe responde com segurança. | | **5** | Perfeitamente alinhado ao conjunto. As respostas são sólidas. | 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** | Mostramos o protótipo e perguntamos o que acharam. Quem conduziu explicou as telas durante o uso. | | **3** | Demos tarefas e observamos, mas sem roteiro escrito; o facilitador ajudou algumas vezes. | | **4** | Roteiro escrito e lido; tarefas (não telas) com investimento da pessoa; pensar em voz alta estimulado; nenhuma pergunta indutora; perguntas guardadas para a sondagem. | | **5** | O acima, com observadores em sala separada, cada um registrando os três problemas mais sérios por sessão, e gravação de tela. | ### 2. Participantes | | | |---|---| | **2** | Colegas de turma, sem relação com o perfil, que já conheciam o projeto. | | **3** | Três pessoas do perfil aproximado, mas o quanto elas se afastam do público-alvo não foi declarado. | | **4** | Três participantes, perfil descrito com precisão, **com a compensação declarada** — o que foi problema de fato e o que foi problema por desconhecimento de domínio. | | **5** | O acima, com pelo menos um participante deliberadamente de fora do público-alvo, e com o motivo dessa escolha explicado. | ### 3. Achados | | | |---|---| | **2** | "Acharam confuso", "gostaram", "sugeriram melhorias". Nenhuma tarefa nomeada. | | **3** | Problemas listados por tela, misturando o que foi observado com o que foi opinado. | | **4** | Só problemas **observados**, cada um ligado à **tarefa específica** em que apareceu e ao participante que o teve; dez priorizados e ordenados de 1 a 10. | | **5** | O acima, com cada problema classificado (deslize ou engano; fase da ação travada; golfo) e a evidência de qual sondagem revelou o engano. | ### 4. Decisão do que mudar | | | |---|---| | **2** | Lista de melhorias futuras, sem dono e sem prazo. | | **3** | Correções descritas, mas sem responsável nem estimativa, e sem ordem de prioridade. | | **4** | Lista ordenada, do pior para o menos pior, com **como consertar, quem faz e que recursos exige** — e uma lista separada de fruta baixa. | | **5** | O acima, com o ponto de parada declarado: o que **não** vai ser consertado nesta rodada e por quê. | ### 5. Honestidade metodológica | | | |---|---| | **2** | O relato sugere que o teste provou que a solução funciona. | | **3** | Limitações citadas de forma genérica ("amostra pequena"). | | **4** | A equipe declara que a rodada é qualitativa e não prova nada; declara o que o teste **não** mede (desejo, motivação) e de onde veio a evidência disso. | | **5** | O acima, com o registro do que a equipe **esperava** que acontecesse, escrito antes do teste, comparado ao que aconteceu. | --- ## 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. --- # Diagnóstico de erro — Quest #8 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: | | Deslize | Engano | |---|---|---| | Origem | Ação subconsciente que se desviou no caminho | Deliberação consciente que partiu errado | | Quem comete mais | **Especialistas**, porque automatizam e não prestam atenção consciente | Quem está diante de situação nova ou mal classificada | | Aparece sozinho no teste? | **Sim.** Você vê acontecer | **Não.** As ações seguintes são coerentes com o objetivo errado | | Como você descobre | Observando | **Só se a pessoa pensar em voz alta, ou se você perguntar na sondagem** | | O que consertar | O controle, o layout, a sequência | O modelo conceitual, o vocabulário, a informação de estado | 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**. | Subtipo | O que é | Como se manifesta | Direção da cura | |---|---|---|---| | **Baseado em regra** | A situação foi diagnosticada corretamente, mas o curso de ação escolhido é errado: a regra errada foi seguida | A pessoa faz algo coerente e confiante, e está errada desde o começo | Modelo conceitual explícito; deixar o estado do sistema visível para que a classificação errada apareça | | **Baseado em conhecimento** | A situação é **mal diagnosticada**, por conhecimento errado ou incompleto; não há habilidade nem regra que se aplique | Situação nova, a pessoa raciocina em voz alta, testa hipóteses, se perde | Modelo conceitual é essencial aqui — é ele que guia o desenvolvimento do plano e a interpretação da situação | | **Lapso de memória** | Esquecimento nas fases de objetivo, plano ou avaliação | A pessoa abandona a tarefa e não retoma; ou não avalia se deu certo | **Mesma cura do lapso de memória em deslizes:** garantir que toda a informação relevante permaneça continuamente disponível. Objetivos, planos e avaliação corrente do sistema são os itens mais importantes, e são justamente os que muitos designs apagam assim que a ação é executada | **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. | # | Fase | A pergunta que a pessoa se faz | |---|---|---| | 1 | **Objetivo** (formar o objetivo) | O que eu quero realizar? | | 2 | **Planejar** (a ação) | Quais são as sequências de ação alternativas? | | 3 | **Especificar** (a sequência de ações) | Que ação eu posso fazer agora? | | 4 | **Executar** (a sequência) | Como eu faço isso? | | 5 | **Perceber** (o estado do mundo) | O que aconteceu? | | 6 | **Interpretar** (a percepção) | O que isso quer dizer? | | 7 | **Comparar** (resultado e objetivo) | Está tudo bem? Eu consegui o que queria? | 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. | Golfo | Atravessa-se com | |---|---| | **Execução** | Significantes, restrições, mapeamentos e modelo conceitual | | **Avaliação** | Feedback e modelo conceitual | 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. | O que o participante disse ou fez | Fase travada | Golfo | O que consertar | |---|---|---|---| | "Não sei o que dá para fazer aqui" · varre a tela sem clicar | Planejar / especificar | Execução | **Significantes** e descoberta: tornar visíveis as ações possíveis | | "Sei o que eu quero, mas não sei como fazer" · encontra o botão certo e não o reconhece como certo | Executar | Execução | **Mapeamento** entre controle e efeito; rótulo; proximidade espacial | | "Cliquei… aconteceu alguma coisa?" · clica de novo no mesmo lugar | Perceber | Avaliação | **Feedback imediato** — até um décimo de segundo de atraso desconcerta | | "Apareceu isso aqui, não sei o que quer dizer" | Interpretar | Avaliação | **Feedback informativo** e modelo conceitual: dizer o que aconteceu, não que algo aconteceu | | "Acho que deu certo… deu?" · sai da tela sem confirmar | Comparar | Avaliação | **Confirmação explícita do estado**; mostrar o novo estado depois da ação | | Perseguiu o objetivo errado desde o início, com ações coerentes entre si | Objetivo | — (engano) | **Modelo conceitual** e vocabulário: a primeira tela, os nomes das coisas | | Pulou uma etapa e não voltou; ou abandonou no meio depois de uma interrupção | Transição entre fases | — (lapso) | Menos passos; lembrete vívido; função de força | | Fez a coisa certa no objeto errado, entre controles parecidos | Executar | Execução | Diferenciar visual e fisicamente os controles (semelhança de descrição) | | Fez a sequência mais frequente em vez da pretendida | Executar | Execução | Fazer as sequências divergirem desde o primeiro passo (captura) | | Fez a ação certa com o produto no estado errado | Executar | Execução | Eliminar o modo, ou torná-lo óbvio (erro de modo) | **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 e inspeção — Quest #8 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. | Fidelidade | O que é | O que testa bem | O que não testa | Cuidado | |---|---|---|---|---| | **Baixa (esboço, storyboard, modelo de rascunho)** | Comum na ideação inicial em todas as disciplinas de design. Serve de ponto de checagem para o time | Conceito, fluxo, nomenclatura, entendimento | Desempenho, prazer de uso, estética | É "proposta para revisão construtiva", não produto — deixe isso explícito ao participante | | **Papel** | Páginas representando telas. A pessoa indica o que faria em cada página, e o pesquisador troca as páginas seguintes para simular a resposta da interface | Entendimento do conceito, nomes, sequência | Tempo de resposta, transições, sensação | Áreas de dificuldade podem ser anotadas **direto no papel**, com códigos | | **Encenação / protótipo de experiência** | Participação ativa numa experiência ao vivo, com adereços simples e representação de papéis, criando um cenário de uso realista | Serviço, atendimento, processo com pessoas, pontos de contato ao longo do tempo | Detalhe de interface | Barato, e viável quando a experiência real é arriscada ou logisticamente complicada; exige ensaio | | **Wireframe navegável** | Renderizações de tela com navegação | Arquitetura de informação, navegação | Percepção de valor | Gera discussão sobre estética que não interessa agora | | **Alta fidelidade** | Aparência de produto final em *look and feel*, às vezes com funcionalidade básica. Em software, implica protótipo interativo capaz de dar uma experiência real | Percepção de valor, confiança, detalhe de interação, estética | Conceito (a pessoa já não critica o essencial) | Caro; e protótipo bonito demais inibe crítica | **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:** | Papel | O que faz | |---|---| | **Controlador** | Simula a inteligência do sistema | | **Supervisor** | Corrige o rumo e sobrepõe decisões que o sistema ou o participante tomam | | **Moderador** | Simula dados sensoriais e faz a experiência imaginada parecer completa | **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 | | Inspeção (heurística, percurso cognitivo) | Teste com usuário | |---|---|---| | Quem | 3 a 5 avaliadores da equipe, trabalhando **independentemente** antes de agregar | Participantes reais, três por rodada | | Contra o quê | Um conjunto de heurísticas acordadas, ou quatro perguntas por passo | Tarefas reais, comportamento observado | | Quando | **Antes** de trazer usuários — limpa o básico e torna o teste mais eficaz | Continuamente | | Acha | Violações de princípio; elementos de diálogo faltantes | O que de fato confunde e frustra | | Não acha | O que ninguém da equipe consegue deixar de saber | Violações de princípio que não apareceram nas tarefas testadas | 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:** | Regra | O que significa | Por quê | |---|---|---| | **Não bloqueante, por padrão** | A animação aceita e responde à entrada do usuário **em qualquer ponto** da sua execução. Animação interrompível é animação não bloqueante | Animação que ignora a entrada enquanto roda impede a pessoa de usar a interface para a tarefa pretendida, e faz o produto parecer quebrado ou lento. Head compara a uma conversa: se a outra pessoa não responde ao que você disse, você para de confiar nela | | **Duração entre 200 ms e 500 ms** | Transições pequenas, com poucos elementos ou pouca mudança, ficam na faixa de 200 a 350 ms. Movimentos maiores, que cobrem muito espaço ou usam transições complexas, sobem para 400 a 500 ms | Head alerta contra as duas simplificações opostas: nem "toda animação de interface tem de ser rapidíssima", nem uma duração única fixa aplicada a tudo. Bom timing é mais arte que ciência — pense em diretriz, não em regra fixa | | **O tamanho da animação combina com o tamanho da tarefa** | Movimento exagerado só onde a tarefa é importante | Head cita o botão de salvar do CodePen, que começa a pulsar depois de cerca de um minuto sem salvar. O exagero seria excessivo em outro contexto; ali, **o volume visual do movimento corresponde à importância da tarefa** | **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 — Quest #8 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. | | Teste tradicional | Teste da própria equipe | |---|---|---| | Tempo por rodada | 1–2 dias de teste, mais uma semana de relatório | **Uma manhã**: testar, almoçar, decidir | | Quando | Quando o site está quase pronto | Continuamente, durante todo o desenvolvimento | | Rodadas | Uma ou duas por projeto | **Uma por mês** | | Participantes | Oito ou mais | **Três** | | Recrutamento | Criterioso, perfil exato | **Solto, se necessário** | | Quem identifica os problemas | Quem conduziu o teste, num relatório | **A equipe inteira**, no almoço do mesmo dia | | Relatório | 25 a 50 páginas | E-mail de 1 a 2 páginas com as decisões | | Propósito | Achar o máximo de problemas e priorizá-los por severidade | **Achar os mais graves e se comprometer a consertá-los** antes da próxima rodada | 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: | Fonte | Serve para | Cuidado | |---|---|---| | O lugar onde você fez a observação da Q1 | O perfil mais próximo do real | Combine com quem te recebeu; não apareça sem avisar | | Grupos e comunidades do domínio (associações, coletivos, grupos de mensagem) | Usuários afoitos que já têm a dor | Peça a um administrador do grupo para apresentar | | Contatos de primeiro grau que se encaixam no perfil, e as indicações deles | Começar rápido | Registre o grau de proximidade na entrega | | Outros cursos do campus, funcionários, terceirizados | O "alguém de fora do público-alvo" | Não use como base inteira | | Serviços de teste remoto não moderado | Ver alguém pensando alto em uma hora | Você não interage; sem sondagem | **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: | Etapa | Tempo | O que acontece | |---|---|---| | Boas-vindas | 4 min | Explicar como funciona, para a pessoa saber o que esperar | | Perguntas sobre a pessoa | 2 min | Deixa à vontade e revela familiaridade com tecnologia | | Tour da tela inicial | 3 min | "Olhe e me diga o que você entende disto" — **sem clicar** | | **As tarefas** | **35 min** | O coração: executar pensando em voz alta | | Sondagem | 5 min | Perguntas sobre o que aconteceu, inclusive as da sala de observação | | Fechamento | 5 min | Agradecer, pagar/entregar o combinado, acompanhar até a porta | 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. | Pode | Não pode | |---|---| | Ler as falas do roteiro como escritas | Improvisar a abertura | | *"No que você está pensando?"* | *"Você não achou confuso aquele botão?"* (indutora) | | *"O que você faria se eu não estivesse aqui?"* | *"Tenta clicar no menu de cima."* | | Admitir que não conhece algo que a pessoa citou | Explicar o produto durante as tarefas | | Digredir um pouco nas perguntas iniciais | Digredir durante as tarefas | | Ficar em silêncio enquanto a pessoa se vira | Preencher o silêncio | 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 | Armadilha | O que acontece | O que fazer | |---|---|---| | **Fruta baixa competindo com o que é grave** | Coisas triviais entram na lista principal e consomem a cota do mês | Mantenha uma **lista separada** de coisas fáceis. "Fácil" = uma pessoa resolve em menos de uma hora, sem precisar de autorização de ninguém que não esteja no debriefing | | **O impulso de acrescentar** | O usuário não entendeu, e o reflexo da equipe é adicionar explicação, instrução, tooltip | Muitas vezes a solução certa é **tirar** o que está obscurecendo o sentido, em vez de acrescentar mais uma distração | | **Pedido de funcionalidade levado a sério demais** | "Eu gostaria mais se ele fizesse X" vira item de backlog | Peça, na sondagem, que a pessoa descreva como a funcionalidade funcionaria. Quase sempre ela mesma conclui: "mas agora que eu penso, eu provavelmente não usaria". **Participantes não são designers.** Quando a ideia é boa de verdade, você reconhece na hora — seu primeiro pensamento é "por que não pensamos nisso?" | | **Problema de caiaque** | A equipe registra desvios momentâneos como se fossem falhas graves | Ignore quando as três condições valem: a pessoa percebe rápido que saiu do caminho, se recupera sozinha, e não se abala. Se o **segundo palpite** dela sobre onde achar as coisas está sempre certo, está bom o bastante | --- ## 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". | Tipo | Sinal na sessão | Direção do conserto | |---|---|---| | **A pessoa não entende o conceito** | Olha a tela e não sabe o que fazer daquilo, ou acha que sabe e está errada | Modelo conceitual, vocabulário, primeira tela (ver `diagnostico-de-erro.md`) | | **As palavras que ela procura não estão lá** | Varre a tela procurando um termo que você não usou | Ou você não antecipou o que ela procuraria, ou as palavras que você usa não são as que ela usaria | | **Há coisa demais acontecendo** | O alvo está na tela e ela não vê | Reduzir o ruído geral, ou aumentar o volume do que precisa ser visto, para que ele salte na hierarquia visual | --- ## 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 --- # Wireframe **Para quê:** planejar a interface antes de desenhá-la. **Quests:** 6 e 8 · **Modo:** 🟢 coprodução ## O que é Organização espacial e dimensionamento das interfaces — o esqueleto: o que fica onde, com que peso, em que ordem de leitura. Sem cor, sem tipografia definitiva, sem imagem final. ## Por que sem estética Porque a estética sequestra a conversa. Mostre um wireframe cinza e as pessoas discutem se a informação está no lugar certo; mostre a mesma tela colorida e discutem o tom do azul. Na fase em que você ainda está decidindo a estrutura, a segunda conversa é desperdício. Vale ainda mais agora que gerar interface bonita ficou barato: a facilidade de produzir alta fidelidade não é motivo para pular a estrutura. ## Como fazer 1. Liste as **tarefas** que o usuário precisa cumprir naquela tela (vem da jornada da Q6). 2. Ordene os elementos por importância para a tarefa — não por o que é fácil de posicionar. 3. Defina a hierarquia com **tamanho e espaço**, não com cor. 4. Deixe explícito o que é ação primária. Se há três botões do mesmo peso, não há ação primária. 5. Anote as regras que a tela não mostra: o que acontece no estado vazio, no erro, no carregamento. O item 5 é o mais esquecido, e estado vazio é a primeira coisa que todo usuário novo vê. ## Ligação com a Q8 O wireframe navegável é um ótimo material de teste de usabilidade — barato de mudar e sem inibir a crítica. Ver `../quests/q08-prototipo/SKILL.md`. --- ## Fontes - **Steve Krug**, *Não me faça pensar* — testar estrutura antes de estética - ⚠️ **Norman** (affordances e significantes) é a leitura seguinte, não a fonte desta ficha: nada aqui depende dele. Ele entra na Q8, em **Diagnóstico de erro — Quest #8** (`../quests/q08-prototipo/referencias/diagnostico-de-erro.md`) - Página `tecnicas/wireframe` do site da disciplina - A observação sobre geração barata de alta fidelidade é da disciplina --- # Microinterações **Para quê:** dar feedback ao usuário através do comportamento dos elementos. **Quests:** 6 (contenção) e 8 (conserto) · **Modo:** 🟢 coprodução ## O que são Pequenos comportamentos dos elementos da interface que produzem **feedback** para o usuário: o botão que reage ao toque, o campo que confirma que aceitou, a transição que mostra de onde veio o conteúdo novo. ## Por que importam Uma interface sem feedback deixa o usuário na dúvida sobre se sua ação teve efeito — e a dúvida produz repetição (clicar duas vezes), abandono ou desconfiança. A microinteração responde três perguntas silenciosas: *funcionou?*, *o que aconteceu?*, *onde eu estou agora?* ## Anatomia 1. **Gatilho** — o que inicia (ação do usuário ou evento do sistema) 2. **Regras** — o que acontece e sob que condições 3. **Feedback** — o que o usuário percebe 4. **Modo e ciclo** — o que muda se repetir, e o que permanece depois ## No Projetão Não é onde investir cedo. Numa Q6, microinteração é penduricalho — o que se cobra ali é o valor sendo entregue. Ela ganha importância na Q8, quando os testes revelam que o usuário **não percebeu** que algo aconteceu: esse é um problema de microinteração, e costuma ser barato de resolver. Sinal no teste de usabilidade: a pessoa clica duas vezes no mesmo botão, ou pergunta "deu certo?". É feedback faltando. ## Bibliografia *Designing Interface Animation*, de Val Head. --- ## Fontes - Página `tecnicas/microinteractions` do site da disciplina — o conceito e o porquê; ela se apoia em gestalt, ergonomia, usabilidade e comunicação - **Val Head**, *Designing Interface Animation* — a bibliografia declarada por aquela página - ⚠️ A anatomia em quatro partes (gatilho, regras, feedback, modos e ciclos) é vocabulário corrente da área, popularizado por Dan Saffer em *Microinteractions* (2013). **Esse livro não está no acervo da disciplina** e a página não o cita — não o apresente como fonte verificada aqui. - **Donald Norman**, *O design do dia a dia* — feedback, significantes e o Golfo da Avaliação - Página `tecnicas/microinteractions` do site da disciplina --- # Usuário afoito (*early adopter*) **Para quê:** ter com quem validar antes de o produto existir. **Quests:** 4 a 9 · **Modo:** 🔴 sem assistência no contato ## O que são Todo produto conta com um pequeno grupo de pessoas que quer usá-lo ou experimentá-lo **antes de estar completo**. São os early adopters, ou usuários afoitos. São pessoas que enxergam mais rápido o **valor** da solução — seja porque estão mais envolvidas com os problemas que ela resolve, seja porque conhecem com profundidade as alternativas disponíveis e não se sentem contempladas por nenhuma. De um jeito ou de outro, dispõem-se a adotar uma solução ainda imperfeita, e podem contribuir para aperfeiçoá-la. ## O que NÃO são Não é "quem gosta de tecnologia", nem "estudantes universitários", nem qualquer faixa demográfica. O critério é **intensidade da dor**, não perfil. Regra prática do Projetão: quem você viu usando a **gambiarra** mais elaborada na Q2 é seu candidato mais forte. Quem já gasta energia contornando o problema é quem mais quer que ele suma. ## Como trabalhar com eles Mesmo sem protótipo, os usuários afoitos ajudam a desenhar características e atributos da solução. A forma mais simples de envolvê-los é **construir uma comunidade** — começando com pessoas próximas que se qualifiquem como potenciais usuárias, e agregando novos membros aos poucos. Manter diálogo permanente com essa comunidade — apresentando avanços e ideias, permitindo que experimentem o que está em desenvolvimento, observando o uso e consultando sobre o que acham — cria engajamento com o projeto. A comunidade se torna a **base de validação** da solução. ## Ao longo das quests Aparecem quando se definem os públicos (Q4) e vão até a organização do processo produtivo (Q9) e a base de testes. Toda decisão de projeto precisa ser validada com usuários — e são eles que tornam isso possível. ## Teste de realidade Se você não consegue listar **cinco pessoas com nome** que usariam sua solução amanhã do jeito que ela está, você ainda não tem usuário afoito. Tem público-alvo, que é outra coisa. --- ## Fontes - **Ash Maurya**, *Running Lean* — o usuário afoito definido por intensidade do problema, não por demografia - **Steve Blank**, *The Four Steps to the Epiphany* — os cinco degraus do earlyvangelist - Página `tecnicas/afoitos` do site da disciplina - Ver **O usuário afoito — Quest #4** (`../quests/q04-escolha/referencias/usuario-afoito.md`) para os degraus abertos um a um --- # Brainstorm **Para quê:** gerar alternativas em grupo. **Quests:** 4 a 10 · **Modo:** 🟢 coprodução — com uma ressalva importante ## O que é Método tradicional de ideação: técnica para elaborar novas ideias em grupo, separando deliberadamente o momento de **gerar** do momento de **julgar**. ## As regras clássicas 1. **Adiar o julgamento.** Nenhuma crítica durante a geração. 2. **Buscar quantidade.** Volume primeiro; qualidade se seleciona depois. 3. **Acolher ideia estranha.** É de onde vem o que ninguém mais teria. 4. **Combinar e melhorar** as ideias dos outros. As quatro acima são as de Osborn. A disciplina acrescenta uma quinta, de condução: 5. **Um assunto por vez**, e uma pergunta bem formulada. A regra 1 é a que mais se quebra, e quebrá-la mata a sessão em cinco minutos. ## A ressalva da era da IA Pedir 50 ideias a um modelo generativo é trivial, e o resultado tem uma característica traiçoeira: é **plausível e médio**. O modelo produz o centro da distribuição — exatamente o oposto do que o brainstorm existe para encontrar. Use a IA aqui de dois jeitos que funcionam: - **Depois** da geração humana, para ampliar e combinar o que a equipe produziu. - Como **provocação enviesada**: peça ideias sob restrição forte ("e se fosse ilegal usar tela?", "e se o usuário tivesse 8 anos?", "e se o orçamento fosse zero?"). Restrição é o que tira o modelo — e as pessoas — da média. O que não funciona: gerar a lista pronta e escolher da lista. A equipe passa a escolher entre opções que ninguém entende profundamente. ## Alternativa quando o grupo é desigual Ver `brainwriting.md`. Em equipe onde algumas pessoas dominam a fala, o brainwriting produz mais e melhor. --- ## Fontes - **Alex Osborn** — as regras clássicas, via **Hanington & Martin**, *Universal Methods of Design*, que datam *Your Creative Power* em **1948** e a 3ª edição de *Applied Imagination* em **1993**; a página do site situa o método na "década de 1950" - Página `tecnicas/brainstorm` do site da disciplina - A ressalva sobre uso de IA na geração é da disciplina, não das fontes acima --- # Modo de IA — como esta disciplina trata o uso de inteligência artificial Leia isto antes de trabalhar em qualquer quest. Vale para o aluno e para a IA que o acompanha. ## A premissa **Todo aluno usa IA.** Não é concessão nem tolerância — é o ponto de partida da disciplina. Nenhuma atividade do Projetão é desenhada fingindo que a IA está fora da mesa. Disso decorrem duas consequências que mudam o trabalho. **A régua sobe.** Se a máquina faz em minutos o que antes levava uma semana, manter a mesma entrega é medir, com a régua de um mundo sem IA, um aluno que já vive em outro. Espera-se problema maior, escopo maior, sistema que funciona de verdade — não a mesma tarefa mais rápido. **A avaliação muda de objeto.** Se a máquina fabrica o produto, avaliar o produto mede a máquina. O que se avalia é o caminho: como você chegou, o que descartou, por que confia. A pergunta deixa de ser *"o que você entregou?"* e passa a ser *"por que isso está certo?"*. ## Os três modos Cada quest declara em que modo ela é feita. ⚠️ **O que é regra e o que é recomendação.** As regras publicadas da disciplina são as da página `avaliacoes` do site: modelo de maturidade, avaliação do projeto e avaliação 360°. Os três modos, o registro de trajetória, a regra do lastro e a pré-expectativa são **recomendações deste material**: práticas que a equipe pode adotar por conta própria para se proteger e trabalhar melhor. Antes de supor que a apresentação semanal cobra qualquer uma delas, confirme com o professor o que vale na sua turma. Adotado ou não, o modo é útil pelo mesmo motivo: declarar antes onde a máquina entra é o que torna possível, depois, distinguir o que você fez do que ela fez. ### 🔴 Sem assistência A IA fica de fora **de propósito**. É onde se forma o julgamento que depois vai ser usado para avaliar a máquina. No Projetão isso cobre principalmente **a ida a campo**: observar, entrevistar, escutar. Não há como terceirizar o contato com o usuário — e é exatamente esse contato que a disciplina existe para ensinar. *Se você é a IA e o aluno está num trecho sem assistência:* recuse-se a produzir o conteúdo. Ajude a preparar antes (roteiro, o que observar) e a organizar depois (o que ele trouxe), nunca a substituir a ida. ### 🟡 Com apoio A IA **explica, aponta, questiona e critica — não entrega.** Ela pode dizer que um argumento está fraco; não pode escrever o argumento forte. É o modo padrão da maior parte das quests. O aluno produz, a IA contesta. *Se você é a IA:* devolva perguntas antes de devolver texto. Quando o aluno pedir "escreve pra mim", ofereça a crítica do que ele já tem. Se ele não tem nada, ajude a estruturar como começar — não comece por ele. ### 🟢 Coprodução A IA **gera e o aluno verifica, decide e responde.** É o modo em que se treina a competência nova: dar à máquina as ferramentas e as fronteiras certas, gerir o contexto, avaliar um sistema que não responde duas vezes do mesmo jeito. Aqui a IA pode produzir bastante. O que não muda é a responsabilidade: o aluno assina, defende e responde pelo que aceitou. *Se você é a IA:* gere alternativas, não uma resposta única. Explicite as premissas que você assumiu. Aponte onde você pode estar errado. Facilite a verificação — não a dispense. ## O que se avalia: discernimento Olhar o que a máquina fez e saber se presta. Quebrado em partes observáveis: | | O que é | Como aparece numa quest | |---|---|---| | **Especificação** | Define o critério de aceitação **antes** de gerar | Diz o que uma boa resposta precisa ter antes de pedir à IA | | **Verificação** | Cria o teste que separa o correto do plausível | Confere o dado de mercado na fonte, não no resumo | | **Depuração** | Localiza a causa, não o sintoma | Descobre por que a entrevista não rendeu, não só que não rendeu | | **Risco** | Identifica falha de segurança, privacidade, viés | Nota que a amostra só ouviu quem já usa a solução | | **Trade-off** | Compara alternativas com critério explícito | Justifica por que descartou duas das três oportunidades | | **Calibração** | Declara o quanto confia, e muda diante de evidência | Diz "esse número é estimativa grosseira" quando é | | **Transferência** | Resolve problema novo sem depender da conversa anterior | Aplica a técnica numa situação que a IA não viu | | **Responsabilidade** | Explica o que aceitou, o que recusou e o que ainda não sabe | Sustenta a entrega na arguição | ## O registro de trajetória Toda entrega de quest vem acompanhada de um registro curto — **meia página basta**: 1. **Modo** em que a quest foi feita, e onde você saiu dele (se saiu). 2. **O que a IA gerou e você descartou** — e por quê. Este é o item mais informativo dos quatro. 3. **O que você verificou** e como. Que afirmação você foi conferir na fonte? 4. **O que ainda não sabe.** Incerteza declarada não tira ponto; incerteza escondida, sim. Não é burocracia de controle. É o material sobre o qual a nota é formada — e o único jeito de o mérito do aluno aparecer quando o artefato poderia ter saído de qualquer lugar. ## O que a disciplina não faz - **Não usa escore de detector de IA como prova.** Detectores erram de forma desigual: num teste com redações do **TOEFL** escritas por humanos, sete detectores classificaram como geradas por IA **61%** das redações de quem não é falante nativo de inglês, contra **5%** das de nativos (Liang, Yuksekgonul, Mao, Wu & Zou, *GPT detectors are biased against non-native English writers*, arXiv:2304.02819, 2023 — publicado em *Patterns*). ⚠️ O estudo mede texto em inglês; não há medida equivalente para português, e um contra-estudo do ETS com detectores mais recentes encontra viés menor (Jiang, Bosch, Attali & LaFlair, *Do AI detectors discriminate against non-native English writers?*, ETS Research, 2024). O ponto que sustenta a decisão não depende do número exato: **detector produz suspeita, não prova**, e o erro não se distribui por igual. - **Não trata declaração de não-uso como mecanismo de controle.** Além de não ser cumprida pela maioria, expõe justamente quem declara com honestidade. O que substitui os dois é mais trabalhoso e é o que forma: avaliar o processo e o raciocínio. ## Duas obrigações que valem nos dois sentidos **Acesso.** Assumir que todo aluno usa IA e deixar cada um arcar sozinho com a ferramenta converteria capacidade de pagamento em desempenho. A disciplina se compromete a viabilizar acesso por modelos gratuitos, quotas e parcerias. Se você está sem acesso, isso é problema da disciplina, não seu — avise. **Custo.** Use o modelo adequado à tarefa, não o maior por reflexo, e declare a escolha quando ela for relevante. Formar alguém para usar bem uma tecnologia inclui formá-lo para perguntar quanto ela custa — e não apenas em dinheiro. --- *Baseado no manifesto do Porto Digital sobre formação em tecnologia na era da IA (Residência Tecnológica, 2026). A adoção no Projetão está em curso: o que funcionar e o que não funcionar será medido e publicado.* --- # Consentimento e dados de terceiros Este material manda você fotografar pessoas em campo, gravar entrevistas, gravar tela de teste de usabilidade e registrar nome e contato de quem foi ouvido. Tudo isso é **dado de outra pessoa**. Ela não é sua colega de equipe nem parte do projeto: ela cedeu meia hora do dia dela. O que segue é o mínimo para que a coleta seja honesta. Não é assessoria jurídica, e não substitui o que o professor ou o comitê de ética da instituição determinar. Se o seu projeto envolve **saúde, crianças e adolescentes, população em situação de vulnerabilidade, dados de pessoas identificáveis em contexto sensível ou qualquer forma de dado que possa expor alguém**, pare aqui e pergunte ao professor antes de ir a campo. --- ## A regra curta **Pergunte antes, em voz alta, e aceite o não.** Três frases, ditas no começo da conversa, resolvem a maior parte dos casos: > "Sou aluno da UFPE, estou fazendo um trabalho de disciplina sobre *[tema]*. Posso te fazer umas perguntas por uns 20 minutos?" > > "Posso gravar só o áudio, para eu não perder nada? Fica com a minha equipe e com o professor da disciplina, que confere o trabalho; ninguém mais ouve, e eu apago no fim do semestre." > > "Se em algum momento você quiser parar, ou quiser que eu tire alguma coisa, é só falar." Se a pessoa hesitar na segunda, **não grave** — anote. Uma entrevista anotada vale mais que uma gravação que a pessoa cedeu constrangida. --- ## O que muda conforme o registro | Registro | O que fazer | |---|---| | **Anotação escrita** | Avise que está anotando. Não registre nome completo se não precisar dele. | | **Áudio** | Peça na hora, com a gravação **ainda desligada**. Comece a gravação pedindo de novo, agora gravado: assim o consentimento fica no próprio arquivo. | | **Foto de pessoa identificável** | Peça. Se for espaço público e a pessoa não é o assunto (multidão, movimento do lugar), enquadre de modo que ela não seja identificável. | | **Foto de lugar, objeto, fila, cartaz** | Livre, desde que não capture rosto, documento nem tela com dado de alguém. | | **Foto de gambiarra** | **Peça.** Gambiarra quase sempre documenta alguém contornando uma regra do próprio trabalho — o exemplo canônico da disciplina é discutir caso clínico por WhatsApp. A pessoa é identificável pelo contexto mesmo sem aparecer, e a foto pode custar o emprego dela. Fotografe só com permissão, e descreva sem nomear o local se houver qualquer risco. | | **Vídeo ou gravação de tela em teste de usabilidade** | Peça explicitamente e diga o que vai ser gravado (a tela e a voz, não o rosto — é o padrão, e basta). | | **Nome e contato** | Só colete se você **vai** usar: para voltar a falar com a pessoa, ou para o professor conferir. Guarde separado das respostas. | --- ## Observação em espaço público Observar o movimento de uma praça, de uma fila, de um ginásio não exige pedir permissão a cada pessoa — mas exige três cuidados: 1. **Não registre rosto, placa, crachá, documento ou tela alheia** sem pedir. 2. **Se alguém perguntar o que você está fazendo, responda a verdade.** Você é aluno, está fazendo um trabalho, e vai embora. Observador que se esconde perde o direito de estar ali. 3. **Se o lugar tem dono ou responsável** — comércio, escola, posto de saúde, empresa —, apresente-se a ele antes. Entrar sem avisar e depois ser descoberto queima o campo para você e para as próximas turmas. --- ## Campo virtual A Q1 diz que **espaço virtual conta**, e boa parte das técnicas tem versão à distância. As regras mudam: | Situação | O que fazer | |---|---| | **Observar comunidade online** (grupo, fórum, comentários) | Ler é uma coisa; **reproduzir** é outra. Não cole print com nome de usuário, foto de perfil ou texto que identifique alguém. Parafraseie, ou peça autorização à pessoa. Grupo fechado não é espaço público: entrar para pesquisar sem dizer a que veio é o mesmo que observar escondido. | | **Chamada de vídeo** | Peça para gravar **antes** de apertar o botão, e de novo já gravando. Diga se o rosto entra ou só a voz. Ferramenta que transcreve sozinha também é gravação: avise. | | **Teste de usabilidade remoto** | Grave tela e voz, não a câmera. Lembre a pessoa de fechar aba, notificação e qualquer coisa pessoal antes de compartilhar a tela — a responsabilidade de avisar é sua. | | **Formulário** | Não peça dado que você não vai usar. Se pedir e-mail ou telefone, diga para quê, e não torne obrigatório. | | **Print de conversa** (WhatsApp, chat) | É dado de duas pessoas, não de uma. Peça às duas, ou tarje. | --- ## A pessoa pode mudar de ideia depois Consentimento não é assinatura que encerra o assunto. Se a pessoa procurar você depois da conversa e pedir para retirar o que disse, ou apagar a gravação, **atenda** — mesmo que já esteja na entrega. Diga isso a ela no começo: > "Se depois você quiser que eu tire alguma coisa, me avisa que eu tiro." Guarde um jeito de encontrar o material dela: se você não sabe qual gravação é de quem, não consegue cumprir a promessa. --- ## E a lei No Brasil vale a **LGPD** (Lei 13.709/2018). Você não precisa virar especialista, mas três noções mudam decisões concretas: - **Dado pessoal** é o que identifica alguém — nome, telefone, e-mail, imagem, voz, e também o que identifica **por combinação** ("o enfermeiro do turno da noite daquele posto"). - **Dado sensível** — saúde, origem racial ou étnica, convicção religiosa, opinião política, filiação sindical, vida sexual, biometria — tem regra mais estrita. Se o seu projeto encosta nisso, fale com o professor **antes** de coletar. - **Finalidade e prazo:** você coleta para o trabalho da disciplina, e apaga no fim do semestre. Usar depois para outra coisa — um artigo, uma startup, um portfólio — é outra finalidade e exige pedir de novo. ⚠️ Isto é orientação de bolso, não parecer jurídico. Em dúvida, pergunte ao professor. --- ## Quem não pode consentir sozinho - **Menores de 18 anos:** o consentimento é de quem responde por eles. Se o seu projeto é sobre adolescentes, isso não é detalhe de execução — é uma restrição de escopo que muda o cronograma. Fale com o professor **antes da Q1**. - **Pessoa em situação de dependência em relação a você** (seu funcionário, seu aluno, alguém que espera algo de você): o "sim" dela não é livre. Procure outra pessoa. - **Pessoa que não entendeu o que você pediu.** Se você não conseguiu explicar em duas frases o que vai fazer com o material, o problema é seu, não dela. --- ## Enquanto o material existe - **Guarde no lugar da equipe, não no seu celular pessoal** — e num lugar em que quem saiu da equipe deixa de ter acesso. - **Não publique bruto.** Nem no repositório do projeto, nem no slide do Demoday, nem no grupo da turma. Na apresentação vai o **achado**, não a gravação; se for indispensável mostrar um trecho, peça de novo à pessoa, especificamente para isso. - **Anonimize na entrega.** "Jorge, 53 anos, usuário do parque" é persona. "Jorge Silva, (81) 9xxxx-xxxx, mora na rua tal" é dado pessoal e não entra em documento que circula. - **Apague no fim do semestre.** Diga isso à pessoa no começo, e depois cumpra. --- ## O que a IA não faz aqui Este é um ponto em que a máquina não ajuda, e tentar usá-la piora: - **Não peça à IA que invente a fala de um entrevistado**, nem para "completar" uma entrevista curta. Se você tem cinco minutos de conversa e precisa de vinte, volte a campo. - **Não cole gravação nem transcrição com nome, contato ou dado de saúde de terceiro** numa ferramenta de IA sem saber o que ela faz com aquilo. Anonimize antes: troque nomes por iniciais, tire telefone e endereço. - **Transcrever e organizar o que a pessoa disse** é uso legítimo (🟡 com apoio). **Escrever o que ela teria dito** não é uso: é invenção de evidência, e é o erro que mais desqualifica um projeto. --- ## O teste de uma frase Antes de registrar qualquer coisa, pergunte-se: > **Se essa pessoa visse depois o que eu guardei, e onde guardei, ela se sentiria enganada?** Se a resposta for "talvez", peça de novo — agora explicando a parte que você não explicou. --- ## Fontes - **IDEO**, *HCD Toolkit* (pt-BR) — a fase *Ouvir*: apresentar-se, explicar o propósito e pedir permissão antes de registrar - **Holtzblatt, Wendell & Wood**, *Rapid Contextual Design* — o acordo explícito com o participante no começo da sessão de indagação contextual - **Steve Krug**, *Não me faça pensar* / *Rocket Surgery Made Easy* — a prática de gravar tela e voz, não rosto, e de avisar o participante do que está sendo gravado. Krug vai além e prescreve um **formulário de autorização de gravação, assinado antes da sessão**; num trabalho de disciplina o pedido verbal gravado costuma bastar, mas se a sessão vai ser gravada em vídeo, ou o material pode sair da equipe, use o formulário - **Lei 13.709/2018 (LGPD)** — as noções de dado pessoal, dado sensível, finalidade e prazo - ⚠️ O restante deste arquivo é **orientação da disciplina**, não regra publicada no site do Projetão nem parecer jurídico. Em projeto que envolva população vulnerável ou dado sensível, a palavra final é do professor e do comitê de ética da instituição. --- # Avaliação — como o Projetão mede um projeto Quatro instrumentos rodam em paralelo: o **modelo de maturidade** (semanal, diagnóstico), a **avaliação do projeto** (final, nota), a **avaliação 360°** (dos pares, ajuste individual) e o **registro de trajetória** (semanal, o que separa o aluno da máquina). ⚠️ **Três são regra; o quarto é recomendação.** Modelo de maturidade, avaliação do projeto e avaliação 360° são o que a página `avaliacoes` do site da disciplina descreve. O **registro de trajetória** — e com ele a **regra do lastro** e a **pré-expectativa**, mais abaixo — é recomendação deste material, não regra publicada. Nada aqui substitui o enunciado do professor: se ele não pediu, não é exigência. Está aqui porque o problema que ele resolve é real, e porque a equipe que o adota sozinha se protege: O quarto existe por um motivo declarado: > **Se a máquina fabrica o produto, avaliar o produto mede a máquina.** Os três primeiros instrumentos avaliam o **artefato**. Sozinhos, eles medem cada vez menos o aluno — e essa é a razão de o quarto existir. Ver `modo-ia.md`. --- ## 1. Modelo de maturidade — 13 milestones, escala 0–5 Acompanhado **semanalmente**. Não gera nota: gera diagnóstico. Serve para a equipe saber onde está frágil enquanto ainda dá tempo de consertar. **Aprovação exige nível 4 em todos os 13.** Um projeto com doze cincos e um dois não está pronto. ### A escala | Nível | Significado | |---|---| | **0** | O critério ainda não aparece no projeto. | | **1** | Já aparece, mas sem clareza nem coerência. Normal na primeira vez que o tema é tocado. | | **2** | Falta clareza **ou** falta coerência com o resto. A resposta ainda está no terreno da insegurança. | | **3** | Coerente, mas ainda não totalmente claro. Há amadurecimento, resta uma parcela de incerteza. | | **4** | Claro e coerente com toda a proposta. Ainda cabe aperfeiçoar, mas a equipe responde com segurança. | | **5** | Perfeitamente alinhado ao conjunto. As respostas às questões de projeto são sólidas. | O salto que trava a maioria das equipes é o **3 → 4**: sair de "faz sentido" para "eu sustento isso sob pergunta". Quase sempre o que falta não é redação — é evidência de campo. > ⚠️ **A escala tem um ponto cego, e ele piora com IA.** Do 3 para cima, a diferença entre os níveis é descrita em termos de *clareza*, *coerência* e *segurança na resposta* — exatamente as qualidades que um texto bem gerado exibe sem que nenhum trabalho tenha sido feito. Um nível 5 escrito por máquina é mais elegante que um nível 4 escrito por quem foi a campo e voltou confuso. > > **Por isso, do 4 para cima o nível exige artefato, não redação.** Ver a regra do lastro, logo abaixo. ### A regra do lastro ⚠️ *Recomendação deste material — não é regra publicada da disciplina. Ver o aviso no topo.* Para pontuar **4 ou 5** em qualquer milestone, a equipe precisa apresentar, junto com a resposta, **pelo menos um artefato de trabalho** — algo que existe porque o trabalho foi feito, e que não seria produzido por quem apenas escreveu bem sobre ele. | Vale como lastro | Não vale | |---|---| | Foto do campo, com data | Descrição do que foi observado | | Áudio ou anotação bruta de entrevista | Resumo da entrevista | | Nome e contato de quem foi ouvido (com consentimento) | "Entrevistamos 14 pessoas" | | Post-its ou quadro de afinidades fotografado | A conclusão do agrupamento | | Gravação de tela do teste de usabilidade | Lista de problemas encontrados | | Link e captura da fonte do dado, com data de acesso | O número citado | | Registro de pré-expectativa datado (ver abaixo) | A afirmação de que houve surpresa | ⚠️ **O lastro é material de terceiros — trate-o como tal.** Foto, áudio, gravação de tela e contato pertencem a quem foi ouvido, não à equipe. Antes de coletar qualquer um deles, leia `consentimento.md`. E o lastro **não circula**: ele fica no repositório da equipe, e o professor o consulta ali, quando avalia. Não vai para o slide, não vai para o grupo da turma, não entra em documento que sai da disciplina. Quem promete "só a minha equipe e o professor" e depois publica um trecho quebrou a promessa que fez em campo. Lastro não precisa ser bonito nem organizado. Precisa ser **anterior à conclusão** e **custoso de fabricar**. ### A pré-expectativa — o único registro que não dá para forjar depois ⚠️ *Recomendação deste material — não é regra publicada da disciplina. Ver o aviso no topo.* Antes de ir a campo, a equipe escreve **o que espera encontrar**, e envia — com carimbo de data — para o canal da disciplina. Uma frase por item basta. Isso custa dez minutos e resolve o problema mais difícil da avaliação: *retroativamente, qualquer um consegue escrever que foi surpreendido.* Ninguém consegue escrever, antes, uma expectativa que depois se prove errada de um jeito específico. Na apresentação, a equipe compara o que escreveu com o que achou. **A divergência é o dado.** Equipe cuja pré-expectativa bateu 100% ou não foi a campo, ou não observou. ### Os 13 critérios | Milestone | Do que trata | Começa na quest | |---|---|---| | **Usuário** | Clareza sobre quem é o usuário/consumidor potencial | Q2 | | **Problema** | Compreensão do problema efetivo que se tenta resolver | Q3 | | **Similares** | Profundidade sobre concorrentes, práticas e boas referências | Q3 | | **PUV** | Identificação de um valor único a entregar, como centro da inovação | Q5 | | **Solução** | Maturidade da proposta e de como ela resolve o problema | Q6 | | **Prova de conceito** | Validação da solução conceitual junto ao usuário | Q6 ⚠️ | | **MVP / Implementação** | Amadurecimento do produto mínimo que entrega os valores validados | Q6 | | **Estratégias de tração** | Como a equipe se aproxima e constitui um grupo de usuários afoitos | Q7 | | **Tração efetiva** | Transformação em negócio real; divulgação e promoção | Q7 | | **Testes de usabilidade** | O que a equipe aprendeu testando, e como a solução mudou | Q8 | | **Plano de projeto** | Organização da equipe, processo produtivo, divisão de responsabilidades | Q9 | | **Modelo de receitas** | Custos, preço, formas de obter recursos | Q7 | | **Pitch** | Clareza para quem não acompanhou o projeto por meses | Q10 | > ⚠️ **Correção de numeração.** A planilha de maturidade publicada no site do Projetão foi escrita quando a disciplina tinha **9 quests**. Depois entrou a Q4 (Oportunidade Escolhida & Organização da Equipe) e tudo de Q4 em diante deslocou uma casa. A tabela acima já está **corrigida para as 10 quests atuais**. Se você comparar com a planilha original, verá as referências antigas — a diferença é essa, não é erro seu. > ⚠️ **Um milestone mudou de lugar por decisão, não por renumeração.** A planilha original põe **Prova de conceito** na quest anterior — que, pelo deslocamento acima, seria a **Q5**. Aqui ela está na **Q6**, porque a Q6 se chama literalmente "MVP & Prova de Conceito" e é onde a validação com usuário acontece. Todos os outros doze milestones seguem o deslocamento de +1 exato; este é o único em que houve escolha. Se o seu professor cobrar a prova de conceito já na Q5, siga o professor — e saiba que a diferença é esta. ### Índices de saúde da equipe Registrados junto com os milestones: - **Tamanho da equipe** — quantos alunos a compõem - **Presença** — quantos estão na apresentação - **Engajamento** — a razão entre os dois Engajamento é o melhor preditor isolado de projeto que termina mal. Queda sustentada nesse índice antecede, com regularidade, entrega incompleta no Demoday. Se a sua equipe está caindo, isso é um problema de projeto — não de frequência. --- ## 2. Registro de trajetória — o que separa o aluno da máquina Entregue **junto com cada quest**. Meia página. É o instrumento que responde "por que isso está certo?" em vez de "o que você entregou?". ### O que ele contém 1. **Modo de IA** em que a quest foi feita, e onde vocês saíram dele. 2. **O que a IA gerou e vocês descartaram — e por quê.** 3. **O que vocês verificaram, e como.** Que afirmação foram conferir na fonte primária? 4. **O que ainda não sabem.** ### Como ele é lido — e por que não basta escrevê-lo bem Este registro é, sozinho, o item mais fácil de fabricar do material inteiro: descrever com elegância o erro de uma IA é justamente a tarefa em que a IA é boa. Uma equipe pode produzir um registro convincente sem ter descartado nada. Três coisas tornam isso caro, e as três são baratas de exigir: **Lastro no item 2.** "Descartamos a persona que a IA propôs" não vale nada. **Cole a persona descartada.** O artefato descartado é gratuito para quem descartou de verdade e trabalhoso para quem não descartou. **Rastro no item 3.** "Conferimos o dado na fonte" não vale nada. **Diga qual afirmação, qual fonte, qual data de acesso, e o que estava diferente do que a IA disse.** Verificação que não achou nenhuma divergência em dez semanas é verificação que não aconteceu. **Consistência ao longo do semestre.** Este é o mecanismo mais forte, e é praticamente gratuito. As dez quests se encadeiam: o usuário afoito da Q4 tem de ser um dos ouvidos na Q2; os concorrentes da Q3 têm de aparecer na curva da Q5; a base de testes da Q9 tem de ser gente citada antes. **Fabricar dez semanas coerentes entre si custa mais que fazer o trabalho** — e a incoerência aparece sozinha na comparação. > **Não se avalia um registro de trajetória isolado. Avalia-se a série.** ### O que a disciplina não faz - **Não usa escore de detector de IA como prova.** Detectores erram de forma desigual: num teste com redações do **TOEFL** escritas por humanos, sete detectores classificaram como geradas por IA **61%** das redações de quem não é falante nativo de inglês, contra **5%** das de nativos (Liang, Yuksekgonul, Mao, Wu & Zou, *GPT detectors are biased against non-native English writers*, arXiv:2304.02819, 2023 — publicado em *Patterns*). ⚠️ O estudo mede texto em inglês; não há medida equivalente para português, e um contra-estudo do ETS com detectores mais recentes encontra viés menor (Jiang, Bosch, Attali & LaFlair, *Do AI detectors discriminate against non-native English writers?*, ETS Research, 2024). O ponto que sustenta a decisão não depende do número exato: **detector produz suspeita, não prova**, e o erro não se distribui por igual. - **Não trata declaração de não-uso como mecanismo de controle.** Além de não ser cumprida pela maioria, expõe justamente quem declara com honestidade. E uma coisa dita em voz alta, porque fingir o contrário seria pior: **o modo 🔴 sem assistência não tem fiscalização.** Nada impede um aluno de abrir outra aba. O que sustenta o modo não é vigilância — é o fato de que, sem o campo, ele não terá lastro para pontuar 4, e a incoerência entre as quests vai aparecer. O modo é um contrato, e o custo de quebrá-lo é diferido, não imediato. --- ## 3. Avaliação do projeto — nota 0 a 10 Feita pelos professores sobre o projeto ao final da disciplina. Considera: - **Completude** — da concepção até a execução e o pleno funcionamento - **Inovação** — a solução precisa trazer inovação na sua elaboração - **Especificidades** — cada disciplina tem exigências próprias que precisam aparecer - **Resultados** — qualidade do trabalho, levando em conta o amadurecimento ao longo do semestre e as considerações da banca no Demoday - **Trajetória** — a série de registros semanais: o que a equipe descartou, o que verificou, e o quanto o projeto mudou por causa de evidência O último critério é o que traz o processo para dentro da nota. Sem ele, a avaliação final mede o artefato — e o artefato, hoje, pode vir de qualquer lugar. A **banca do Demoday** é formada por profissionais do mercado. Ela influencia a nota, mas não a determina: julga o resultado apresentado, sem ter acompanhado o processo de aprendizado do semestre. Cada equipe tem um **professor mentor**, que acompanha de perto e atua como advogado da equipe na avaliação — ele é quem conhece as dificuldades que o resultado final não mostra. E é ele quem tem a série completa de registros de trajetória. --- ## 4. Avaliação 360° — ±2 pontos Cada aluno avalia **cada colega da própria equipe** em três dimensões: - **Engajamento** — atenção dada ao trabalho, envolvimento, colaboração nas tarefas - **Produtividade** — quanto cada um trabalhou e entregou - **Convivência** — o quanto as relações têm sido colaborativas, respeitosas e fluidas O resultado **soma ou subtrai até 2 pontos** sobre a nota de projeto do grupo, individualizando a nota de cada aluno. **Como o cálculo funciona, e por que isso importa:** o valor é calculado sobre o **desvio do aluno em relação à média da própria equipe** — não em relação a uma régua absoluta. Consequências práticas: - Avaliar todo mundo com nota máxima não beneficia ninguém: se todos estão na média, todos ficam em zero de ajuste. - Numa equipe que trabalhou bem por igual, o ajuste tende a zero — o que é o resultado correto. - Numa equipe desequilibrada, o instrumento separa. É desenhado para isso. --- ## Autodiagnóstico ao fim de cada quest Faça o exercício antes que ele seja feito por outros: 1. Que milestone esta quest alimenta? 2. Em que nível de 0 a 5 você se coloca? 3. **Qual artefato sustenta esse nível?** — se a resposta é "acho que ficou bom", o nível é 2. Se é um texto bem escrito e nada mais, o teto é 3. 4. O que faltaria para chegar a 4? Divergência entre a auto-avaliação da equipe e a leitura do mentor é informação útil, não constrangimento. Equipe que se dá 5 no que o mentor vê como 2 tem um problema anterior ao do projeto.