Comece pela situação, antes da solução.
Antes de investir no desenvolvimento, explicite quem enfrenta o problema, em que momento ele aparece e qual consequência produz. Esse enquadramento ajuda a comparar possibilidades e a reconhecer quando uma nova funcionalidade não é a melhor resposta.
“Precisamos de um aplicativo” ainda deixa perguntas importantes abertas. Quem vai usá-lo? Que tarefa é difícil hoje? O que acontece quando ela não é concluída? A conversa fica mais concreta quando sai do formato da solução e chega à experiência de quem precisa dela.
Exemplo hipotético. Uma equipe pede um painel de acompanhamento porque recebe muitas perguntas sobre solicitações em aberto. O problema pode estar na ausência de atualizações, em mensagens pouco claras ou na própria demora da operação. Cada causa pede uma resposta diferente.
Separe o que você sabe do que precisa descobrir.
Registre as observações disponíveis sem transformá-las automaticamente em uma explicação. Uma pessoa abandonar um formulário mostra uma interrupção; não revela, sozinha, o motivo. Pode haver dúvida, falta de informação, erro ou simplesmente uma mudança de prioridade.
Organize a conversa em três perguntas:
- O que observamos? Uma situação concreta, com contexto e origem.
- O que acreditamos que explica isso? Uma hipótese que ainda pode mudar.
- Como podemos aprender? Uma observação de uso, entrevista ou teste que ajude a reduzir a incerteza.
O guia de descoberta do GOV.UK orienta a investigar o problema e as necessidades das pessoas antes de se comprometer com a construção. Na prática, isso pede espaço para revisar a solução inicialmente imaginada.
Escolha um recorte que permita decidir.
Um problema amplo demais torna difícil saber onde começar. Em vez de tentar “melhorar toda a experiência”, selecione uma tarefa, um grupo de pessoas e uma situação de uso. Descreva também o que ficará fora da primeira investigação.
No exemplo do painel, um recorte possível seria entender como o solicitante descobre o andamento do pedido. A equipe pode observar as mensagens recebidas e testar uma atualização de status mais clara antes de assumir o custo de uma nova área do produto.
Defina o que o aprendizado vai permitir decidir.
A investigação precisa levar a uma escolha. Estabeleça o que faria o time seguir, ajustar ou abandonar uma hipótese. Combine os sinais observáveis e quem participa da decisão, sem criar metas numéricas que ainda não têm uma referência real.
Ao final, o objetivo é ter um problema mais claro, prioridades discutíveis com evidências e um próximo passo proporcional ao que se sabe. Isso conecta o diagnóstico à execução e evita transformar a primeira ideia em compromisso permanente.
Leve uma decisão para a reunião, além de uma lista de pedidos.
Para comparar demandas, sugerimos registrar os pontos abaixo em uma página. O objetivo é tornar o critério de escolha visível para negócio, design e engenharia. Uma pontuação isolada pode esconder a fragilidade de uma hipótese; registre também o que sustenta cada resposta.
- Situação e consequência
- Quem enfrenta a dificuldade, em que tarefa e o que acontece quando ela permanece. Registre o efeito observado, sem presumir perda de receita ou produtividade.
- Evidência disponível
- O que veio de observação, atendimento ou dados do produto. Indique a origem e quais públicos ou situações ainda não foram considerados.
- Alternativas possíveis
- Compare uma mudança de processo, uma melhoria no produto atual e uma construção nova. Explicite o que cada alternativa exige da operação.
- Próximo aprendizado
- Defina o teste ou a investigação que pode alterar a escolha. Combine quem decide e em que momento a evidência será revisada.
No exemplo do painel, uma atualização de status pode ser a primeira hipótese a testar. Se as dúvidas persistirem porque os próprios responsáveis não conhecem o andamento, a prioridade passa a ser organizar o processo que produz a informação.
Esse roteiro serve para decisões com incerteza sobre o problema. Uma correção urgente que interrompe a operação pede resposta proporcional à urgência, com investigação complementar depois. Nem toda demanda precisa atravessar a mesma profundidade de descoberta.
Quando a decisão envolve um produto em operação, a próxima leitura pode ser onde a interface interrompe a tarefa. Para entender nossa atuação, conheça os serviços de estratégia e evolução de produto.
Referência consultada
GOV.UK Service Manual: How the discovery phase works. Referência para investigação do problema e decisão de continuidade. O roteiro é uma síntese da Antídra; o exemplo é hipotético.
