O planejamento do sprint é na quinta-feira, e o topo do backlog depende de três coisas que ninguém verificou. Os usuários desejam o recurso, eles o encontrarão e entenderão o que ele faz quando o fizerem. Cada crença é plausível e cada uma já foi escrita em um bilhete.
A pesquisa de usuários de IA usa modelos de linguagem para simular ou analisar conversas de usuários, para que uma equipe possa fazer uma pergunta a um público modelado em minutos, em vez de recrutar pessoas por semanas. Bem usado, ele dá à equipe de produto uma primeira verificação barata das suposições do backlog. Mal utilizado, produz um acordo que parece confiante. Este guia cobre uma rotina de dois dias que obtém benefícios e evita armadilhas.
Principais conclusões
- Teste apenas suposições que possam alterar um ticket. Se uma resposta errada não alterar o plano, pule a verificação.
- Escreva de três a cinco cartões de suposições antes de planejar, cada um com a crença, o custo de estar errado e a decisão que isso alimenta.
- Trate as respostas da IA como hipóteses. Usuários simulados são bons para esclarecer questões e ruins para comprovar a demanda.
- Rotular as evidências como modeladas, observadas ou relatadas, e agende uma verificação de usuário real para qualquer coisa baseada em evidências modeladas.
O que conta como uma suposição que vale a pena testar?
Vale a pena testar uma suposição quando o plano depende dela e uma resposta errada mudaria o ticket. “Usuários gostam de interfaces limpas” falha nesse teste. “Os analistas reaplicam os mesmos filtros a cada sessão” é aprovado, porque se for falso, o recurso de filtros salvos diminui ou desaparece.
O momento é importante porque o planejamento deixa pouco espaço para pesquisa. O Guia Scrum diz O Sprint Planning tem um limite de tempo de no máximo oito horas para um Sprint de um mêse a primeira pergunta que a equipe responde é por que o Sprint é valioso. As verificações realizadas antes dessa reunião informam a resposta. As verificações são executadas durante o período destinado à decisão.
Como você transforma um item do backlog em uma suposição testável?
Escreva cada item arriscado como um pequeno cartão que nomeia a crença, a consequência de estar errado e a decisão que ela alimenta. Um cartão força a equipe a dizer o que mudaria de ideia, o que a maioria dos tickets nunca faz. Aqui está um exemplo:
Item: Saved filters on the reports page
We believe: Analysts re-apply the same few filters every session
If false: Cut the ticket, or shrink it to "remember last filter"
Evidence: Two support tickets, no usage data
Test: Ask a modeled audience of analysts how they set up a weekly report
Decide by: Wednesday, before planning
Procure usar de três a cinco cartas. Uma equipe que tenta testar todo o backlog não testará nada disso, e os cartões dos itens mais arriscados proporcionam o melhor retorno.
O que a pesquisa de usuários de IA faz na prática?
A pesquisa de usuários de IA vem em duas formas. O primeiro analisa os dados que você já possui: agrupando tickets de suporte e resumindo as transcrições das entrevistas. Funciona com base em evidências reais, portanto seu principal risco é um resumo desleixado.
A segunda forma entrevista pessoas simuladas. Pesquisa de usuários de IA desse tipo constrói um painel de personas modeladas que correspondem ao seu perfil-alvo, faz suas perguntas e relata os temas. Não precisa de recrutamento e retorna resultados rapidamente, o que cabe em uma janela de dois dias. O seu resultado provém de um modelo de utilizadores e não de utilizadores, e essa distinção deve aparecer em todos os documentos de planeamento que o citam.
Quais suposições são adequadas para uma verificação de IA e quais não?
Um público simulado ajuda mais quando você deseja aprimorar uma pergunta e menos quando precisa de provas. Grupo Nielsen Norman Revisão de 2024 de usuários sintéticos considerá-los úteis para gerar hipóteses e preparar guias de entrevista. Alertou contra a sua utilização para decisões finais ou validação de conceitos, e para populações de nicho, porque a IA tende a agradar e “cada ideia é muitas vezes vista como boa”.
- As pessoas entenderão esse rótulo ou mensagem? — Sim, como primeira passagem. Problemas de compreensão aparecem no texto.
- Qual problema devemos abordar nas entrevistas? – Sim. A saída funciona como uma lista de hipóteses.
- Os usuários desejam esse recurso? — Fracamente. Os modelos tendem a concordar com a ideia.
- Eles vão pagar por isso? — Não. As preferências declaradas e modeladas derivam do comportamento.
- Eles podem completar esse fluxo? — Não. Precisa de observação de pessoas reais.
- Os especialistas em um nicho de área precisam disso? — Não. Os dados de formação sobre pequenas populações são irregulares.
Como você faz a verificação dois dias antes do planejamento?
Passe a terça coletando respostas e a quarta lendo-as com ceticismo. Na terça-feira, faça a pergunta de cada cartão ao público modelado em termos neutros e pergunte o que os faria não usar o recurso. Uma pergunta formulada como “Os filtros salvos ajudariam você?” convida a um sim, enquanto “Oriente-me na configuração do seu relatório semanal” não.
Na quarta-feira, compare as respostas com o que você já sabe por meio de tickets de suporte e análises. Marque cada suposição como apoiada, contradita ou pouco clara. Trate uma resposta unânime com suspeita, porque o público real raramente concorda em alguma coisa. Tenha também cuidado com listas nas quais os usuários modelados “parecem se importar com tudo”, que é como o Nielsen Norman Group descreve sua fraca priorização.
Tudo o que permanece obscuro ou de alto risco vai para pessoas reais. A análise clássica de Jakob Nielsen descobriu que cinco usuários encontram cerca de 85% dos problemas de usabilidadeassumindo usuários comparáveis, e ele recomendou várias rodadas pequenas em vez de uma grande. Uma verificação de IA é uma boa maneira de decidir o que deve ser perguntado a essas cinco pessoas.
Como os resultados devem mudar o sprint?
Cada marca mapeia para uma decisão diferente. Uma suposição contradita significa que o ticket é cortado ou reduzido à sua menor versão útil. Uma suposição apoiada que se baseia apenas em evidências simuladas ainda não é segura; portanto, agende uma verificação de usuário real como a primeira tarefa do sprint, antes do trabalho de construção que depende dela. Uma suposição pouco clara não deveria receber todo o escopo.
O custo de pular esta etapa é real. Uma análise de 2019 de 615 assinaturas de produtos por um fornecedor de análise de produtos descobriu que cerca de 12% dos recursos geram 80% do volume de uso diário e 80% dos recursos raramente ou nunca são usados. Essa é a base de clientes de um fornecedor, e os números abrangem recursos que os clientes optaram por acompanhar, portanto, trate-os como um guia aproximado. Eles ainda sugerem que a maior parte do acúmulo é uma aposta.
Quais são os limites da pesquisa de usuários de IA?
A pesquisa de usuários de IA não pode substituir a conversa com usuários reais. O Nielsen Norman Group descobriu que os usuários sintéticos deram relatos excessivamente otimistas sobre seu próprio comportamento, como afirmar que terminaram todos os cursos de um estudo, e que não podiam fornecer experiências reais do passado. Também chamou a apresentação de descobertas sintéticas como descobertas de usuários reais de “uma forma antiética de compartilhar o que você aprendeu”.
Dois hábitos mantêm uma equipe honesta. Rotule cada evidência no documento de planejamento como modelada, observada ou relatada e exija que qualquer recurso construído com base na evidência modelada tenha uma verificação do usuário real agendada. A revisão também alertou que as equipes que estão começando com a pesquisa sintética podem se sentir confortáveis e pular a pesquisa real, portanto, coloque a verificação real no calendário antes que o primeiro resultado da IA chegue.
Perguntas frequentes
A pesquisa de usuários de IA pode substituir entrevistas com usuários reais? Não. É uma primeira passagem barata que ajuda você a escrever perguntas melhores e identificar suposições fracas. Qualquer coisa que impulsione uma construção significativa ainda precisa de pessoas reais.
Quantas suposições uma equipe deve testar antes de planejar? Três a cinco. Escolha aqueles em que uma resposta errada cortaria ou remodelaria um ticket.
Como faço para impedir que usuários simulados concordem comigo? Use perguntas neutras e abertas, pergunte o que os faria evitar o recurso e trate as respostas unânimes como um sinal de alerta.
O que devo fazer com resultados que não posso verificar? Marque-os como modelados, dê-lhes menos peso do que as evidências observadas e agende uma verificação do usuário real antes de comprometer o escopo completo.
Fontes: Guia Scrum, Planejamento de Sprint; Jakob Nielsen, “Por que você só precisa testar com 5 usuários” (18 de março de 2000); Nielsen Norman Group, “Usuários sintéticos: se, quando e como usar ‘pesquisas’ geradas por IA” (21 de junho de 2024); Relatório de adoção de recursos de 2019 (615 assinaturas de produtos, informado pelo fornecedor).
