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.