# 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** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-08.md) | Antes de testar. Roteiro completo, falas literais, recrutamento, o debriefing | | **Diagnóstico de erro — Quest #8** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-08.md) | Ao analisar. Deslize × engano, as sete fases, os golfos, feedback | | **Protótipos e inspeção — Quest #8** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-08.md) | 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** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-08.md) | o que testar em cada fidelidade | | **Microinterações** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-08.md) | quando o usuário não percebe que algo aconteceu | | **Usuário afoito (*early adopter*)** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-08.md) | quem recrutar | | **Brainstorm** (https://projetao-ufpe.vercel.app/baixar/colar/projetao-08.md) | 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 | --- # 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. --- # 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. --- > Versão leve. As referências completas desta quest estão em > https://projetao-ufpe.vercel.app/baixar/colar/projetao-08.md